RE: CONSENSUS TEST: Fragmentation handling

["Michael Roe" <mroe@microsoft.com>]

This proposal is OK with me, although I have a few small quibbles:

(a) I'd prefer "MAY" rather than "SHOULD" for #3 (stateful fragment
    checking), but don't feel very strongly about it.

(b) In #1, I agree with Steve Kent's proposal to have the "ANY" selector
    match non-initial fragments (the packets that match "OPAQUE" are
    a subset of the packets that match "ANY") -- See Steve's revised version
    of #1.

(c) > determination of the "strongest" 
    > algorithms requires imposing a total ordering of the available 
    > algorithms, a local determination at the discretion of the initiator 
    > of the SA.)

    (i) To be pedantic, you don't need a total ordering - it can work with
        some partial orderings.

        forall x in initiatorAlgorithms
            Less_Than_Or_Equal_Initiator (x, negotiatedAlgorithm)

        forall y in responderAlgorithms
            Less_Than_Or_Equal_Responder (y, negotiatedAlgorithm)

         As long as negotiatedAlgorithm exists, you're OK - 
         Less_Than_Or_Equal_Initiator and Less_Than_Or_Equal_Responder
         can be partial orderings.

    (ii) It's not just at the discretion of the initiator. As I understand it,
         both intiator and responder take their local ipsec policies,
         and their own idea of what the ordering on algorithms is, and separately
         decide which algorithms are acceptable for the fragment only SA. IKE then
         attempts to negotiate a choice in the intersection of these two sets of
         acceptable algorithms. 

         [This is just a minor quibble - I'm basically in agreement with what
          is being proposed]

Mike

> 1. All implementations MUST support tunnel mode SAs that pass traffic 
> without regard to port field values. If the SA will carry traffic for 
> specified protocols, the two selector sets MUST be used to specify 
> the port fields for the SA: ANY and OPAQUE. An SA defined in this 
> fashion will carry all traffic for the indicated source/destination 
> addresses and specified protocol(s). If the SA will carry traffic 
> without regard to a specific protocol value (i.e., ANY is specified), 
> then the port field values MUST be set to ANY as well.
> 
> 2. All implementations MAY support tunnel mode SAs that will carry 
> only non-initial fragments, separate from non-fragmented packets and 
> initial fragments. The OPAQUE value will be used to specify port 
> field selectors for an SA to carry non-initial fragments. Specific 
> port selector values will be used to define SAs to carry initial 
> fragments and non-fragmented packets. This approach can be used if a 
> user or administrator wants to create one or more tunnel mode SAs 
> between the same source/destination addresses that discriminate based 
> on port fields.  These SAs MUST have non-trivial protocol selector 
> values, otherwise approach #1 above can be used. Receivers MUST 
> perform a minimum offset check on IPv4 (non-initial) fragments to 
> protect against overlapping fragment attacks when SAs of this type 
> are employed. Because such checks cannot be performed on IPv6 
> non-initial fragments, users and administrators are advised that 
> carriage of such fragments may be dangerous, and implementers may 
> choose to NOT support such SAs for IPv6 traffic. Also, because a SA 
> of this sort will carry ALL non-initial fragments that match a 
> specified source/destination address pair and protocol value, users 
> and administrators are advised to protect such traffic using ESP 
> (with integrity) and the "strongest" integrity and encryption 
> algorithms available at both peers. (Determination of the "strongest" 
> algorithms requires imposing a total ordering of the available 
> algorithms, a local determination at the discretion of the initiator 
> of the SA.)
> 
> 3. An implementation SHOULD support some form of stateful 
> fragment checking for a tunnel mode SA with non-trivial port field 
> values (not ANY or OPAQUE).  Implementations that will transmit 
> non-initial fragments on a tunnel mode SA that makes use of 
> non-trivial port selectors MUST notify a peer via an IKE payload 
> (TBD). The peer MUST reject this proposal if it will not accept 
> non-initial fragments in this context. If an implementation does not 
> successfully negotiate transmission of non-initial fragments for such 
> an SA, it MUST NOT send such fragments over the SA. This standard 
> does not specify how peers will deal with such fragments, e.g., via 
> reassembly or other means, at either sender or receiver. However, a 
> receiver MUST drop non-initial fragments that arrive on an SA with 
> non-trivial port selector values unless this feature has been 
> negotiated. Dropping such packets is an auditable event. Note that in 
> configurations where fragments of a packet might be sent or received 
> via different security gateways or BITW implementations, stateful 
> strategies for tracking fragments may fail.
>