Re: FCIP Last Call, comment 109 - Special Frame

[Ralph Weber <ralphoweber@compuserve.com>]

Regarding:

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

Yes, the fields are allowed to be changed and such changes result
in the connection being closed 100% of the time. Whether the changes
are intentional or accidental, the connection is ALWAYS closed if
the SF fails to transit back and forth unchanged.

The ONLY way the connection is NOT closed is when the SF transits
both directions unchanged, NO EXCEPTIONS.

I believe that this fully maintains the integrity of the end-to-end
check described in the comment response.

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