Re: CONSENSUS TEST: Fragmentation handling

[vamsi <vamsi@intotoinc.com>]

At 12:27 PM 4/6/2004 -0400, Theodore Ts'o wrote:
>On Fri, Apr 02, 2004 at 09:55:07AM -0500, Stephen Kent wrote:
> > > > How about a compromise? We could make #2 a MAY and #3 a SHOULD. A
> > >> SHOULD is almost a MUST, with a loophole as noted below (from RFC
> > >> 2119):
> > >
> > >That would be accectable for me.
> > >
> > >> This would allow a hardware implementation to not support #3, if
> > >> doing so would adversely impact overall performance.
> > >
> >
> > Well, since we agree on a solution, let's not argue about the rationale :-)
>
>OK, do we have have consensus on the following text?  (Taken from
>Steve's message of March 22nd, with #2 changed to MAY and #3 changed
>to SHOULD).
>
>Please respond by Friday....
>
>                                                 - Ted
>
>
>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.

It seems fine to me, but I have these comments.
1. Case 3 can be made as 'MAY'.
2. When case 2 is not employed and when communicating security gateways
     don't agree on, as mentioned in case3, the sender implementations, in my
     view, MUST not drop the packets and use mechanisms such as 'reassembly'.
     So, it would be better to indicate this explicitly in the text.

Vamsi