Re: FCIP Last Call, comments 52 & 53 - Special Frame

[Ralph Weber <ralphoweber@compuserve.com>]

Regarding:

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

These two are the comments I would prefer to see left open until
we have the section that describes the connection setup usage of
the Special Frame. It may be that a pointer to that section will
suffice.

Thanks.

.Ralph

Black_David@emc.com wrote:

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