iFCP: Minutes authors' confcall Fri September 21th

["Franco Travostino" <travos@nortelnetworks.com>]

Attendees:
Mark Edwards, Eurologic
Charles Monia, Nishan Systems
David Robinson, Sun Microsystems
Franco Travostino, Nortel Networks
Josh Tseng, Nishan Systems


1.  iFCP Security

FT described the latest snapshot of security work for the soon-to-be iFCP 05 spec. JT and FT had derived this prose from the iFCP text in the Aboba I-D and from the post-interim slides posted to the IPS reflector.

1.1. ME had caught a wrong sentence there, to the sense that it was possible to _negotiate_ any and all security features away. 'Negotiate' is the wrong word, it applies to iSCSI but not to iFCP. For iFCP, we  must use 'administratively disable' rather than 'negotiate'. Both ME and JT were satisfied with this change.

1.2. Static vs. dynamic IP addresses. David Black had questioned whether a MUST not use DHCP would pass muster with the IESG. There was consensus that DHCP for iFCP is most unlikely. DR successfully argued that a router cannot possibly use DHCP-supplied addresses, thus there must be an acceptable way to word this requirement. Given that we are bought into IKE Aggressive Mode anyway due to Main Mode's weakness with pre-shared group keys, we agreed that this is now a minor issue.

1.3. AES CTR mode. ME gave us a reference to a new I-D for the latter (that is, draft-moskowitz-aes128-ctr-00.txt). DR proposed that we put AES CTR as MUST implement, and add the proviso that we will eliminate such requirement if there is no normative text that we can cite. We agreed on this wording, and we continue to see 3DES CBC suiting us just fine.

1.4. Transport vs tunnel mode. FT asked to review current text stating that tunnel mode is MUST implement and transport mode is SHOULD implement. ME reaffirmed that dual implementation is easy enough in software, and had indirect knowledge that hardware implementation was simple enough. JT to gain more anecdotal evidence.

1.5. DR asked about SLP being a plausible setup alternative. ME and JT answered that iSNS is an invariant, and that the iSNS spec already describes that an iSNS client may implement an SLP client for discovery.

1.6. Process. We agreed to make a few additional passes on the security text, and then incorporate it into iFCP revision 05 (tentative date for IETF submission, Sept. 28th). The Aboba I-D will also be upgraded and kept consistent to the extent that we can manage it. The iFCP text, which we can fully control, will be the authoritative text in case of version skews.

2.  iFCP issues from the last WG.

CM addressed the following points, which were raised during the WG interim meeting.

2.1. Should appendix B, "Implementing IP to FC connectivity" be deleted? DR proposed to have an Informational RFC describing this new application scenario. Everybody agreed.

2.2. Should Appendix B specify that the DF bit must be honored for inbound and outbound IP traffic? Agreed, but it's really not germane here due to resolution in 2.1.

2.3. Stale frame detection, and clock accuracy issues. It was proposed to revise iFCP to require 100 ppm for the time reference, and to specify the accuracy requirements for the client nodes as a function of client update frequency. CM has verified that 100 ppm is comfortably within the state of the art. FT recalled that we also ought to define a measure for loss of sync. FT and ME asked that the spec indicates a recommended value. This suggestion was accepted.

2.4. Should FC-MI support be an iFCP goal? It would require that iFCP gateways support FC management server. CM described the FC-MI issue in detail. FT asked whether T11.3 currently believes that FC-MI is a mandatory property for FC. After some discussion, we agreed that CM will take the FC-MI issue to the proper working group at the next T11 meeting.

3.  Rev 4.1 feedback

FT asked about TRPLO commands whose parameter pages exceed frame size. After some discussion, it became clear that the specification could use extra text detailing the end-to-end failure semantics for this case.

FT mentioned that TCP RST came up at the interim meeting as a quick way to terminate a TCP connection upon abnormal conditions (e.g., a CRC error in the common encapsulation frame). We agreed to set requirement levels for use of TCP RST upon specific errors.

FT said that a gateway implementation could reboot fast enough to defeat the purpose of the TIME_WAIT state, thus making it possible for ghost frames to be around still and derail communication (ignoring IP security mechanisms for a second). There was consensus that it may be worth indicating a quiet time in the specification (the TCP specifications are quite vague on this, with values that are dated and practically ignored in most cases because end-systems' OSs take long time to reboot anyway).

-franco

Franco Travostino, Director Content Internetworking Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: travos@nortelnetworks.com