Subject: RE: I-D ACTION:draft-ietf-ipsec-sctp-06.txt

From: "Paul Knight" <[email-masked]>
Date: Thu, 10 Apr 2003 12:27:52 -0400

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: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, April 09, 2003 7:18 AM
> To: IETF-Announce; @tislabs.com
> Cc: [email-masked]
> 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:
	[email-masked].
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.

---

From: Derek Atkins <[email-masked]>
Date: 10 Apr 2003 21:58:44 -0400

Paul,

No, it appears your reading of this is correct.  I hope this is a bug
(or an oversight).  I agree with you that a road warrior probably has
a different inner IP address than external IP Address.  The main
difference between a road warrior and a security gateway is that the
road warrior generally has an inner network of an IPv4/32 or an
IPv6/128.

I agree this text should be fixed.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Francis Dupont <[email-masked]>
Date: Fri, 11 Apr 2003 12:07:14 +0200

In your previous mail you wrote:

=> Please don't send an HTML copy of the body...

   
=> I believe this draft is about IKEv1 and IKEv2 can be different...
I can say this issue stresses the need of an address management
(so the fact a node can use several own addresses is taken into account
and the "same address" becomes "address which belongs to the same node",
the issue is solved at the price to have to implement the belonging (?)
check).

=> I have to confess that I don't understand why the draft requires the
same address when all the text before this paragraph shows it should only
require that the inner address and the outer address (aka the peer address)
belongs to the same node, i.e., is member of the address set!
 Perhaps this is a consequence of the usual confusion between inner and
outer addresses when we talk about SPD and SADB selectors... But the draft
is clear about this issue, SPD selectors are trafic selectors and match
the inner address. There is no SADB selector involved: the text is about
the incoming processing and uses explicitely the outer address (the right
term, "peer address", is in the text) for the SA lookup.
 The only reason (which is not in the draft) I can find is to make things
simpler, i.e., disallow flexibility between inner and outer addresses.
Of course, I share your concern, i.e., this doesn't work when some addresses
have not the same status than others. I am waiting the answer from the
authors!

Thanks

[email-masked]

PS: my address management proposal convers the multi-homing case so works
well with SCTP. For instance, it provides a very easy way to negociate
the set of addresses in all "phases".
PPS: BTW the draft should reference the PKIX document, aka RFC 3280,
in the certificate discussion (3-2-a).

---

