Subject: [nemo] DSMIPv6 and IKE - Summary and call for concensus

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 26 Oct 2007 00:01:06 +1000

Folks,

This discussion has been going on for a while and I'm sure it wasn't for
easy to follow. 
This email contains a summary of the discussion so far and a call for
comment/concensus. Please respond promptly because there is some pressure
from 3GPP to get this draft out very soon. 

The issue is how to run IKE in combination with DSMIPv6 in a private
IPv4-only network. If you want more detail about why this is a problem
please look at the thread "DSMIPv6 and IKE". 

There are three types of solutions that we discussed. A quick summary of
each below:

1. The Virtual link approach. In this case IKE runs over v6 only and is
completely unaware of the IPv4 network. As a result IKE's NAT traversal is
never invoked. Only DSMIPv6's NAT traversal is used. In this approach, the
DSMIPv6 implementation in the HA is required to cache the outer IPv4 address
and source port of the IPv4 message that contains IKE, then append them to
the response from its own IKE daemon. This is basically done to hide the
IPv4 network from IKE and effectively disable its NAT traversal, which
solves our problem. 
Three people agreed with this approach but two people (I'm including
Christian) are against it. So there doesn't seem to be concensus on this. I
believe the concern here was that the HA's caching of the outer address and
port was complex for the implementation.

2. Karen suggested a way of running IKE without any changes (again see the
thread for details). In this approach DSMIPv6 BUs are secured with ESP as
usual. Normal traffic is sent over the DSMIPv6 port. However, secure traffic
is sent over the IKE port (4500). The result of this approach is that it
takes two messages to complete a handover, one from DSMIPv6 (BU) and an
update from IKE (for the secure traffic). The concern that I had here in the
discussion with Karen was the number of messages and the delays associated
for that. Of course IKE doesn't do movement detection ...etc. So my concern
is the discriminatory experience of the handover for different parts of the
traffic. 

3. The third class of solutions involves either modifying MIPv6 (adding new
messages) or IKE or both. I'm only including this for completeness, no one
really wants this. 

Please send your comments on the above. Basically the options are 1 or 2. In
theory we could do both but I think it's best to pick one method for this to
avoid interoperability issues and additional complexity. 

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 25 Oct 2007 22:42:13 -0700

Hi Hesham,

IMO, we should go with solution 2) below. I prefer that we let
IKEv2 use its own NAT traversal mechanism. Regarding two round
trips during a handover, note that the IKEv2 exchange to
re-establish the IKEv2 SA and the IPsec SAs is not in the
critical path of handover. The BU/BAck messages can be exchanged
with the existing IPsec SAs. The IKEv2 exchange can be happen a
few seconds (or minutes) after the handover. So there is *no*
impact on the handover.

This would be the same as the lack of support for the "K" flag
in RFC 3775. In RFC 3775, if either the mobile node or the home
agent are not capable of updating the IKE SA based on the
exchange of BU/BAck, there is always an IKE exchange after the
handover (or whenever the CoA changes).

Please let me know if I am missing something related to the
impact of the IKEv2 exchange on the handover.

I am not comfortable with the temporary tunnel created in
solution 1).

Vijay

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

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 26 Oct 2007 16:19:23 +1000

> critical path of handover. 

=> It is in the critical path for the secure packets. That's what the
discussion was about.

   The BU/BAck messages can be exchanged
 > few seconds (or minutes) after the handover. So there is *no*

=> No, see above. This is only good for insecure traffic. At least this is
not solution 2 below.

Hesham

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 25 Oct 2007 23:38:57 -0700

Hi Hesham,
A few comments inline.  

