RE: 2nd try

["Bora Akyol" <bora@cisco.com>]

Hi Steve,

This looks good, one question about the fragment SA(s):

If we have several "parallel" SAs to support different levels
of QoS (for the main SAs), do we need to have the same amount
of fragment SAs as the main ones? 

Thanks

Bora

> Conclusions
> 
> There is no simple, uniform way to handle fragments in all contexts. 
> Different approaches work better in different contexts.  Thus I 
> suggest we require support for two approaches, and offer a third, and 
> allow a user or administrator to choose from among these based on 
> topology constraints and security requirements. Hence the following 
> proposed text:
> 
> 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 MUST 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 MAY choose to 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.
>