From: "Angelos D. Keromytis" <[email-masked]>
Date: Tue, 15 Apr 2003 14:01:11 -0400

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 <[email-masked]
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, 
>
>------_=_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 &quot;security gateways&quot;).&nbsp; =
>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>&nbsp;&nbsp; When operating in tunnel mode, the =
>question of what to use as the</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; tunnel destination address (for the =
>&quot;outer&quot; header) arises.&nbsp; We</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; distinguish three cases: where the end =
>hosts are also the tunnel</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; endpoints; where neither host is a =
>tunnel endpoint (the tunnel</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; endpoints are security gateways); and =
>where only one of the hosts is</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; a tunnel endpoint (the usual case for =
>the &quot;road warrior&quot; talking to</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; a security gateway).&nbsp; In the first =
>case, the outer addresses MUST be</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; the same as the inner addresses of the =
>tunnel.&nbsp; In the second case</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; (security gateways) there is no special =
>processing; address</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; selection proceeds as it would for two =
>distinct sets of end hosts.</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; In the third case, the &quot;road =
>warrior&quot; uses the security gateway's</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; address as the tunnel destination =
>address, and MUST use the same</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; source address as that of the inner =
>packet.&nbsp; Symmetrically, the</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; security gateway uses its own address =
>as the source address of the</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; tunnel, and MUST use the the same =
>destination address in the outer</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; header as that of the inner =
>packet.&nbsp; An implementation will probably</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; structure the code so that if, during =
>SA setup, the inner and outer</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; address of either side is the same, =
>rather than explicitly store the</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; corresponding address of the tunnel, it =
>sets a flag that marks the SA</FONT>
><BR><FONT SIZE=3D2>&nbsp;&nbsp; to use the same address in the tunnel =
>header as in the inner header.</FONT>
></P>
>
><P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
><BR><FONT SIZE=3D2>&gt; From: [email-masked] [<A =
>HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
></A>] </FONT>
><BR><FONT SIZE=3D2>&gt; Sent: Wednesday, April 09, 2003 7:18 AM</FONT>
><BR><FONT SIZE=3D2>&gt; To: IETF-Announce; @tislabs.com</FONT>
><BR><FONT SIZE=3D2>&gt; Cc: [email-masked]</FONT>
><BR><FONT SIZE=3D2>&gt; Subject: I-D =
>ACTION:draft-ietf-ipsec-sctp-06.txt</FONT>
><BR><FONT SIZE=3D2>&gt; </FONT>
><BR><FONT SIZE=3D2>&gt; </FONT>
><BR><FONT SIZE=3D2>&gt; A New Internet-Draft is available from the =
>on-line </FONT>
><BR><FONT SIZE=3D2>&gt; Internet-Drafts directories. This draft is a =
>work item of the </FONT>
><BR><FONT SIZE=3D2>&gt; IP Security Protocol Working Group of the =
>IETF.</FONT>
><BR><FONT SIZE=3D2>&gt; </FONT>
><BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
>Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : On the =
>Use of SCTP with IPsec</FONT>
><BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
>Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : S. Bellovin et =
>al.</FONT>
><BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
>Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
>draft-ietf-ipsec-sctp-06.txt</FONT>
><BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
>Pages&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 0</FONT>
><BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
>Date&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
>2003-4-8</FONT>
><BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
><BR><FONT SIZE=3D2>&gt; This document describes functional requirements =
>for IPsec </FONT>
><BR><FONT SIZE=3D2>&gt; [RFC2401] and IKE [RFC2409] to facilitate their =
>use for </FONT>
><BR><FONT SIZE=3D2>&gt; securing SCTP [RFC2960] traffic.</FONT>
><BR><FONT SIZE=3D2>&gt; </FONT>
><BR><FONT SIZE=3D2>&gt; A URL for this Internet-Draft is: </FONT>
><BR><FONT SIZE=3D2>&gt; <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 &quot;anonymous&quot; and a password of your =
>e-mail address. After logging in, type &quot;cd internet-drafts&quot; =
>and then</FONT></P>
>
><P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&quot;get =
>draft-ietf-ipsec-sctp-06.txt&quot;.</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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
>SIZE=3D2>[email-masked].</FONT>
><BR><FONT SIZE=3D2>In the body type:</FONT>
><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
>SIZE=3D2>&quot;FILE =
>/internet-drafts/draft-ietf-ipsec-sctp-06.txt&quot;.</FONT>
><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
><BR><FONT SIZE=3D2>NOTE:&nbsp;&nbsp; The mail server at ietf.org can =
>return the document in</FONT>
><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
>SIZE=3D2>MIME-encoded form by using the &quot;mpack&quot; =
>utility.&nbsp; To use this</FONT>
><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>feature, =
>insert the command &quot;ENCODING mime&quot; before the =
>&quot;FILE&quot;</FONT>
><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
>SIZE=3D2>command.&nbsp; To decode the response(s), you will need =
>&quot;munpack&quot; or</FONT>
><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>a =
>MIME-compliant mail reader.&nbsp; Different MIME-compliant mail =
>readers</FONT>
><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>exhibit =
>different behavior, especially when dealing with</FONT>
><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
>SIZE=3D2>&quot;multipart&quot; MIME messages (i.e. documents which have =
>been split</FONT>
><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>up into =
>multiple messages), so check your local documentation on</FONT>
><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>how to =
>manipulate these messages.</FONT>
><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=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--