> -----Original Message-----
> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Thursday, October 25, 2007 7:01 AM
> To: [email-masked]; [email-masked]
> Subject: [Mip6] DSMIPv6 and IKE - Summary and call for concensus
> 
> Folks,
> 
> This discussion has been going on for a while and I'm sure it 
> wasn't for easy to follow. 
> This email contains a summary of the discussion so far and a 
> call for comment/concensus. Please respond promptly because 
> there is some pressure from 3GPP to get this draft out very soon. 
> 
> The issue is how to run IKE in combination with DSMIPv6 in a 
> private IPv4-only network. If you want more detail about why 
> this is a problem please look at the thread "DSMIPv6 and IKE". 
> 
> There are three types of solutions that we discussed. A quick 
> summary of each below:
> 
> 1. The Virtual link approach. In this case IKE runs over v6 
> only and is completely unaware of the IPv4 network. As a 
> result IKE's NAT traversal is never invoked. Only DSMIPv6's 
> NAT traversal is used. In this approach, the
> DSMIPv6 implementation in the HA is required to cache the 
> outer IPv4 address and source port of the IPv4 message that 
> contains IKE, then append them to the response from its own 
> IKE daemon. This is basically done to hide the
> IPv4 network from IKE and effectively disable its NAT 
> traversal, which solves our problem. 
> Christian) are against it. So there doesn't seem to be 
> concensus on this. I believe the concern here was that the 
> HA's caching of the outer address and port was complex for 
> the implementation.
> 

I'm not as concerned about the complexity aspect, but, I'm more
concerned about the changes to the IPsec architecture this brings.  I
think this solution requires an SPD bypass rule to be setup for the
DSMIP6 port that will first allow MIP6 to process the packets before
IPsec has a chance to apply the SPD rule for BU.  It is strange in that
the IPsec protection is somehow sought for packets from the trusted
boundary (i.e., MIP6 to IPsec in the same box) rather than the untrusted
boundary (the packet coming in from the untrusted portion is the one to
the DSMIP6 port and that is bypassed).  One could argue that this isn't
a big deal, but, given IPsec's design of inspecting all packets coming
from the untrusted boundary first, it does make me uncomfortable to skew
that. 

> 2. Karen suggested a way of running IKE without any changes 
> (again see the thread for details). In this approach DSMIPv6 
> BUs are secured with ESP as usual. Normal traffic is sent 
> over the DSMIPv6 port. However, secure traffic is sent over 
> the IKE port (4500). The result of this approach is that it 
> takes two messages to complete a handover, one from DSMIPv6 
> (BU) and an update from IKE (for the secure traffic). The 
> concern that I had here in the discussion with Karen was the 
> number of messages and the delays associated for that. Of 
> course IKE doesn't do movement detection ...etc. So my 
> concern is the discriminatory experience of the handover for 
> different parts of the traffic. 
> 

Sorry to say that I have not yet caught up on this solution fully and
so, am unable to comment on it yet.  From your recent email, it sounds
like we have two roundtrips in the critical path, if the data is to be
secured with IPsec as well.  Can these roundtrips be in parallel or are
they sequential?  If they  need to be sequential, I think that is a big
enough negative impact on handoff times.  If they can be parallel and
can be processed out of order at the HA, I'd be less concerned with it. 

> messages) or IKE or both. I'm only including this for 
> completeness, no one really wants this. 
> 

I'm not sure I understand this part.  We are adding new functionality to
MIP6 to support DSMIP6.  And, we are adding NAT-T to MIP6 specifically
for that.  Given that, why is it a big deal to support a new message in
MIP6 for this sake?  This also makes the udpates need two messages, but,
in this case, it definitely can be parallel and processed out of order
and hence, there is no impact on handoff times.  

Vidya

> Please send your comments on the above. Basically the options 
> are 1 or 2. In theory we could do both but I think it's best 
> to pick one method for this to avoid interoperability issues 
> and additional complexity. 
> 
> Hesham
> 
> 
> 
>

---

From: <[email-masked]>
Date: Fri, 26 Oct 2007 09:03:00 +0200

Hi,

> => No, see above. This is only good for insecure traffic. At 

Actually secure traffic from the MN towards the HA is not impacted by
the delay,
but it is true that secure traffic in the HA to MN direction is
impacted. It will
not function until the HA IPSEC SA has been upated with the correct
ports and addresses and this will not happen until one of the following
two things has happened:

* the MN has send secure traffic towarsd the HA
* the MN has initiated an IKE_SA update exchange 

Karen

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 26 Oct 2007 17:05:44 +1000

> from the untrusted boundary first, it does make me 

=> I really don't get two things about your comment:
A. The packet format is the same for both alternatives so I'm not sure if
this is a general comment or specific to this alternative. It shouldn't be
the latter. 
B. How are we bypassing anything in IPsec? I mean, there is no more
bypassing here than the processing of the routing header in MIP6. Simply
removing the outer IPv4 header, which can never be protected by IPsec, is
not bypassing it. I don't get that.

 > enough negative impact on handoff times.  If they can be parallel and

