FCIP Last Call, comments 52, 53, 55 and 109 - Short Frame

[Black_David@emc.com]

I'm not satisfied with the proposed resolution of these comments.
They're reproduced below, and my concerns are:

Comments 52 and 53: There needs to be some guidance given for how
	the FCIP entity is supposed to choose among the alternatives.
	I think this may be as simple as one sentence in each case
	pointing to the new text on use of the Short Frame as
	"as a poor-man's SLP", as whether to change the information
	to be returned seems to be the crucial decision facing an
	implementer.

Comment 55: I agree that there's no technical problem here, but
	would like to see an editorial change to avoid the "SHALL wait
	indefinitely" language that bothers me.  I suggest changing:

          The FCIP Entity SHALL wait indefinitely for the FC Entity to
          authenticate source of the TCP connect request and SHALL not
          use the new TCP Connection for any purpose until the FC Entity
          completes the authentication.

	to:

          The FCIP Entity SHALL not use the new TCP Connection for
          any purpose until the FC Entity authenticates the source
          of the TCP connect request.

Comment 109: The proposed resolution says:

   The SF is protected by requiring that the echoed data field values
   exactly match those sent. This is an end-to-end-to-end check that
   is more certain than even a CRC.

	Unfortunately, comments 52 and 53 call out text that allows those
	fields to be changed.  This needs some more thought/explanation,
	and this issue needs to be considered open for now.

Thanks,
--David

--- Comments 52, 53, 55, and 109 -----

Comment 52 Technical

   -- Section 9.1.3 - Processing Incoming TCP Connect Requests

      If the Destination FC Fabric Entity World Wide Name contains 0,
      the FCIP Entity SHALL take one of the following three actions:

      1)  Leave the Destination FC Fabric Entity World Wide Name field
          and Ch bit both 0;
      2)  Change the Destination FC Fabric Entity World Wide Name field
          to match FC Fabric Entity World Wide Name associated with the
          FCIP Entity that received the TCP connect request and change
          the Ch bit to 1; or
      3)  Close the TCP Connection without sending any response.

      The choice between the above actions depends on the anticipated
      usage of the FCIP Entity and is outside the scope of this
      specification. The FCIP Entity may consult the "shared" database
      when choosing between the above actions.

   [T] I'm not buying the "outside the scope" disclaimer. Some more
   description of why the three choices are available is in order even
   if the normative criteria for choosing among them are specified in
   FC-BB-2. If my assumption about FC-BB-2 is correct, the last
   sentence is almost certainly too weak - it needs to refer to
   consulting the FC Entity to determine what to do.

   Accepted but not as the comment intended

   Delete "... and is outside the scope of this specification"

   Other actions to be taken

   Note: Some non SLP implementations wish to use the SF as a
   configuration determination mechanism. The choice exists to allow
   that option.

   Describe this in the new section added in response to comment 44.


Comment 53 Technical

   -- Section 9.1.3 - Processing Incoming TCP Connect Requests

      If:
      a)  The Destination FC Fabric Entity World Wide Name contains a
          non-zero value that does not match the FC Fabric Entity World
          Wide Name associated with the FCIP Entity that received the TCP
          connect request, or
      b)  The contents of the Connection Usage Flags, and Connection
          Usage Code fields is not acceptable to the FCIP Entity that
          received the TCP connect request,
      then the FCIP Entity SHALL take one of the following two actions:
      1)  Change the contents of the unacceptable fields to correct/
          acceptable values and set the Ch bit to 1; or
      2)  Close the TCP Connection without sending any response.

   [T] 1) looks like a security hole that discloses information an
   attacker may find useful in establishing an undesired connection to
   FCIP.
   What's the motivation/purpose for this?

   No changes made

   The motivation is to allow the SF to be used as a poor-man's SLP.

   Option 1) is a security policy that is not a security hole because
   either IPsec or option 2) or both are available as security policy
   choices.

Comment 55 Technical

   -- Section 9.1.3 - Processing Incoming TCP Connect Requests

          The FCIP Entity SHALL wait indefinitely for the FC Entity to
          authenticate source of the TCP connect request and SHALL not
          use the new TCP Connection for any purpose until the FC Entity
          completes the authentication.

   [T] "wait indefinitely" creates an obvious denial of service attack
   vulnerability. Try again.

   Rejected

   The potential for a denial of service attack exists only if the
   attacker can affect the interface between the FCIP Entity and the
   FC Entity. Since the interface between these two exists only inside
   an FCIP-FC implementation, the opportunities for such an attack
   are reasonably beyond the bounds of such concerns.

   If the FCIP Entity and FC Entity were specified in a single
   standard, the wording would be "Do A, B, and C." There would be
   no interface point at which a wait could exist and the issue
   would either be handled implicitly (probably with R_A_TOV) or
   ignored entirely.

Comment 109 Technical

   > 6.6.1 FCIP Encapsulation of FC Frames
   ....
   >    The CRCV (CRC Valid) Flag SHALL be set to 0.
   >
   >    The CRC field SHALL be set to 0.

   I am surprised that the FCIP encapsulated header is never protected
   by a CRC. The error detection section clearly acknowledges the
   possibility that TCP checksum could be inadequate for certain
   deployments - and even suggests checking the FC frame CRC (sort
   of like a data digest) on reception at the Encapsulated Frame
   Receiver Portal.

   My recommendation is to require an FCIP Entity to employ the header
   CRC if the SF that it receives asks for CRC - IOW, similar to iSCSI's
   approach. So, I guess I am also advocating a new bit in the pFlags
   field to announce this. When this CRC expectation is announced, the
   FC CRC checking test in 6.6.2.2 should also be a mandatory test -
   from the "semi-optional" list it is currently in.

   Rejected

   The SF is protected by requiring that the echoed data field values
   exactly match those sent. This is an end-to-end-to-end check that
   is more certain than even a CRC.

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------