Subject: [Mip6] question on DS-MIPv6 security

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Fri, 1 Jun 2007 12:39:06 +0200

Hi,

A couple of questions to the security model of DS-MIPv6.

The option for BU protection described below in option 2 in a mail cut
from the archives
seems to say UDP ESP tunnel encapsulation (RFC 3948). Is that correctly
understood and if yes
then why would you need a specific port for this usage in DS-MIPv6 ?

******snip*****
To: "Basavaraj Patil" <basavaraj.patil at nsn.com>, "ext Tsirtsis,
George" <tsirtsis at qualcomm.com>, "Sri Gundavelli" <sgundave at
cisco.com>, "Hesham Soliman" <Hesham at elevatemobile.com>, <mip6 at
ietf.org>, <nemo at ietf.org> 
Subject: RE: [Mip6] The use of GRE 
From: "Vijay Devarapalli" <Vijay.Devarapalli at AzaireNet.com> 
Date: Wed, 16 May 2007 14:33:59 -0700 
Cc: 
List-help: <mailto:[email-masked]?subject=help> 
List-id: mip6.ietf.org 
List-post: <mailto:[email-masked]> 
List-subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>,
<mailto:[email-masked]?subject=subscribe> 
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>,
<mailto:[email-masked]?subject=unsubscribe> 
References: <[email-masked]> 
Thread-index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAa6kGYQAInDPQ 
Thread-topic: [Mip6] The use of GRE 

Hello Raj,

We might actually end up with option 2. I see three reserved 
UDP ports with DS-MIPv6 already.

1. One UDP port indicating IPv4/IPv6. You parse the IP version
   field to figure out whether it is IPv4 or IPv6.
2. One UDP port for ESP encapsulation. This happens when you 
   protect DS-MIPv6 traffic with ESP and use UDP encapsulation 
   for NAT traversal. The packet format would be
     IPv4 hdr (src=MN-IPv4-CoA, dst=HA-IPv4)
     UDP hdr
     ESP hdr
     IPv6 (src=MN-IPv6-HoA, dst=CN)
     Payload 
3. One reserved UDP port for GRE encapsulation in DS-MIPv6.

So this is almost option 2. :) Option 2 was one reserved port
per protocol that follows the UDP header.

Vijay
*********************

On the other hand, this option is not described in the DS-MIP draft
which only seems to reference the destination option/routing header
versions
of the BU and not the optional tunneling version from RFC 4877. I find
it a little confusing that optional ways to transmit BU's are described
on the list
and not in the draft - ?
 
Secondly, looking into the destination option/routing header versions of
the BU as described in Section 4.1 of DS-MIP, then these are described
without security
headers, although they in Section 5 of DS-MIP are said to be protected
using IPSec (as in standard [MIP] modulo RFC 4285). In this respect,
I am rather concerned with the processing of the stack:
IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 
UDP header 
IPv6 header (src=V4CoA, dst=HAADDR) 
DST-OPT HAO (IPv6 home address) 
ESP (transport)
Mobility header BU [IPv4 HAO] 

as the appearance of ESP after a transport header will require a not
very nice processing flow in the stack, unless IPSec is made to
understand
"IP" headers of form IP-UDP-IP - Has this been discussed or is it not
perceived as a problem by other implementators ?

I have to admit that I have been away from this list in a very long
time,  and yes, I haven't 
checked the archives all that way back, but I hope you can, at least, 
let me know whether this has been thought through, 
and I just haven't grasped the 
details yet, or whether these details are still being finalized.

Thanks,
Karen

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 1 Jun 2007 21:39:23 +1000

Karen, 
 
Please ignore option 2 below, we're not doing this in the draft. This was
part of a concensus call and we're leaving the draft as is today as a result
of this call. 

Secondly, looking into the destination option/routing header versions of the
BU as described in Section 4.1 of DS-MIP, then these are described without
security

headers, although they in Section 5 of DS-MIP are said to be protected using
IPSec (as in standard [MIP] modulo RFC 4285). In this respect,

as the appearance of ESP after a transport header will require a not very
nice processing flow in the stack, unless IPSec is made to understand

=> I'm not sure I understand the problem you're seeing above. By the time
IPsec gets this packet there would not be IPv4/UDP headers and it would look
like a normal IPsec protected IPv6 packet. 

 Hesham

---

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Fri, 1 Jun 2007 13:59:51 +0200

Hi,
 
The problem, I see,  is the looping from higher transport layer, UDP,
back to IP/IPSec processing. 
 
With ESP UDP encapsulation 
the processing of the full header IP-UDP-IP-IPSEC is kept in the
IP/IPSec layer.
 
BR, Karen

________________________________

	From: Hesham Soliman [mailto:[email-masked]] 
	Sent: 1. juni 2007 13:39
	To: Karen E. Nielsen (AH/LMD); [email-masked]
	Subject: RE: [Mip6] question on DS-MIPv6 security

	Karen, 
	 
	Please ignore option 2 below, we're not doing this in the draft.
This was part of a concensus call and we're leaving the draft as is
today as a result of this call. 

		Secondly, looking into the destination option/routing
header versions of the BU as described in Section 4.1 of DS-MIP, then
these are described without security

		headers, although they in Section 5 of DS-MIP are said
to be protected using IPSec (as in standard [MIP] modulo RFC 4285). In
this respect,

		as the appearance of ESP after a transport header will
require a not very nice processing flow in the stack, unless IPSec is
made to understand

		"IP" headers of form IP-UDP-IP - Has this been discussed
or is it not perceived as a problem by other implementators ?  

		=> I'm not sure I understand the problem you're seeing
above. By the time IPsec gets this packet there would not be IPv4/UDP
headers and it would look like a normal IPsec protected IPv6 packet. 

		 Hesham

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 1 Jun 2007 22:06:03 +1000

Ah, sure, that's a problem if you do implement this in user space. What can
I say, let's hope NATs disappear! Not much else we can do about this. 
 
Hesham

  _____  

From: Karen E. Nielsen (AH/LMD) [mailto:[email-masked]] 
Sent: Friday, June 01, 2007 10:00 PM
To: Hesham Soliman; [email-masked]
Subject: RE: [Mip6] question on DS-MIPv6 security

Hi,
 
The problem, I see,  is the looping from higher transport layer, UDP, back
to IP/IPSec processing. 
 
With ESP UDP encapsulation 
the processing of the full header IP-UDP-IP-IPSEC is kept in the IP/IPSec
layer.
 
BR, Karen

  _____  

Karen, 

 Hesham

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 01 Jun 2007 14:35:28 +0200

> part of a concensus call and we're leaving the draft as is today as a result

Umm -- are you saying that there has been a consensus determination
from the chairs regarding this question, or just that option 2 has
been ruled out?  I'd agree with the latter, but not the former...

	Henrik

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 1 Jun 2007 22:47:17 +1000

The chairs already sent the way forward on the list and I was asked to
update the draft for other issues and leaving it as is for this one. So, yes
a decision was publicly announced on the list a few weeks ago. 

Hesham 

 > -----Original Message-----
 > From: Henrik Levkowetz [mailto:[email-masked]] 
 > Sent: Friday, June 01, 2007 10:35 PM
 > To: Hesham Soliman
 > Cc: [email-masked]
 > Subject: Re: [Mip6] question on DS-MIPv6 security
 > 
 > 
 >

---

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Fri, 1 Jun 2007 15:03:25 +0200

Hi,
 
No, to keep it in IP/IPSec kernel space I guess the options, as you have
discussed on the list, is
specific UDP port for IP-UDP-IP or ESP UDP encapsulation and the option
2 tunnel BU format.
 
I do not want to attempt to reopen this discussion. I have a better idea
about where the spec is now.
Thanks.
 
Karen

	Sent: 1. juni 2007 14:06

	Ah, sure, that's a problem if you do implement this in user
space. What can I say, let's hope NATs disappear! Not much else we can
do about this. 
	 
	Hesham

		From: Karen E. Nielsen (AH/LMD)
[mailto:[email-masked]] 
		Sent: Friday, June 01, 2007 10:00 PM
		To: Hesham Soliman; [email-masked]
		Subject: RE: [Mip6] question on DS-MIPv6 security

		Hi,
		 
		The problem, I see,  is the looping from higher
transport layer, UDP, back to IP/IPSec processing. 
		 
		With ESP UDP encapsulation 
		the processing of the full header IP-UDP-IP-IPSEC is
kept in the IP/IPSec layer.
		 
		BR, Karen

			From: Hesham Soliman
[mailto:[email-masked]] 
			Sent: 1. juni 2007 13:39
			To: Karen E. Nielsen (AH/LMD); [email-masked]
			Subject: RE: [Mip6] question on DS-MIPv6
security

			Karen, 
			 
			Please ignore option 2 below, we're not doing
this in the draft. This was part of a concensus call and we're leaving
the draft as is today as a result of this call. 

				Secondly, looking into the destination
option/routing header versions of the BU as described in Section 4.1 of
DS-MIP, then these are described without security

				headers, although they in Section 5 of
DS-MIP are said to be protected using IPSec (as in standard [MIP] modulo
RFC 4285). In this respect,

				I am rather concerned with the
processing of the stack: 

				as the appearance of ESP after a
transport header will require a not very nice processing flow in the
stack, unless IPSec is made to understand

				"IP" headers of form IP-UDP-IP - Has
this been discussed or is it not perceived as a problem by other
implementators ?  

				=> I'm not sure I understand the problem
you're seeing above. By the time IPsec gets this packet there would not
be IPv4/UDP headers and it would look like a normal IPsec protected IPv6
packet. 

				 Hesham

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 01 Jun 2007 21:32:02 +0200

Hi Hesham,

> a decision was publicly announced on the list a few weeks ago. 

Are you referring to Raj's mail of 2007-05-16, with the title
"Re: [Mip6] The use of GRE" ?

If so, then we have a problem here.  The discussion continued
after that mail; that mail was neither in title nor in the text
announcing a consensus call, and if you have received instructions
to update the draft based on that mail as a consensus call,
I'll have to challenge those instructions.

	Henrik

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 01 Jun 2007 14:38:09 -0500

Well... Maybe there was not a final summary note sent out to close that
discussion. Let me send one now.

-Raj

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 4 Jun 2007 14:36:02 -0700

Hello Karen,

The stuff that you cut and pasted from an earlier mail of mine
shows reverse tunneled IPsec protected DS-MIPv6 traffic when 
the mobile node is attached to an IPv4 access network. Nothing 
about a binding update.

If a mobile node chooses to reserve tunnel IPv6 traffic with ESP
protection when it is attached to an IPv6 access network, the 
packet format would be as follows.

     IPv6 hdr (src=MN-IPv6-CoA, dst=HA-IPv6) 
     ESP hdr 
     IPv6 (src=MN-IPv6-HoA, dst=CN) 
     Payload 

If the same mobile node ends up on an IPv4 access network, the 
packet format for the same traffic flow will be as follows.

If the payload traffic does not need ESP tunnel mode protection,
then the packet formats would be (when the mobile node is on an 
IPv6 access network)

    IPv6 hdr (src=MN-IPv6-CoA, dst=HA-IPv6) 
    IPv6 (src=MN-IPv6-HoA, dst=CN) 
    Payload 

and (when the mobile node is on an IPv4 access network)

Vijay

> Sent: Friday, June 01, 2007 3:39 AM
> To: [email-masked]
> Subject: [Mip6] question on DS-MIPv6 security
> 
> Hi, 
> 
> The option for BU protection described below in option 2 in a 
> mail cut from the archives 
> seems to say UDP ESP tunnel encapsulation (RFC 3948). Is that 
> correctly understood and if yes 
> To: "Basavaraj Patil" <basavaraj.patil at nsn.com>, "ext 
> Tsirtsis, George" <tsirtsis at qualcomm.com>, "Sri 
> Gundavelli" <sgundave at cisco.com>, "Hesham Soliman" <Hesham 
> at elevatemobile.com>, <mip6 at ietf.org>, <nemo at ietf.org> 
> 
> List-help: <mailto:[email-masked]?subject=help 
> <mailto:[email-masked]?subject=help> > 
> List-id: mip6.ietf.org 
> List-post: <mailto:[email-masked] <mailto:[email-masked]> > 
> List-subscribe: <https://www1.ietf.org/mailman/listinfo/mip6 
> <https://www1.ietf.org/mailman/listinfo/mip6> >, 
> <mailto:[email-masked]?subject=subscribe 
> <mailto:[email-masked]?subject=subscribe> > 
> List-unsubscribe: 
> <https://www1.ietf.org/mailman/listinfo/mip6 
> <https://www1.ietf.org/mailman/listinfo/mip6> >, 
> <mailto:[email-masked]?subject=unsubscribe 
> <mailto:[email-masked]?subject=unsubscribe> > 
> Thread-index: 
> AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAa6kGYQAInDPQ 
> On the other hand, this option is not described in the DS-MIP 
> draft which only seems to reference the destination 
> option/routing header versions
> 
> of the BU and not the optional tunneling version from RFC 
> 4877. I find it a little confusing that optional ways to 
> transmit BU's are described on the list
> 
> and not in the draft - ? 
>   
> Secondly, looking into the destination option/routing header 
> versions of the BU as described in Section 4.1 of DS-MIP, 
> then these are described without security
> 
> headers, although they in Section 5 of DS-MIP are said to be 
> protected using IPSec (as in standard [MIP] modulo RFC 4285). 
> In this respect,
> 
> require a not very nice processing flow in the stack, unless 
> IPSec is made to understand
> 
> "IP" headers of form IP-UDP-IP - Has this been discussed or 
> is it not perceived as a problem by other implementators ? 
> 
> I have to admit that I have been away from this list in a 
> very long time,  and yes, I haven't

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 4 Jun 2007 14:40:09 -0700

Karen,

RFC 4877 allows the use of ESP both in transport and tunnel mode
protecting the Binding Update. The packet formats are already
listed in 4877.

The DS-MIPv6 spec shows the introduction of UDP header but only
shows the use of ESP transport mode. ESP tunnel mode with UDP
header is also possible. It is not however shown explicitly in
the DS-MIPv6 specification.

Vijay

> Sent: Friday, June 01, 2007 6:03 AM
> No, to keep it in IP/IPSec kernel space I guess the options, 
> as you have discussed on the list, is
> specific UDP port for IP-UDP-IP or ESP UDP encapsulation and 
> the option 2 tunnel BU format.
>  
> I do not want to attempt to reopen this discussion. I have a 
> better idea about where the spec is now.
> Thanks.
>  
> Karen
>  
>  
> 
> 
> 	Ah, sure, that's a problem if you do implement this in 
> user space. What can I say, let's hope NATs disappear! Not 
> much else we can do about this. 
> 	 
> 	Hesham
> 
> 
> 		the processing of the full header 
> IP-UDP-IP-IPSEC is kept in the IP/IPSec layer.
> 		 
> 		BR, Karen
> 
> 
> 			Please ignore option 2 below, we're not 
> doing this in the draft. This was part of a concensus call 
> and we're leaving the draft as is today as a result of this call. 
> 
> 
> 				Secondly, looking into the 
> destination option/routing header versions of the BU as 
> described in Section 4.1 of DS-MIP, then these are described 
> without security
> 
> 				headers, although they in 
> Section 5 of DS-MIP are said to be protected using IPSec (as 
> in standard [MIP] modulo RFC 4285). In this respect,
> 
> 				as the appearance of ESP after 
> a transport header will require a not very nice processing 
> flow in the stack, unless IPSec is made to understand
> 
> 				"IP" headers of form IP-UDP-IP 
> - Has this been discussed or is it not perceived as a problem 
> by other implementators ?  
> 
> 				=> I'm not sure I understand 
> the problem you're seeing above. By the time IPsec gets this 
> packet there would not be IPv4/UDP headers and it would look

---

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Wed, 6 Jun 2007 09:14:47 +0200

Hi Vijay,

Thanks.

Yes I understand this. What I think is important however is also 
the relation to IPSec. I.e., one thing is the packet format another
issue is
what the packet format represents and how it is negotiated.

For example, as far as I understand it anyway, then using the standard
ESP transport protection 
for BU in DS-MIP means that one can use IPSec SA's agreed on beforehand
in-between the HA and the MN,
as these are anchored on the Home Addresses. However if the optional
tunnel mode encapsulation is used,
one will use IKEv2 to detect NAT traversal and establish the appropriate
SAs (ESP tunnel or ESP UDP tunnel, and now
also IPv4 or IPv6 transport layer) after which the BU can be
authenticated - Right ?

BTW. How is it thought that HA and MNs will decide upon which BU
protection mechanism and thus packet format to
use - the standard or the optional ? 

Thanks,

Karen

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: 4. juni 2007 23:36
> The stuff that you cut and pasted from an earlier mail of 
> mine shows reverse tunneled IPsec protected DS-MIPv6 traffic 
> when the mobile node is attached to an IPv4 access network. 
> Nothing about a binding update.
> 
> If a mobile node chooses to reserve tunnel IPv6 traffic with 
> ESP protection when it is attached to an IPv6 access network, 
> the packet format would be as follows.
> 
> If the same mobile node ends up on an IPv4 access network, 
> the packet format for the same traffic flow will be as follows.
> 
> If the payload traffic does not need ESP tunnel mode 
> protection, then the packet formats would be (when the mobile 
> node is on an
> IPv6 access network)
> 
> > from the archives seems to say UDP ESP tunnel encapsulation (RFC 
> > 3948). Is that correctly understood and if yes then why 
> would you need 
> > a specific port for this usage in DS-MIPv6 ?
> > 
> > ******snip*****
> > We might actually end up with option 2. I see three 
> reserved UDP ports 
> > with DS-MIPv6 already.
> > 
> > So this is almost option 2. :) Option 2 was one reserved port per 
> > protocol that follows the UDP header.
> > 
> > Vijay
> > *********************
> > 
> 4877. I find 
> > it a little confusing that optional ways to transmit BU's are 
> > described on the list
> > 
> > and not in the draft - ? 
> >   
> header versions 
> > of the BU as described in Section 4.1 of DS-MIP, then these are 
> > described without security
> > 
> > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP header
> require a not 
> is it not 
> > time,  and yes, I haven't checked the archives all that way 
> back, but 
> > I hope you can, at least, let me know whether this has been thought 
> > through, and I just haven't grasped the details yet, or 
> whether these 
> > details are still being finalized.
> > 
> > Thanks,
> > Karen
> > 
> > 
> > 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Jun 2007 11:11:20 +0200