=> They can definitely be in parallel, but I don't think IKE knows enough
about movement to do this in any timely manner. So, it makes the handover of
the secure traffic non-deterministic. Sorry if I gave that impression (that
they have to be sent sequentially). 

 > and hence, there is no impact on handoff times.  

=> Well, we already have the two message solution, so why invent another two
message case that need to be secured ...etc? 

Hesham

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 26 Oct 2007 17:07:04 +1000

> Actually secure traffic from the MN towards the HA is not impacted by

=> Yes of course, but we normally measure the handover delay ignoring the
direction of traffic. 

Hesham

---

From: <[email-masked]>
Date: Fri, 26 Oct 2007 09:51:10 +0200

Hi,

With respect to the latter then I believe that we should choose one
solution 
and one solution only for interoperability reasons.

I am in favor of solution 2. 

Solution 1. breaks with the paradigm of standard MIPv6 that IKE is run
on the CoA level and I think that we should keep this basic paradigm.

This allow us to build the DSMIP NAT traversal mechanism with the
standard NAT traversal mechanism of the protocols we are using (IPSEC
and IKE)
and giving NATs and the complexity of things, I think that it is very
wise to
build as much as possible with standard building blocks.
(This also allows for future interworking with MOBIKE if ever desired)

I would like to spend a few words giving some additional details of 
the characteristics of the solutions which perhaps is not clear form the
summary.

Solution 1:

Secure Tunneling of payload:

Secure Traffic will is in this situation be send with two IP tunneling
headers, the DSMIP one (which IKE and IPSec is oblivious to) and the
IPSec tunnel header, that is:

IPv4 header 
UDP header 
IPv6 header (src=V6HOA, dst=HAADDR)
ESP
IPv6 (src=v6Hoa, dst=CNADDR)
Payload Data

the IPSEc protocol being a standard 4301 ESP tunnel.

Solution 2:

Secure Tunneling of payload:

Secure Traffic will 
is in this situation be 
send with RFC 3948 IPSec tunneling, that is

IPv4 header 
UDP header 
ESP
IPv6 (src=v6Hoa, dst=CNADDR)
Payload Data

Update of IKE_SA and IPSec Sas:

The IPSEc transport ESP used to protect the BU/BACK exchange 
is the same as in solution 1 and seen in isolation it survives
movements. 
But in order for it to be refreshed (and simply for it not to be torn
down at some point) the IKE_SA must be updated after the movement.

The IPSec RFC 3948 has the same dependency towards the IKE_SA but
in addition the IPSec RFC 3948 only 
functions when a NAT mapping has been created
for UDP 4500 communication in between HA and MN, and the
IPSec SA (HA side) has been updated with this information.

The basic principle of solution 2 is to perform the
updating on the IKE_SA and the IPSec RFC 3948 SA AFTER the BU/BACK
exchange.
This is a modular and robust approach, BUT it introduces delay.

The IKE_SA is first updated and the IPSec tunnel will first be fully
operational in both directions, when either of the followings has
happened:

*A secure packet from the MN has arrived and has been processed at the
HA
*An authenticated IKE packet from the MN carrying NAT configuration
options in 
IKE payload has arrived and has been processed at the HA.

BR, Karen

> Sent: Thursday, October 25, 2007 4:01 PM
> summary of
> only and is
> outer IPv4 address
> concensus on this. I
> (again see the
> (BU) and an
> are 1 or 2. In

---

From: <[email-masked]>
Date: Fri, 26 Oct 2007 11:16:41 +0200

Hi,
 
 Can these roundtrips be in 
>  > parallel or are

With the IKEv2 RFC in hand, and only the RFC - NOT individual
implementations,
then with minimal interpretation of section 2.23 of RFC 4306, the update
cannot be done in parallel, the HA MUST process the BU and make some
changes in the IKE_SA and the IPSEC tunnel SAS before a single IKE
exchange can update the IKE_SAs and the RFC 3948 IPSec SAs
appropriately.

If we are speaking of a full new IKE_SA establishment and a new IPsec
tunnel SA
creation (means 2 extra RTTs) then this can be done in parallel.

With MOBIKE, the update can be done in parallel and would only detail
one
exchange.

BR, Karen

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 26 Oct 2007 20:49:06 +1000

Thanks Karen for the clarification. So, we have two cases here:
1. Standard IKEv2 = Sequential updates
2. Mobike = parallel updates. 

Hesham 

 > From: [email-masked] 
 > [mailto:[email-masked]] 
 > Sent: Friday, October 26, 2007 7:17 PM
 > To: [email-masked]; [email-masked]; 
 > [email-masked]; [email-masked]
 > Subject: RE: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and 
 > call for concensus
 > 
 > Hi,
 >

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 29 Oct 2007 17:33:10 -0700

Thanks Hesham.

I think I mixed up solution 2 described below in your email with
solution 2 described in an email you sent on the 17th of October.
http://www1.ietf.org/mail-archive/web/mip6/current/msg06856.html

I do want to avoid two round trips during every handover. I also want
to avoid running MOBIKE at the same time as MIPv6. Does not make sense.

Having said, I would like to figure out whats wrong with running IKEv2
on port 4500, but sending the BU on DS-MIPv6 port with a transport mode
SA.

Lets say IKEv2 runs on UDP port 4500 always and negotiates a transport
mode SA for protecting the BU.

When the BU packet goes through the SPD entries, the transport mode SA
is picked. After IPsec processing the packet will be as follows

IPv6 hdr (src=V6HOA, dst=HAADDR)
ESP Hdr
BU
   IPv4 CoA option

With DS-MIPv6 encapsulation the packet becomes

IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR)
UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT)
IPv6 hdr (src=V6HOA, dst=HAADDR)
ESP Hdr
BU
   IPv4 CoA option

Now lets assume the mobile node moves and attaches to another IPv4
access network. The transport mode IPsec SA is still valid. IKEv2
does not know that the mobile node moved, its IPv4 address changed
or if there is a new NAT in the path. So the mobile node can send
a BU right away as follows.

IPv4 hdr (src=new_V4ADDR, dst=HA_V4ADDR)
UDP hdr (srcport=DS-MIPv6-PORT, dstport=DS-MIPv6-PORT)
IPv6 hdr (src=V6HOA, dst=HAADDR)
ESP Hdr
BU
   IPv4 CoA option (new IPv4 CoA)

When the HA receives the BU, the packet will appear like the following

IPv4 hdr (src=NATTED_new_V4ADDR, dst=HA_V4ADDR)
UDP hdr (srcport=NATTED_DS-MIPv6-PORT, dstport=DS-MIPv6-PORT)
IPv6 hdr (src=V6HOA, dst=HAADDR)
ESP Hdr
BU
   IPv4 CoA option (new IPv4 CoA)

The HA would process the BU and respond to the NATTED_DS-MIPv6-PORT.

Meanwhile the MIPv6 stack on the mobile node will trigger the IKEv2
daemon on the mobile node to re-run IKEv2. This is because the original
IKEv2 SA is not valid anymore. When the IKEv2 SAs are re-negotiated, new
IPsec SAs are also setup.

This would allow the IKEv2 exchange to happen out of the critical path.
There is no update to the IKEv2 SA based on the BU/BAck exchange. There
are no tunnel mode SAs created for any MIPv6 signaling messages. What
am I missing now?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 29 Oct 2007 17:34:09 -0700

[email-masked] wrote:
> ports and addresses 

But why? I thought this was a transport mode SA keyed on the IPv6 home
address of the mobile node.

Vijay

and this will not happen until one of the following

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 29 Oct 2007 17:38:01 -0700

Karen,

I am not sure if you are talking about a transport mode SA or tunnel
mode SA to protect the BU. You have used both in your emails.

Vijay

---

From: <[email-masked]>
Date: Tue, 30 Oct 2007 08:27:46 +0100

Hi Vijay,

I am talking transport ESP to protect BU/BACK.
Tunnel mode ESP to protect payload.

Karen 

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Tuesday, October 30, 2007 1:38 AM
> To: Nielsen Karen E
> Cc: [email-masked]; [email-masked]
> Subject: Re: [nemo] RE: [Mip6] DSMIPv6 and IKE - Summary and 
> call for concensus
> 
> Karen,
>

---

From: <[email-masked]>
Date: Tue, 30 Oct 2007 08:41:19 +0100

Hi Vijay, 

> address of the mobile node.

Yes, the transport mode SA's are,
but the tunnel mode SAs for payload
protection are not in the scenario I am considering.

The delay I am speaking about is related uniquely to the transport mode
SAs
(as well as of course to rekeying and such of the transport mode SAs,
whenever that is needed.)

I, myself, is not very concerned with delay associated with tunnel mode
IPSec protection from HA to MN. Especially given that Route Optimization

is not relevant for DSMIP. Read, the only case, I am aware off, where
tunnel
mode protection is required by the MIP standard (MUST). Yes there are
multicast and other things, but is it really crucial if we have a delay
there (?).

Karen

---

From: <[email-masked]>
Date: Tue, 30 Oct 2007 08:56:22 +0100

> Sent: Tuesday, October 30, 2007 1:33 AM
> To: Hesham Soliman; Nielsen Karen E; Kaas-Petersen Christian
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Mip6] DSMIPv6 and IKE - Summary and call for concensus
> 
> Thanks Hesham.
> 

Delay associated with tunnel SAs for payload protection.

Karen

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 30 Oct 2007 08:14:37 -0700

> Delay associated with tunnel SAs for payload protection.

Can we then first conclude that we don't have an issue for
completing the BU/BAck exchange?

IPsec ESP protection in tunnel mode for payload packets is
optional after all.

Vijay

---

From: <[email-masked]>
Date: Tue, 30 Oct 2007 21:12:07 +0100

Hi Vijay, 

> IPsec ESP protection in tunnel mode for payload packets is

Couldn't agree more !

Karen

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 30 Oct 2007 13:32:56 -0700

It appears to me that we don't really need to change anything for
sending BU/BAck as long as we run IKEv2 on port 4500 and negotiate
a transport mode SA keyed on the IPv6 home address for protecting
the BU/BAck.

Now coming to payload protection using ESP in tunnel mode, there
is an issue. Payload packets are always sent as follows

   IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR)
   UDP hdr (dstport=4500)
   ESP hdr
   IPv6 hdr (src=V6HOA, dst=CN_V6)
   Payload

If IPv4 packets are being sent, the packet format would be as
follows.

   IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR)
   UDP hdr (dstport=4500)
   ESP hdr
   IPv4 hdr (src=V4HOA, dst=CN_V4)
   Payload

So in this case, we are using IPsec NAT traversal. We need IKEv2
to run after every handover before packets can sent/received. Note
that the BU/BAck exchange happens immediately without any impact.

Note that if tunnel mode ESP protection is not being used for the
payload traffic, the packet format would be as follows.

   IPv4 hdr (src=V4ADDR, dst=HA_V4ADDR)
   UDP hdr (dstport=DS-MIPv6-PORT)
   ESP hdr
   IPv6 hdr (src=V6HOA, dst=CN_V6)
   Payload

One option would be to live with this. Payload protection is
optional anyway. If you have a secure access link, then you don't
really need to encrypt payload traffic.

But if you still want to use ESP tunnel mode encryption for the
payload, we need a solution. One solution is for the home agent to
treat the handover as if the NAT box on the path rebooted (or lost
state) and came up with a new NATted IPv4 address and source port
for the payload packets sent by the mobile node. The home agent
just accepts the packets and responds to the new NATTED port. The
home agent can do this for a configurable amount of time while
waiting for a fresh IKEv2 exchange to update the NAT traversal
information.

Vijay

---

From: <[email-masked]>
Date: Tue, 30 Oct 2007 21:36:05 +0100

Hi Vijay, 

> Sent: Tuesday, October 30, 2007 9:33 PM
> To: Nielsen Karen E; [email-masked]; Kaas-Petersen Christian
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Payload protection and NAT traversal
> 

Yes, I agree, this is exactly and indeed what I have said.

Karen

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 31 Oct 2007 10:30:43 +1000

This is exactly what we've been discussing, except you took out the case of
protection of payload packets. So the solution you list below cannot be
compared with alt 1 or 2 because it only addresses part of the problem, i.e.
no payload security. 

Hesham 

 > Sent: Tuesday, October 30, 2007 10:33 AM
 > To: Hesham Soliman; [email-masked]; 
 > [email-masked]

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 31 Oct 2007 10:38:02 +1000

> waiting for a fresh IKEv2 exchange to update the NAT traversal

=> These are all options, true. So you're saying the HA stores both sets of
information for a short time? Because the change could also be a DoS, so
until a timeout takes place the HA wouldn't know whether it was a genuine
change or an attack.

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 30 Oct 2007 16:49:28 -0700

Hesham Soliman wrote:
> protection of payload packets. 

hmm... are you sure? You said a couple of times that sending a BU
would take two round trips for solution 2.

> So the solution you list below cannot be
> compared with alt 1 or 2

Neither solution 1 nor 2 will work for payload security when you
use ESP in tunnel mode for the payload packets.

 >  because it only addresses part of the problem, i.e.
> no payload security. 

Note that providing payload security was never a requirement.

Vijay

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 31 Oct 2007 10:53:47 +1000

> would take two round trips for solution 2.

=> No, I said the handover would take 2 RTTs. 

 > use ESP in tunnel mode for the payload packets.

=> Sure they will, Karen already sent the packet formats. Solution 2 uses
port 4500 for tunnel mode, hence the entire discussion about 2 RTT
handovers. 

 > Note that providing payload security was never a requirement.

=> You mean for DSMIPv6? I think we have to be realistic. I don't think it
makes sense to use MIP6 and Mobike at the same time just so we can encrypt
payload traffic. I think you agreed with that in your last email. So, if you
don't want that then you need to figure out how to secure payload traffic.
Otherwise, the solution we have will only look good on paper. 

Hesham

 > >  > >  > > This discussion has been going on for a while 
 > and I'm sure 
 > >  > >  > it wasn't for
 > >  > >  > > easy to follow.
 > >  > >  > > This email contains a summary of the discussion 
 > so far and 
 > >  > >  > a call for
 > >  > >  > > The issue is how to run IKE in combination with 
 > DSMIPv6 in 
 > >  > >  > a private
 > >  > >  > > IPv4-only network. If you want more detail about 
 > why this 
 > >  > >  > is a problem
 > >  > >  > > completely unaware of the IPv4 network. As a 
 > result IKE's 
 > >  > >  > NAT traversal is
 > >  > >  > > Three people agreed with this approach but two 
 > people (I'm 
 > >  > >  > including
 > >  > >  > > believe the concern here was that the HA's 
 > caching of the 
 > >  > >  > outer address and
 > >  > >  > > update from IKE (for the secure traffic). The 
 > concern that 
 > >  > >  > I had here in the
 > >  > >  > > 3. The third class of solutions involves either 
 > modifying 
 > >  > >  > MIPv6 (adding new
 > >  > >  > > theory we could do both but I think it's best to 
 > pick one 
 > >  > >  > method for this to

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 30 Oct 2007 17:03:51 -0700

> => No, I said the handover would take 2 RTTs. 

Ok never mind then. BU/BAck exchange does not require two round trips.

> port 4500 for tunnel mode, hence the entire discussion about 2 RTT

I repeat, none of the solutions work as long as you use ESP UDP
encapsulation (port 4500) for the payload traffic to the CN.

> Otherwise, the solution we have will only look good on paper. 

RFC 3775, 3776 and 4877 say ESP protection for payload traffic is
optional. If you have a secure access link or if you application
layer security obviously you don't need to encrypt all traffic
reverse tunneled through the home agent.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 30 Oct 2007 17:04:22 -0700

> until a timeout takes place the HA wouldn't know whether it was a genuine

You are supposed to deal with intermediate NATs losing state and
allocating new NATed source address and source port anyway. Nothing
new.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 30 Oct 2007 19:12:51 -0500

But Hesham... Do we need to solve the payload security issue?
I thought the MIP6 signaling security was what was being tackled.

0Raj

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 31 Oct 2007 11:44:58 +1000

> encapsulation (port 4500) for the payload traffic to the CN.

=> CN? No one is talking about sending anything to the CN.

 > reverse tunneled through the home agent.

=> Interesting opinion, so you don't think there is a need for VPNs in
cellular systems. Anyway, I know they're not required in MIPv6 but I'm
talking about practical deployment. We disagree on that.

Hesham

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 31 Oct 2007 11:47:22 +1000

> I thought the MIP6 signaling security was what was being tackled.

=> We're simply solving the full case. The discussion was always dealing
with both cases. We always knew that we can do the BU/BA with transport
mode, but we were not sure how to address the entire use case with a mix of
secure and insecure traffic. That was always the problem. 

Hesham

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 31 Oct 2007 11:48:54 +1000

> allocating new NATed source address and source port anyway. Nothing

=> You didn't answer my question above. What you say amounts to a
requirement, my question was:
So you're saying the HA 
 > stores both sets of

Hesham

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 30 Oct 2007 17:55:14 -0700

Hi Hesham, Vijay, all,
Sorry my responses on this thread have been so sporadic and less than
useful.  Hesham had a couple of questions on my last email, so, I will
just attempt to clarify those below.  The two things I wanted to point
out with this approach are: 

* If IKEv2 was run on port 4500, this solution requires an update to
RFC3948 which mandates that all ESP packets be sent to UDP port 4500.
AFAIK, this requirement was put consciously so that all incoming packets
from the untrusted interface can be put through IPsec processing in the
same manner.  And, RFC3948 defines how to differentiate IKEv2 from ESP
packets coming in on port 4500.   

* If we didn't run IKEv2 on port 4500 and instead hid the NAT-T from
IKEv2 (which is what Hesham's first option was proposing), I think we'll
need a bypass entry to allow the BU coming in on the DSMIP6 port to be
given to MIP6.  An implementation may allow that directly, but, that's
not feasible if the implementation really followed RFC4301.  So, at
least in principle, we need to talk about having an SPD bypass entry for
the DSMIP6 port, processing of the packet by DSMIP6 to remove the NAT-T
headers and subsequently ESP processing with the right SPD entry.
Implementations need to handle this correctly.  

Thanks,
Vidya

> Sent: Tuesday, October 30, 2007 5:04 PM
> To: Hesham Soliman
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> >  > > This is exactly what we've been discussing, except you  > took 
> > out the case of  > > protection of payload packets.
> >  >
> >  > > So the solution you list below cannot be  > > compared 
> with alt 1 
> > or 2  >  > Neither solution 1 nor 2 will work for payload security 
> > when you  > use ESP in tunnel mode for the payload packets.
> > 
> > => Sure they will, Karen already sent the packet formats. 
> Solution 2 
> > uses port 4500 for tunnel mode, hence the entire discussion about 2 
> > RTT handovers.
> 
> I repeat, none of the solutions work as long as you use ESP 
> UDP encapsulation (port 4500) for the payload traffic to the CN.
> 
> > => You mean for DSMIPv6? I think we have to be realistic. I don't 
> > think it makes sense to use MIP6 and Mobike at the same 
> time just so 
> > we can encrypt payload traffic. I think you agreed with 
> that in your 
> > last email. So, if you don't want that then you need to 
> figure out how to secure payload traffic.
> RFC 3775, 3776 and 4877 say ESP protection for payload 
> traffic is optional. If you have a secure access link or if 
> you application layer security obviously you don't need to 
> encrypt all traffic reverse tunneled through the home agent.
> 
> Vijay
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 30 Oct 2007 19:19:13 -0700

Hesham Soliman wrote:
>  > Solution 2 uses

Payload traffic to the CN reverse tunneled through the HA. You
know what I meant.

> talking about practical deployment. We disagree on that.

Ok. I am interested in solving the problem, but it is optional
according to the specifications we have.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 30 Oct 2007 19:19:51 -0700

> requirement, my question was:

I was responding to it. It is not a DoS attack.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 30 Oct 2007 19:19:13 -0700

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 30 Oct 2007 19:19:51 -0700

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 30 Oct 2007 21:07:25 -0700

> packets coming in on port 4500.   

For DS-MIPv6 we are negotiating a transport mode ESP SA for the IPv6
traffic. In fact there is an IPv6 header before the ESP header. So
IPsec is not performing UDP encapsulation. UDP encapsulation is being
done by DS-MIPv6.

I don't believe 3948 considered something like this. As far as RFC
3948 is concerned there is always an IPv4 header preceding the ESP
header. Therefore there is a need for UDP encapsulation.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 30 Oct 2007 23:33:01 -0500

Hello,

I would like to encourage more people on the MIP6 and NEMO lists to review
the discussion related to DSMIP6 and IKEv2 and the issue that was raised
earlier as well as the proposed solutions.
Please provide your feedback to the ML.

At the present time there are only a handful of people commenting and it is
difficult to gauge consensus as a result.

I have also requested a couple of IKE experts (Tero Kivinen and Pasi Eronen)
to review and provide input.

-Basavaraj