Subject: iFCP: Minutes authors' confcall Fri October 5th

From: "Franco Travostino" <[email-masked]>
Date: Fri, 05 Oct 2001 16:40:03 -0400

Attendees:

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

I) Review of iFCP version 5 changes and document status (CM)

The document was submitted to the IETF repository as 5.0. CM quickly 
described the changes:
a) New security text.
b) Deleted appendix b (IP to FC connectivity) per co-author and IPS wg 
comments
c) Stale frame detection -- Added text describing recommended policy for 
making a transition to the Unsynchronized state following loss of contact 
with SNTP server.
d) Following reboot or cold start, added timed wait before the gateway may 
initiate TCP connections. Requested to prevent collisions with in-flight 
traffic from previous connections.
e) Specified TCP RST as the means to abosrt a TCP connection when an error 
occurs.
f) Added AES section

ME provided I-D references for AES. FT argued that the section addressing 
d) suggests a far too short timeout (5 sec), which may only work for 
in-flight traffic and not for TCP retransmissions. DR suggested a 2 min. 
value (standard), with capability to adjust it through a management interface.

II) Security Update (FT)

FT reported that the iFCP security text had been included in the Aboba 
draft, and that a merge effort took place to harmonize/consolidate the 
iSCSI/iFCP/FCIP contributions. FT warned that the -01.txt version of the 
Aboba draft has several known merge problems in the iFCP+FCIP section, and 
they have been discussed and worked on already to a large extent.

FT mentioned that at the last iscsi-security call the policy work by the 
IPsec Policy WG came up as a potential blueprint for defining security 
attributes into iSNS. JT will be looking into this opportunity.

JT presented several design choices for iSNS security. iSNS security is 
needed to protect data other than identities (e.g., N_PORT attributes, 
SCNs), which an eavesdropper could use to launch targeted attacks (e.g., 
DoS attacks). A key choice is TLS vs IPsec/IKE. TLS appears to be a 
necessary and sufficient solution when talking to an iSNS server. Most 
likely, however, iFCP implementations will want to piggyback on existing 
IPsec/IKE apparatus, for merely practical reasons. There was consensus that 
IPsec/IKE will be used. JT asked whether confidentiality matters in iFCP to 
iSNS exchanges. There was consensus that encryption is a MUST implement 
just like it is for the iFCP protocol.

III) Discussion of comments not incorporated in iFCP, rev 5 (CM)
a) QoS hints from FC exchanges
b) TPRLO frame size
For a), there was consensus that the specification should not venture into 
describing QoS hooks built into FC traffic, either as PLOGI options or 
CS_CTL field. Normative text and current practice do not support use of 
these hooks, thus  iFCP gateways will not see these QoS hints in FC exchanges.

For b), CM explained why the failure semantics related to frame size are 
already covered in detail, and how other border cases for TRPLO frame size 
cannot happen by design.

IV) Last call action items

The co-authors agree that release 6 of the iFCP specification, publicly 
available next week,  is by all means a complete draft, meeting all the 
known last call requirements (with the notable exception of the signature 
key authentication section in the security area, which still needs to be 
synchronized with work happening or soon-to-be-happening within 
iscsi-security). Thorough reviews from the larger community are in order at 
this point.

-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]