[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: Re: FW: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt
From: Karen Seo <kseo () bbn ! com>
Date: 2005-03-23 14:29:33
Message-ID: p06100543be672cf919ae () [128 ! 89 ! 89 ! 115]
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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:kent@bbn.com]
>Sent: Monday, February 28, 2005 9:59 PM
>To: Black_David@emc.com
>Cc: Vishwas Manral; hartmans-ietf@mit.edu; brc@zurich.ibm.com;
>Black_David@emc.com; housley@vigilsec.com; 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.
>
>
[Attachment #5 (text/html)]
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: FW: [Ipsec]
draft-ietf-ipsec-rfc2401bis-05.txt</title></head><body>
<div>Hi Vishwas,</div>
<div><br></div>
<div>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. </div>
<div><br></div>
<div>Karen</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#000080">Hi Karen,</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#000080"> </font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#000080">This is what Steve had sent a month
back.</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#000080"> </font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#000080">Thanks,</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#000080">Vishwas</font></blockquote>
<blockquote type="cite" cite>
<hr size="2"></blockquote>
<blockquote type="cite" cite><font face="Tahoma"
size="-1"><b>From:</b> Stephen Kent [mailto:kent@bbn.com]<br>
<b>Sent:</b> Monday, February 28, 2005 9:59 PM<br>
<b>To:</b> Black_David@emc.com<br>
<b>Cc:</b> Vishwas Manral; hartmans-ietf@mit.edu; brc@zurich.ibm.com;
Black_David@emc.com; housley@vigilsec.com; Stephen Kent<br>
<b>Subject:</b> RE: [Ipsec]
draft-ietf-ipsec-rfc2401bis-05.txt</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">Folks,</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">Here is the
text I have crafted for the next rev of 2401bis, based on David's
suggested text from a few weeks ago:</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">In 5.1.2
replace the bullet:</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font></blockquote>
<blockquote type="cite" cite><font size="+2" color="#000000"> o
IPsec describes how to handle ECN or DS.</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">with</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"> o
IPsec describes how to handle ECN and DS and provides the
ability</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">to control
propagation of changes in these fields between
unprotected</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">and
protected domains. In general, propagation from a protected to
an</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">unprotected
domain is a covert channel and thus controls are
provided</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">to manage
the bandwidth of this channel. Propagation of ECN values
in</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">the other
direction are controlled so that only legitimate</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">ECN changes
(indicating occurrence of congestion between the
tunnel</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">endpoints)
are propagated. By default, DS propagation from
an</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">unprotected
domain to a protected domain is not permitted.
However,</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">if the
sender and receiver do not share the same DS code space,
and</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">the receiver
has no way of learning how to map between the two
spaces,</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">then it may
be appropriate to deviate from the default.
Specifically,</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">an IPsec
implementation MAY be configurable in terms of how it
processes</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">the outer DS
field for tunnel mode for received packets. It may
be</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">configured
to either discard the outer DS value (the default) OR
to</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">overwrite
the inner DS field with the outer DS field. If
offered</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">the discard
vs. overwrite behavior MAY be configured on a per SA
basis.</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">This
configuration option allows a local administrator to decide
whether</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">the
vulnerabilities created by copying these bits outweigh
the</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">benefits of
copying. See [RFC 2983] for further information on when<br>
<x-tab> </x-tab>each of these behaviors may be
useful, and also for the possible<br>
<x-tab> </x-tab>need for
diffserv traffic conditioning prior or subsequent to
IPsec</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">processing
(including tunnel decapsulation).</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">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).</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">add note
9</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> 9. An implementation
MAY choose to provide a facility to bypass</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">the DS value
from the outer header to the inner header, on</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">a per SA
basis, for received tunnel mode packets. The
motivation</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">for
providing this feature is to accommodate situations in
which</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">the DS code
space at the receiver is different from that of
the</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">sender and
the receiver has no way of knowing how to translate
from</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">the sender's
space. There is a danger in copying this value
from</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">the outer
header to the inner header, since it enables an
attacker</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">to modify
the outer DSCP value in a fashion that may adversely
affect</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">other
traffic at the receiver. Hence the default behavior for
IPsec</font></blockquote>
<blockquote type="cite"
cite><x-tab>
</x-tab></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">implementations is NOT to permit such
copying.</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font></blockquote>
<div><br></div>
</body>
</html>
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic