CONSENSUS TEST: Fragmentation handling

["Theodore Ts'o" <tytso@mit.edu>]

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.