[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-ipsec-sctp-06.txt
You're right, said paragraph will be deleted. The rationale behind it was to
try to minimize the risk of address-imprersonation attacks inside a tunnel, but
this is in fact taken care of at the IKE{,v2} level by establishing the
appropriate SPD entries.
-Angelos
In message <6204FDDE129D364D8040A98BCCB290EF052203FD@zbl6c004.corpeast.baynetwo
rks.com>, "Paul Knight" writes:
>This message is in MIME format. Since your mail reader does not understand
>this format, some or all of this message may not be legible.
>
>------_=_NextPart_001_01C2FF7E.221FB260
>Content-Type: text/plain
>
>Hi Steve and all,
>
>The draft (in the end of Section 2, below) appears to propose a new
>requirement that remote access tunnel mode IPsec users MUST use an inner IP
>address equivalent to their outer address (or else it reclassifies such
>users as "security gateways"). This seems to directly contradict all the
>work with DHCP over IKE and the entire Configuration Payload discussion, all
>of which is based on assigning an inner tunnel address which can be a part
>of a VPN address domain (i.e., different from the outer address).
>
>Am I missing something (besides my second cup of coffee)?
>
>Regards,
>Paul Knight
>
>>From Section 2:
> When operating in tunnel mode, the question of what to use as the
> tunnel destination address (for the "outer" header) arises. We
> distinguish three cases: where the end hosts are also the tunnel
> endpoints; where neither host is a tunnel endpoint (the tunnel
> endpoints are security gateways); and where only one of the hosts is
> a tunnel endpoint (the usual case for the "road warrior" talking to
> a security gateway). In the first case, the outer addresses MUST be
> the same as the inner addresses of the tunnel. In the second case
> (security gateways) there is no special processing; address
> selection proceeds as it would for two distinct sets of end hosts.
> In the third case, the "road warrior" uses the security gateway's
> address as the tunnel destination address, and MUST use the same
> source address as that of the inner packet. Symmetrically, the
> security gateway uses its own address as the source address of the
> tunnel, and MUST use the the same destination address in the outer
> header as that of the inner packet. An implementation will probably
> structure the code so that if, during SA setup, the inner and outer
> address of either side is the same, rather than explicitly store the
> corresponding address of the tunnel, it sets a flag that marks the SA
> to use the same address in the tunnel header as in the inner header.
>
>> -----Original Message-----
>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
>> Sent: Wednesday, April 09, 2003 7:18 AM
>> To: IETF-Announce; @tislabs.com
>> Cc: ipsec@lists.tislabs.com
>> Subject: I-D ACTION:draft-ietf-ipsec-sctp-06.txt
>>
>>
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories. This draft is a work item of the
>> IP Security Protocol Working Group of the IETF.
>>
>> Title : On the Use of SCTP with IPsec
>> Author(s) : S. Bellovin et al.
>> Filename : draft-ietf-ipsec-sctp-06.txt
>> Pages : 0
>> Date : 2003-4-8
>>
>> This document describes functional requirements for IPsec
>> [RFC2401] and IKE [RFC2409] to facilitate their use for
>> securing SCTP [RFC2960] traffic.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sctp-06.t
>xt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in, type
>"cd internet-drafts" and then
> "get draft-ietf-ipsec-sctp-06.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
> mailserv@ietf.org.
>In the body type:
> "FILE /internet-drafts/draft-ietf-ipsec-sctp-06.txt".
>
>NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility. To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command. To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader. Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>------_=_NextPart_001_01C2FF7E.221FB260
>Content-Type: text/html
>Content-Transfer-Encoding: quoted-printable
>
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
><HTML>
><HEAD>
><META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
>charset=3Dus-ascii">
><META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
>5.5.2656.31">
><TITLE>RE: I-D ACTION:draft-ietf-ipsec-sctp-06.txt</TITLE>
></HEAD>
><BODY>
>
><P><FONT SIZE=3D2>Hi Steve and all, </FONT>
></P>
>
><P><FONT SIZE=3D2>The draft (in the end of Section 2, below) appears to =
>propose a new requirement that remote access tunnel mode IPsec users =
>MUST use an inner IP address equivalent to their outer address (or else =
>it reclassifies such users as "security gateways"). =
>This seems to directly contradict all the work with DHCP over IKE and =
>the entire Configuration Payload discussion, all of which is based on =
>assigning an inner tunnel address which can be a part of a VPN address =
>domain (i.e., different from the outer address).</FONT></P>
>
><P><FONT SIZE=3D2>Am I missing something (besides my second cup of =
>coffee)?</FONT>
></P>
>
><P><FONT SIZE=3D2>Regards,</FONT>
><BR><FONT SIZE=3D2>Paul Knight</FONT>
></P>
>
><P><FONT SIZE=3D2>From Section 2:</FONT>
><BR><FONT SIZE=3D2> When operating in tunnel mode, the =
>question of what to use as the</FONT>
><BR><FONT SIZE=3D2> tunnel destination address (for the =
>"outer" header) arises. We</FONT>
><BR><FONT SIZE=3D2> distinguish three cases: where the end =
>hosts are also the tunnel</FONT>
><BR><FONT SIZE=3D2> endpoints; where neither host is a =
>tunnel endpoint (the tunnel</FONT>
><BR><FONT SIZE=3D2> endpoints are security gateways); and =
>where only one of the hosts is</FONT>
><BR><FONT SIZE=3D2> a tunnel endpoint (the usual case for =
>the "road warrior" talking to</FONT>
><BR><FONT SIZE=3D2> a security gateway). In the first =
>case, the outer addresses MUST be</FONT>
><BR><FONT SIZE=3D2> the same as the inner addresses of the =
>tunnel. In the second case</FONT>
><BR><FONT SIZE=3D2> (security gateways) there is no special =
>processing; address</FONT>
><BR><FONT SIZE=3D2> selection proceeds as it would for two =
>distinct sets of end hosts.</FONT>
><BR><FONT SIZE=3D2> In the third case, the "road =
>warrior" uses the security gateway's</FONT>
><BR><FONT SIZE=3D2> address as the tunnel destination =
>address, and MUST use the same</FONT>
><BR><FONT SIZE=3D2> source address as that of the inner =
>packet. Symmetrically, the</FONT>
><BR><FONT SIZE=3D2> security gateway uses its own address =
>as the source address of the</FONT>
><BR><FONT SIZE=3D2> tunnel, and MUST use the the same =
>destination address in the outer</FONT>
><BR><FONT SIZE=3D2> header as that of the inner =
>packet. An implementation will probably</FONT>
><BR><FONT SIZE=3D2> structure the code so that if, during =
>SA setup, the inner and outer</FONT>
><BR><FONT SIZE=3D2> address of either side is the same, =
>rather than explicitly store the</FONT>
><BR><FONT SIZE=3D2> corresponding address of the tunnel, it =
>sets a flag that marks the SA</FONT>
><BR><FONT SIZE=3D2> to use the same address in the tunnel =
>header as in the inner header.</FONT>
></P>
>
><P><FONT SIZE=3D2>> -----Original Message-----</FONT>
><BR><FONT SIZE=3D2>> From: Internet-Drafts@ietf.org [<A =
>HREF=3D"mailto:Internet-Drafts@ietf.org">mailto:Internet-Drafts@ietf.org=
></A>] </FONT>
><BR><FONT SIZE=3D2>> Sent: Wednesday, April 09, 2003 7:18 AM</FONT>
><BR><FONT SIZE=3D2>> To: IETF-Announce; @tislabs.com</FONT>
><BR><FONT SIZE=3D2>> Cc: ipsec@lists.tislabs.com</FONT>
><BR><FONT SIZE=3D2>> Subject: I-D =
>ACTION:draft-ietf-ipsec-sctp-06.txt</FONT>
><BR><FONT SIZE=3D2>> </FONT>
><BR><FONT SIZE=3D2>> </FONT>
><BR><FONT SIZE=3D2>> A New Internet-Draft is available from the =
>on-line </FONT>
><BR><FONT SIZE=3D2>> Internet-Drafts directories. This draft is a =
>work item of the </FONT>
><BR><FONT SIZE=3D2>> IP Security Protocol Working Group of the =
>IETF.</FONT>
><BR><FONT SIZE=3D2>> </FONT>
><BR><FONT SIZE=3D2>> =
>Title : On the =
>Use of SCTP with IPsec</FONT>
><BR><FONT SIZE=3D2>> =
>Author(s) : S. Bellovin et =
>al.</FONT>
><BR><FONT SIZE=3D2>> =
>Filename : =
>draft-ietf-ipsec-sctp-06.txt</FONT>
><BR><FONT SIZE=3D2>> =
>Pages : 0</FONT>
><BR><FONT SIZE=3D2>> =
>Date : =
>2003-4-8</FONT>
><BR><FONT SIZE=3D2>> </FONT>
><BR><FONT SIZE=3D2>> This document describes functional requirements =
>for IPsec </FONT>
><BR><FONT SIZE=3D2>> [RFC2401] and IKE [RFC2409] to facilitate their =
>use for </FONT>
><BR><FONT SIZE=3D2>> securing SCTP [RFC2960] traffic.</FONT>
><BR><FONT SIZE=3D2>> </FONT>
><BR><FONT SIZE=3D2>> A URL for this Internet-Draft is: </FONT>
><BR><FONT SIZE=3D2>> <A =
>HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sctp-06.t" =
>TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-ipsec-s=
>ctp-06.t</A></FONT>
><BR><FONT SIZE=3D2>xt</FONT>
></P>
>
><P><FONT SIZE=3D2>To remove yourself from the IETF Announcement list, =
>send a message to </FONT>
><BR><FONT SIZE=3D2>ietf-announce-request with the word unsubscribe in =
>the body of the message.</FONT>
></P>
>
><P><FONT SIZE=3D2>Internet-Drafts are also available by anonymous FTP. =
>Login with the username "anonymous" and a password of your =
>e-mail address. After logging in, type "cd internet-drafts" =
>and then</FONT></P>
>
><P> <FONT SIZE=3D2>"get =
>draft-ietf-ipsec-sctp-06.txt".</FONT>
></P>
>
><P><FONT SIZE=3D2>A list of Internet-Drafts directories can be found in =
><A HREF=3D"http://www.ietf.org/shadow.html" =
>TARGET=3D"_blank">http://www.ietf.org/shadow.html</A> </FONT>
><BR><FONT SIZE=3D2>or <A =
>HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" =
>TARGET=3D"_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT>
></P>
><BR>
>
><P><FONT SIZE=3D2>Internet-Drafts can also be obtained by =
>e-mail.</FONT>
></P>
>
><P><FONT SIZE=3D2>Send a message to:</FONT>
><BR> <FONT =
>SIZE=3D2>mailserv@ietf.org.</FONT>
><BR><FONT SIZE=3D2>In the body type:</FONT>
><BR> <FONT =
>SIZE=3D2>"FILE =
>/internet-drafts/draft-ietf-ipsec-sctp-06.txt".</FONT>
><BR> =20
><BR><FONT SIZE=3D2>NOTE: The mail server at ietf.org can =
>return the document in</FONT>
><BR> <FONT =
>SIZE=3D2>MIME-encoded form by using the "mpack" =
>utility. To use this</FONT>
><BR> <FONT SIZE=3D2>feature, =
>insert the command "ENCODING mime" before the =
>"FILE"</FONT>
><BR> <FONT =
>SIZE=3D2>command. To decode the response(s), you will need =
>"munpack" or</FONT>
><BR> <FONT SIZE=3D2>a =
>MIME-compliant mail reader. Different MIME-compliant mail =
>readers</FONT>
><BR> <FONT SIZE=3D2>exhibit =
>different behavior, especially when dealing with</FONT>
><BR> <FONT =
>SIZE=3D2>"multipart" MIME messages (i.e. documents which have =
>been split</FONT>
><BR> <FONT SIZE=3D2>up into =
>multiple messages), so check your local documentation on</FONT>
><BR> <FONT SIZE=3D2>how to =
>manipulate these messages.</FONT>
><BR> =
> =20
><BR> =
> =20
><BR><FONT SIZE=3D2>Below is the data which will enable a MIME compliant =
>mail reader implementation to automatically retrieve the ASCII version =
>of the Internet-Draft.</FONT></P>
>
></BODY>
></HTML>
>------_=_NextPart_001_01C2FF7E.221FB260--