Subject: iFCP: Minutes authors' confcall Fri September 21th

From: "Franco Travostino" <[email-masked]>
Date: Fri, 21 Sep 2001 17:51:51 -0400

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: [email-masked]