iFCP: Minutes authors' confcall Fri October 5th

["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

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: travos@nortelnetworks.com