Subject: Re: FW: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt

From: Karen Seo <[email-masked]>
Date: Wed, 23 Mar 2005 09:29:33 -0500

Hi Vishwas,

Thank you for the email below.  I was worried for a moment there.  I 
checked the list of changes I just sent out and the update you 
describe below is on the list (about 3/4's of the way down) and in 
the new draft.

Karen

>Hi Karen,
>
>This is what Steve had sent a month back.
>
>Thanks,
>Vishwas
>
>From: Stephen Kent [mailto:[email-masked]]
>Sent: Monday, February 28, 2005 9:59 PM
>To: [email-masked]
>Cc: Vishwas Manral; [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]; Stephen Kent
>Subject: RE: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt
>
>Folks,
>
>Here is the text I have crafted for the next rev of 2401bis, based 
>on David's suggested text from a few weeks ago:
>
>In 5.1.2 replace the bullet:
>
>  o IPsec describes how to handle ECN or DS.
>
>with
>
>   o IPsec describes how to handle ECN and DS and provides the ability
>
>to control propagation of changes in these fields between unprotected
>
>and protected domains. In general, propagation from a protected to an
>
>unprotected domain is a covert channel and thus controls are provided
>
>to manage the bandwidth of this channel. Propagation of ECN values in
>
>the other direction are controlled so that only legitimate
>
>ECN changes (indicating occurrence of congestion between the tunnel
>
>endpoints) are propagated.  By default, DS propagation from an
>
>unprotected domain to a protected domain is not permitted.  However,
>
>if the sender and receiver do not share the same DS code space, and
>
>the receiver has no way of learning how to map between the two spaces,
>
>then it may be appropriate to deviate from the default. Specifically,
>
>an IPsec implementation MAY be configurable in terms of how it processes
>
>the outer DS field for tunnel mode for received packets. It may be
>
>configured to either discard the outer DS value (the default) OR to
>
>overwrite the inner DS field with the outer DS field.  If offered
>
>the discard vs. overwrite behavior MAY be configured on a per SA basis.
>
>This configuration option allows a local administrator to decide whether
>
>the vulnerabilities created by copying these bits outweigh the
>
>benefits of copying.  See [RFC 2983] for further information on when
>	each of these behaviors may be useful, and also for the possible
>	need for diffserv traffic conditioning prior or subsequent to IPsec
>
>processing (including tunnel decapsulation).
>
>In 5.1.2.2, change the the header construction table for DS Field, 
>so that the column for the decapsulator says "no change" (9).
>
>add note 9
>
>      9. An implementation MAY choose to provide a facility to bypass
>
>the DS value from the outer header to the inner header, on
>
>a per SA basis, for received tunnel mode packets. The motivation
>
>for providing this feature is to accommodate situations in which
>
>the DS code space at the receiver is different from that of the
>
>sender and the receiver has no way of knowing how to translate from
>
>the sender's space. There is a danger in copying this value from
>
>the outer header to the inner header, since it enables an attacker
>
>to modify the outer DSCP value in a fashion that may adversely affect
>
>other traffic at the receiver.  Hence the default behavior for IPsec
>
>implementations is NOT to permit such copying.
>
>
_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec