SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


Home

Last updated: Sun Apr 21 23:18:50 2002
9738 messages in chronological order