Vijay Devarapalli wrote:
> protecting the Binding Update. The packet formats are already listed 
> in 4877.
> 
> The DS-MIPv6 spec shows the introduction of UDP header but only shows
>  the use of ESP transport mode. ESP tunnel mode with UDP header is 
> also possible. It is not however shown explicitly in the DS-MIPv6 
> specification.

Vijay I don't see in DS-MIPv6 spec any picture with ESP, IPv6 and UDPv4
headers - what do you mean?  (I see pictures with IPv6, IPv4 and UDP
headers, but not ESP). draft-ietf-mip6-nemo-v4traversal-04.txt

RFC4877 "Mobile IPv6 with IKEv2 and IPsec" is only about IPv6 and
IPv6-in-IPv6, not IPv4; as I read it.

Alex

> 
> Vijay
> 
>> -----Original Message----- From: Karen E. Nielsen (AH/LMD) 
>> [mailto:[email-masked]] Sent: Friday, June 01, 2007 
>> 6:03 AM To: Hesham Soliman; [email-masked] Subject: RE: [Mip6] 
>> question on DS-MIPv6 security
>> 
>> Hi,
>> 
>> No, to keep it in IP/IPSec kernel space I guess the options, as you
>>  have discussed on the list, is specific UDP port for IP-UDP-IP or 
>> ESP UDP encapsulation and the option 2 tunnel BU format.
>> 
>> I do not want to attempt to reopen this discussion. I have a better
>>  idea about where the spec is now. Thanks.
>> 
>> Karen
>> 
>> 
>> 
>> 
>> From: Hesham Soliman [mailto:[email-masked]] Sent: 1. 
>> juni 2007 14:06 To: Karen E. Nielsen (AH/LMD); [email-masked] 
>> Subject: RE: [Mip6] question on DS-MIPv6 security   Ah, sure, 
>> that's a problem if you do implement this in user space. What can I
>>  say, let's hope NATs disappear! Not much else we can do about
>> this. Hesham
>> 
>> 
>> [mailto:[email-masked]] Sent: Friday, June 01, 2007 
>> 10:00 PM To: Hesham Soliman; [email-masked] Subject: RE: [Mip6] 
>> question on DS-MIPv6 security   Hi,  The problem, I see,  is the 
>> looping from higher transport layer, UDP, back to IP/IPSec 
>> processing.  With ESP UDP encapsulation the processing of the full 
>> header IP-UDP-IP-IPSEC is kept in the IP/IPSec layer.  BR, Karen
>> 
>> 
>> From: Hesham Soliman [mailto:[email-masked]] Sent: 1. 
>> juni 2007 13:39 To: Karen E. Nielsen (AH/LMD); [email-masked] 
>> Subject: RE: [Mip6] question on DS-MIPv6 security   Karen,  Please 
>> ignore option 2 below, we're not doing this in the draft. This was 
>> part of a concensus call and we're leaving the draft as is today as
>>  a result of this call.
>> 
>> 
>> versions of the BU as described in Section 4.1 of DS-MIP, then 
>> protected using IPSec (as in standard [MIP] modulo RFC 4285). In 
>> this respect,
>> 
>> I am rather concerned with the processing of the stack: IPv4 header
>>  (src=V4ADDR, dst=HA_V4ADDR) UDP header IPv6 header (src=V4CoA, 
>> dst=HAADDR) DST-OPT HAO (IPv6 home address) ESP (transport) 
>> as the appearance of ESP after a transport header will require a 
>> not very nice processing flow in the stack, unless IPSec is made to
>>  understand
>> 
>> "IP" headers of form IP-UDP-IP - Has this been discussed or is it 
>> not perceived as a problem by other implementators ?
>> 
>> => I'm not sure I understand the problem you're seeing above. By 
>> the time IPsec gets this packet there would not be IPv4/UDP headers
>>  and it would look like a normal IPsec protected IPv6 packet.
>> 
>> Hesham
>> 
>> 
> 
> _______________________________________________ Mip6 mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________