Re: ECN and issue 58

[Joe Touch <touch@ISI.EDU>]

Black_David@emc.com wrote:

> Joe,
> 
> 
>>>My proposed text:
>>>
>>>When IPsec tunnels behave as originally specified in [RFC 2401], ECN
> 
> usage
> 
>>>is not appropriate for the outer IP headers because tunnel decapsulation
>>>processing discards ECN congestion indications to the detriment of the
>>>network.  ECN support for IPsec tunnels for IKEv1-based IPsec requires
>>>multiple  operating modes and negotiation (see [RFC 3168]).  IKEv2
>>>simplifies this situation requiring that ECN be usable in the outer IP
>>>headers of all tunnel-mode IPsec SAs created by IKEv2.  Specifically,
>>>tunnel encapsulators and decapsulators for all tunnel-mode Security
>>>Associations (SAs) created by IKEv2 MUST support the ECN
> 
> full-functionality
> 
>>>option for tunnels specified in [RFC3168] and MUST implement the tunnel
>>>encapsulation and decapsulation processing specified in [RFC2401bis] to
>>>prevent discarding of ECN congestion indications.
>>>
>>>NB: [RFC 2401] reference is informative, [RFC 3168] and [2401bis] are
>>>normative.
>>
>>It might be useful to consider that RFC2168 already specifies how ECN 
>>interacts with IP in IP (RFC2003) tunneling (sec 9.1), and that IPsec 
>>tunnels should follow that convention.
> 
> 
> Yes, that was considered, and the latter reference to [RFC3168] in my text
> is to sec 9.1 -  it would be good to make that explicit (i.e., "... ECN
> full-functionality option for tunnels specified in Section 9.1 of
> [RFC3168].").

Yes.

>>This is keeping with another goal, i.e., having 2401bis point to RFC2003 
>>excepting only security caveats, rather than (largely) respecifying an 
>>existing specification.
> 
> 
> If 2401bis goes that route, that would be ok, but 2401bis has to do
> something to override RFC2401 and Section 9.2 of RFC3168.  I would
> prefer to not point to RFC2003 from IKEv2, and leave it to 2401bis to
> decide whether to say that this is realized by reference to RFC2003
> (... provided that you can convince Steve Kent that the result doesn't
>  break any IPsec security properties ... ).

Sure - it's probably better to have all that info in one place - in 2401bis.

Joe