Subject: [Mip6] DSMIPv6 and IKE

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 17 Oct 2007 23:59:07 +1000

Folks, 

We had a discussion in a smaller group about this problem, which was
initially raised in one of Christain Kaas-Petersen's emails. The problem of
integrating IKE and DSMIPv6 is fairly tricky because of the fact that each
mechanism has its own NAT traversal method. 

So after discussing this with a couple of people I'll present three possible
ways of solving this issue. Thanks to Pasi for writing up about 7 different
options, Raj and Vidya for their input. 

Problem description:
--------------------

DSMIPv6 obviously needs to provide a NAT traversal mechanism. The detection
of a NAT relies on the BU/BA message exchange. If a NAT were detected, UDP
encapsulation follows. Now, the problem is, for the BU to be sent, we need
to run IKE, which has it's own ports/traversal mechanisms. 
So if we run IKE and send the BU over the IKE tunnel, the HA will not know
what port number/address to send the MN's traffic to. Note that the MN
cannot include the port number 
and address because clearly it doesn't know what those values are since
they're allocated by the NAT. 

If we send the BU over port 4500 then we need to send another message (not
secured) using DSMIPv6 port to the HA with every handover. I think this is
unacceptable because we basically need to send two messages for handover and
one of them has zero security. So the idea of using two ports (4500 and
DSMIPv6 port) doesn't really work. 
And we don't have a way today of sending the BU separately over DSMIPv6
port. I.e., what's described in the draft is not possible today. 

Solution space:
---------------

There are basically three ideas that were discussed in a small group:

1. Allow DSMIPv6 to look like a virtual link for IKE. Hence, IKE will simply
run over IPv6 and will not be aware of IPv4 at all. 

2. Run IKE over port 4500, but add "DSMIPV6_UDP_ENCAPSULATION" notification
when negotiating ESP SAs

3. Add a new message in MIP6 that creates a port mapping in the NAT. The BU
is still sent over 4500 and the new message is either insecure or (a long
shot) secured by a crypto token exchanged in the BU/BA. 

Message format for solution 1:
------------------------------

IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT)
IPv6 header (src=V6HOA, dst=HAADDR)
ESP header
Mobility header
BU [IPv4 HAO]
IPv4 CoA option
  
And IKE messages would look like:

IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT)
IPv6 header (src=V6HOA, dst=HAADDR)
UDP header (src=500, dst=500)
IKE message...

With this solution, the HA would essentially store the route information for
the IKE messages (the port and address received in the outer header) and use
them as dst address and port in the respose message. This information must
not be stored permanently in the HA, only to respond to the messages.
Obviously, if the IKE daemon in the HA silents ignores an IKE message then
this information would have to be removed, so there would need to be a
timeout or inter-process communication in the implementation. For the MN
it's a lot simpler, source address selection for the IKE implementation
would always return the V6HoA. 

Message format for solution 2:
------------------------------

IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT)
ESP header
IPv6 header (src=V6HOA, dst=HAADDR)
Mobility header
BU [IPv4 HAO]
IPv4 CoA option

In this option we run IKE over port 4500, but add
"DSMIPV6_UDP_ENCAPSULATION"
notification when negotiating ESP SAs. Those ESP SAs would use src/dst
port DSMIPv6-PORT. 

But we would still have to rely on IKE to either implicitly or explicitly
update its ports and addresses whenever the mobile node moves. 

Option 3:
---------

Basically we didn't work out message formats for this option. I think we all
agreed that it's a long shot and, while interesting, it essentially involves
designing a new method for MIPv6 security, which is not the best or fastest
way to handle this problem. 

Conclusions:

IMO each one of those solutions has it's own flaws. There is no clean and
perfect solution above, but there are no clean solutions with NATs
unfortunately. I'm personally inclined to go with alternative 1 but let's
hear some opinions on this. Time is critical because there is a lot of
pressure to move this draft to the IESG. Please send comments. 

Thanks, 
Hesham

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

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 17 Oct 2007 20:01:09 +0200

Hi Hesham, all,

On 2007-10-17 15:59 Hesham Soliman said the following:
> initially raised in one of Christain Kaas-Petersen's emails...

...
> run over IPv6 and will not be aware of IPv4 at all. ...

...
> pressure to move this draft to the IESG. Please send comments. 

I concur.  Alternative 1 would be my preference, too.

	Henrik

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 18 Oct 2007 17:33:05 -0700

Hi Hesham and others,

Thanks for coming up with multiple solutions to this problem.
I have a few comments below.

Hesham Soliman wrote:

> them as dst address and port in the respose message. 

This solution would work, but I am not too comfortable with the
temporary tunnel being setup for IKEv2 messages. We don't have
such a thing for a MIPv6 home agent today. All tunnel state is
created only after the successful exchange of a BU/BAck.

This information must
> Message format for solution 2:

I would like to know more about the "cons" of this solution. In
this solution the BU/BAck is always sent over port 4500 using
UDP ESP encapsultion, but actual DS-MIPv6 tunnel uses
"DSMIPv6-PORT". This should work fine.

> update its ports and addresses whenever the mobile node moves.

But today we *do not* assume that the exchange of a BU/BAck always
updates the IKE SA. What if we assume the 'K' flag is always
cleared when the mobile node is attached to an IPv4 access network.
Of course this would always result in an IKEv2 exchange, in
addition to the BU/BAck exchange every time the CoA changes. This
is not so bad, since this defaults to lack of support for the 'K'
flag.

Vijay

---

From: <[email-masked]>
Date: Fri, 19 Oct 2007 13:01:11 +0200

The following is more or less what I originally thought would work,
with a note on K bit and a note on ESP transport.  I still think it
will work.

The MN is at some IPv6 capable foreign network, and it has already
used IKE to negotiate both an ESP transport for BU/BA exchanges and
some ESP tunnels for payload traffic.  Now it moves to an IPv4-only
foreign network.  Depending on the K bit, there are two variants.

First suppose the previous BU/BA exchange had cleared the K bit.  A
strict interpretation of this means either the IKE SA and all CHILD SAs
are invalid and must be negotiated again, or MOBIKE must be used to move
the IKE endpoint.  Then the BU/BA exchange can be done.  A perhaps
less strict interpretation would say, that the IKE SA is a session
between two node identities (reported in IDi and IDr payloads) and
the ESP transport is between some IPv6 addresses in the nodes different
from the interface addresses (namely the IPv6 home address (v6HoA) and
the IPv6 home agent address (v6AgA)).  Neither node identities nor
IPv6 endpoint addresses have changed.  So the ESP transport can still 
be used to protect the IPv6 BU/BA, becoming

    IPv6 header (v6HoA, v6AgA)
    ESP transport
    mobility data

which subsequently is prepended UDP (using DSMIPv6 ports) and IPv4
headers.  Subsequently IKE can be negotiated or MOBIKE can be used
to move the endpoints and any ESP tunnels for payload traffic.

Next suppose the previous BU/BA exchange had set the K bit.  In this
case the less-strict-interpretation above can be used to do the
BU/BA exchange, which makes one hole in the NAT box, followed by
an IKE aliveness exchange, which makes another hole in the NAT box and
is used to move the ESP tunnels for the payload traffic.

Of course it would be nice if movement could be done in one exchange
but reusing the IKE ports (ie UDP port 4500) gives a mixing of IKE and
mobility and IPsec packets, which is kind of overloading the use of
port 4500.

Christian

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: 19. oktober 2007 02:33
> To: Hesham Soliman
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Mip6] DSMIPv6 and IKE
> 
> Hi Hesham and others,
> 
> > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP header 
> (src=DSMIPv6-PORT, 
> > dst=DSMIPv6-PORT)
> > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP header 
> (src=DSMIPv6-PORT, 
> > dst=DSMIPv6-PORT)
> > With this solution, the HA would essentially store the route 
> > information for the IKE messages (the port and address 
> received in the 
> > outer header) and use them as dst address and port in the 
> respose message.
> 
> This solution would work, but I am not too comfortable with 
> the temporary tunnel being setup for IKEv2 messages. We don't 
> have such a thing for a MIPv6 home agent today. All tunnel 
> state is created only after the successful exchange of a BU/BAck.
> 
> This information must
> > Obviously, if the IKE daemon in the HA silents ignores an 
> IKE message 
> > then this information would have to be removed, so there 
> would need to 
> > be a timeout or inter-process communication in the 
> implementation. For 
> > the MN it's a lot simpler, source address selection for the IKE 
> > implementation would always return the V6HoA.
> > 
> > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP header 
> (src=DSMIPv6-PORT, 
> > dst=DSMIPv6-PORT) ESP header
> I would like to know more about the "cons" of this solution. 
> In this solution the BU/BAck is always sent over port 4500 
> using UDP ESP encapsultion, but actual DS-MIPv6 tunnel uses 
> > But we would still have to rely on IKE to either implicitly or 
> > explicitly update its ports and addresses whenever the 
> mobile node moves.
> 
> But today we *do not* assume that the exchange of a BU/BAck 
> always updates the IKE SA. What if we assume the 'K' flag is 
> always cleared when the mobile node is attached to an IPv4 
> access network.
> addition to the BU/BAck exchange every time the CoA changes. 
> This is not so bad, since this defaults to lack of support for the 'K'
> flag.
> 
> Vijay
>

---

From: <[email-masked]>
Date: Fri, 19 Oct 2007 14:05:47 +0200

Hi,

I find that the problem description to be a little off from what I
understood the
problem to be and therefore I am also not totally in line with the
proposed solutions.

> Problem description:

A lot is said about sending the BU "over the IKE tunnel" and over the
same ports 
as IKE and IPSEC RFC 3948.

Nothing is said about keeping the current design of sending the BU over
a specific DSMIP port and then fixing the IKE and IPSEC port issues
by a subsequent specific run of IKE to create the NAT port mappings for
the 4500 port
used by IKE and IPSec 3948. 

By excluding this from the problem
description, the solution is also excluded from the solution space.

This way of looking at the problem do require multiple messages to
complete the handover. Though still only one exchange for the BU to go
through.
The additional exchanges to ensure that all security SAs are up and
running, that is:
the IKE_SA which will ensure the continued aliveness of the ESP
transport SA used to protect the BU
as well as potential additional SAs for secure tunneling of payload 

Is there a special reason why this solution is not looked at ?

The solution does not fall into the category described above where
it is said that one of the additional exchanges has zero security.

> Solution space:

Looking into the solutions proposed. 

The first have the disadvantage that 
we cannot benefit from IPSec and IKEs NAT traversal intelligence (e.g.
RFC 3948),
IPSEC SAs as IPSEC and IKE are now kept in the dark about the outer IP
layers and NAT.
Further it seems to make it even more complicated to handle IKE during
movements, now IKE should
be run on the CoA when in an Ipv6 foreign network (or Ipv6 homenetwork)
but on the HoA when on an Ipv4 foreign network.
Not so nice.

Solution 2 seems to attempt to run IKE as normal but to have the RFC
3948 IPSEC SAs use
a different port, namely the DSMIPv6 port. But then we distort the NAT
traversality of
IKE and IPSec which rely on the ports used in IKE to be the same as the
port used in the 3948.
(The latter has implications for when and how ports are updated in the
IKE_SAs and the IPSec SAs
when the NAT changes mappings).

Solution 3 has the disadvantage that port 4500 is being overloaded.
Today both IKE and 3948 ESP IPSec
uses this port and there are rules for how one can detect whether a
received packet is an IKE packet or an IPSec ESP packet,
these rules are based on the fact that the SPI in the ESP header can
never coincide with the beginning of the IKE header.
With DSMIPv6, the next header will be an Ipv6 header and can it be
guaranteed that the beginning of the Ipv6 header could not coincide
with the SPI in the ESP header ?

BR, Karen

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 20 Oct 2007 10:01:27 +1000

> used by IKE and IPSec 3948. 

=> How can we send the BU over DSMIP port? Can you provide a solution for
this? 
Hos is the SA established ? 

 > complete the handover. Though still only one exchange for 

=> The point is, there are alternatives that would solve the problem with
two messages every handover, but why should we do that if we can avoid it? 

 > Is there a special reason why this solution is not looked at ?

=> What is the solution? We have two classes of solutions in the three
alternatives I sent. One class covers the "two message approach", the other
(alternative 1) does it with one message. What other solution do you
propose? Please send it to the list. I saw an email from Christian that I
haven't read yet, may be that's what you mean. But it sounds like you're
proposing another alternative for the "two message" approach. All things
being the same, I'm personally not in favour of doing two messages every
handover because we have two NAT traversal mechanisms running in parallel.
Seems very inefficient.

 > IPSEC SAs as IPSEC and IKE are now kept in the dark about 

=> What is IKEs NAT traversal intelligence? We don't use 3948 but I don't
understand what features we're missing.

 > but on the HoA when on an Ipv4 foreign network.

=> No, you don't actually have to do that, but you can do what you suggest
above. But at worste this is only an issue when changing admin domains. I
still think it's much better to live with this corner case than having the
norm be two messages per handover. I think we should optimise the more
common case. 

Hesham

---

From: <[email-masked]>
Date: Mon, 22 Oct 2007 11:44:45 +0200

Hi Hesham,

<snip>

> Hos is the SA established ? 

Pls. see below.

<snip>

> two messages every handover, but why should we do that if we 

Yes, 2 messages is a con, but it may still be less worse
that the cons of the proposed 1 message alternatives.

> handover because we have two NAT traversal mechanisms running 

Yes, but it is only in the NAT traversal situation that we have 2
messages.
When there is no NAT detected in the BU,
the second message exchange (IKE run, pls. see below) need not be run.

Yes, it is inefficient, but perhaps it is as efficient as it can be (?).

> understand what features we're missing.

How should we handle IPSec tunneling of payload from the MN to the HA:

If IKE is kept unaware of the DSMIP tunnel, then it cannot negotiate
Ipv6 in Ipv4 ESP tunnels and specifically it can not negotiate RFC 3948
tunnels
for Ipv6 in Udp in Ipv4 tunnels for NAT traversal.

Consequently IPSec tunneling of payload will have to be double 
tunneled on the MN HA link, i.e.,:

IPv4-UDP-IPv6-ESP-IPv6-Payload (for NAT traversal)

or 

IPv4-IPv6-ESP-IPv6-Payload

for no NAT traversal.

Whereas today when IKE uses the CoA, it can negotiate RFC 3948 tunnels
for this purpose,
which will result in:

IPv4-UDP-ESP-IPv6-Payload 

or standard tunnels

IPv4-ESP-IPv6-Payload 

for no NAT traversal.

yes, IPSec tunneling is only a SHOULD, and a corner case, as RO is no
point really on an Ipv4 only link.
But is that the same as we will go with this (inefficient :-) way of
doing it ?

Perhaps there is another way, without the double tunneling, which is
escaping me ?

I would like to advocate the solution described by Christian. He has
described the solution in 
a couple of mails, please see the last mail. I will here only highlight
the details.

Solution 4.

Run BU, BACK as described in DSMIP to a specific port. The IPSEC
transport ESP negotiated 
for IPv6 can be used to protect the BU, BACK. The DSMIP layer will
remove (respectively add)
the outer IP-UDP headers before (respectively after) the packet is being
IPSec decrypted (respectively encrypted).

IKE can negotiate the transport SAs regardless of whether the CoA is the
Ipv6 HoA or an Ipv4 (private or public)
or and Ipv6 CoA.

As in standard Mipv6 the transport SA in place is expected to be OK
although the IKE SA is no longer
valid as the MN end-point (the CoA) has moved. 

When the BU detects no NAT. The IKE SA and all IPSec tunnel SAs can be
updated as in standard MIPv6 as no UDP ports are in play,
only the new CoA must be inserted in the IKE SA and the IPSEC SA.

When the BU/BACK exchange informs the MN that a NAT was present then it
need to start en IKE exchange so the
ports in the IKE SA and associated IPSEC tunnel SAs can be appropriately
updated.

Now we are done.

Yes it requires multiple exchanges to fix the IKE and IPSEC ports, but
only in the case where a NAT is detected.
Further it is only the traffic which relies on IPSEc tunneling which is
impacted by the delay caused by the 
additional IKE exchange.

Hope this explains.

BR, Karen

---

From: "Tsirtsis, George" <[email-masked]>
Date: Mon, 22 Oct 2007 02:51:42 -0700

Hi all,

I also think that requiring more messages on every handoff should not be
done lightly here. The solution proposed by Hesham seems efficient and
others have also indicates that although it requires special processing
of a limited number of messages, it looks doable....so IMO this is the
preferred option here.

Thanks
George

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Saturday, October 20, 2007 1:01 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Mip6] DSMIPv6 and IKE

 > used by IKE and IPSec 3948. 

=> How can we send the BU over DSMIP port? Can you provide a solution
for
this? 
Hos is the SA established ? 

 > complete the handover. Though still only one exchange for 

=> The point is, there are alternatives that would solve the problem
with
two messages every handover, but why should we do that if we can avoid
it? 

=> What is the solution? We have two classes of solutions in the three
alternatives I sent. One class covers the "two message approach", the
other
(alternative 1) does it with one message. What other solution do you
propose? Please send it to the list. I saw an email from Christian that
I
haven't read yet, may be that's what you mean. But it sounds like you're
proposing another alternative for the "two message" approach. All things
being the same, I'm personally not in favour of doing two messages every
handover because we have two NAT traversal mechanisms running in
parallel.
Seems very inefficient.

 > IPSEC SAs as IPSEC and IKE are now kept in the dark about 

=> What is IKEs NAT traversal intelligence? We don't use 3948 but I
don't
understand what features we're missing.

 > but on the HoA when on an Ipv4 foreign network.

=> No, you don't actually have to do that, but you can do what you
suggest
above. But at worste this is only an issue when changing admin domains.
I
still think it's much better to live with this corner case than having
the
norm be two messages per handover. I think we should optimise the more
common case. 

Hesham

---

From: "Hesham Soliman" <[email-masked]>
Date: Mon, 22 Oct 2007 23:55:21 +1000

> that the cons of the proposed 1 message alternatives.

=> It's difficult to say what "less worse" means unless you can quantify it.

 > Yes, but it is only in the NAT traversal situation that we have 2

=> Which is most of the time! 

 > for Ipv6 in Udp in Ipv4 tunnels for NAT traversal.

=> Forgetting about 3948 tunnels because it's not an accident that we don't
use it, why can't IKE negotiate those tunnels? 

 > IPv4-IPv6-ESP-IPv6-Payload

=> Correct, I thought you were saying that it can't be done (above).

 > Perhaps there is another way, without the double tunneling, which is

=> I don't know if there can be another way and I doubt that there is one. I
agree that we should try to reduce the tunnels but this is the choice that
we're faced with. an extra header for the VPN case Vs two RTTs for handover.
I'd like to get rid of both problems but it's not possible because of NATs.

 > only in the case where a NAT is detected.

=> Yes of course, but that's the majority of the cases! 

 > impacted by the delay caused by the 

=> Ok but I want to make it clear that this falls under the "two message"
class of solutions. You seemed to indicate in your last email that there was
a class of solutions missing. So we still have to consider the same tradeoff
that we're talking about now. I'm assuming that when you say IKE sets up the
SA, you mean that there is no modification needed for IKE, correct? I'm not
an IKE expert so can you elaborate on the IKE messages that will be sent
over port 4500 to setup an SA for DSMIPv6 ports? 

Hesham

---

From: <[email-masked]>
Date: Mon, 22 Oct 2007 16:45:12 +0200

Here is another proposal, maybe not exactly another class of solutions,
but reducing the problem to one packet exchange.  In the two-message
approach, two entries are made in the NAT box: one for an IKE exchange, 
another for the BU/BA exchange.  The NAT entry for IKE is used not just
for IKE packets but by all ESP tunnel packets.  So this entry is kept 
alive in the NAT box by a lot of traffic.  That may not be the case 
for the BU/BA exchange, which will happen only occasionally when the 
lifetime is to be renewed.  Why not introduce a new payload in IKE
in which the BU or the BA packet is carried?  
  
This looks a little like MOBIKE, but MOBIKE is always doing two 
exchanges because the responder has to verify the initiator 
has sent a correct IP address.  This verification can be done by 
examining the BU packet as transported by IKE.

The new IKE payload for the BU and BA will work similar to the way
EAP messages are carried back and forth by IKE. 

Christian

> Sent: 22. oktober 2007 15:55
> To: Nielsen Karen E; [email-masked]; [email-masked]

---

From: <[email-masked]>
Date: Mon, 22 Oct 2007 22:51:29 +0200

Hi Hesham, 

> Sent: Monday, October 22, 2007 3:55 PM

In my opinion, I was doing that below. But I apologize for 
giving soft words instead of technical arguments.

> => Which is most of the time! 

OK, I accept that.

> use it, why can't IKE negotiate those tunnels? 

Why don't you want 3948 tunnels ?

> => Correct, I thought you were saying that it can't be done (above).

I was saying that IKEv2 in this situation cannot negotiate Ipv6 in Ipv4
ESP tunnels, which is true.

> => Yes of course, but that's the majority of the cases! 

Ok, I accept.

> a class of solutions missing. 

I am sorry if I mislead you. I was only trying to say that this 2
message exchange 
solution wasn't one in which one of the messages had zero security, so I
felt that it was missing
from the general descriptions about 2 message exchange solutions given
in your mail.

I wanted to make sure that this solution was discarded for the right
reasons.

So we still have to consider 
> the same tradeoff
> that we're talking about now.

I think that it is worthwhile to notice that the handover for all
traffic which is not
IPSec tunnel encapsulated on the MN=HA path is achieved in 1 RTT.

 I'm assuming that when you say 
> IKE sets up the
> SA, you mean that there is no modification needed for IKE, 
> correct?

I am not sure what you mean here. 
But standard IKEv2 can negotiate 
* the Ipv6 transport ESP SA from the MN to the HA required for Ipv6
level protection of the BU
* standard IPSec tunnel (Ipv6 in Ipv4 or Ipv4 in Ipv4), the local
end-point in the outer Ipv4 header of the tunnel SA being the HA's Ipv4
address, when there is no NAT
* and, when there's a NAT in between the MN and the HA, ESP UDP
encapsulated tunnel IPSec Sas (RFC 3948), the local
end-point in the outer Ipv4 header of the tunnel SA being the HA's Ipv4
address and with an UDP header inserted.

 I'm not
> over port 4500 to setup an SA for DSMIPv6 ports? 

I am not entirely sure what you mean. If you mean whether IKE can
negotiate
an IPSEC ESP SA that takes an Ipv6 (or an Ipv4 packet) packet, encrypts
it and append and Ipv4 header, UDP header to DSMIP port and ESP 
header (in reverse order), then I don't think that standard IKE can do
that over port 4500.

If that it what you mean, then I may suddenly understand why we fail to
understand one another.
If you want the IPSec tunneled packets to look as if they were destined
for the DSMIP port, then forget about everything I have 
said.

I don't understand why you would like to have that, if that is what you
want indeed - ? - but that's a different discussion.

Thanks !

Karen

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 22 Oct 2007 15:14:10 -0700

Tsirtsis, George wrote:
> done lightly here. 

This statement is not entirely correct. The IKEv2 exchange following
a handover is not in the critical path. It can done much later after
the handover. For example it could be done 60 seconds after the
handover. The exchange of BU/BAck would update the binding right away.

This would be equivalent to not supporting the 'K' bit in RFC 3775.
In RFC 3775, if either the mobile node or the home agent is not
capable of updating the IKEv2 SA based on the BU/BAck, there is
always an IKEv2 exchange following the handover.

 > The solution proposed by Hesham seems efficient and

Depends. Using some temporary tunnel state and making IKEv2 run over
that tunnel is not that straight forward.

Vijay

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 23 Oct 2007 13:24:32 +1000

> Why don't you want 3948 tunnels ?

=> Because I want to avoid running two traversal mechanisms simultaneously
and ending up with two messages. 

 > from the general descriptions about 2 message exchange 

=> OK, agreed.

 > IPSec tunnel encapsulated on the MN=HA path is achieved in 1 RTT.

=> So you're saying that all IPsec tunnel encapsulated traffic is going over
port 4500, right? 
IMO, from a performance point of view it's not good enough to tell a
customer part of your traffic will take 1 RTT for handovers and the secure
part will take 2 RTT.

 > address and with an UDP header inserted.

=> Yes I understand that, but I'm talking about this:
MN has address 10.0.0.1
A. MN's NATTED address for IKE: 61.0.0.1 outer port 30000
B. MN's NATTED address for DSMIP 61.0.0.100 outer port 40000

Given that IKE doesn't know anything about B, can it still negotiate an SA
for DSMIP to send a BU? This is what I'm trying to understand. As much
detail on the IKE messages as possible please. 

 > for the DSMIP port, then forget about everything I have 

=> I'm not sure if we're on the same page here. You're saying that you can
send a BU secured with ESP, using DSMIP ports, correct? I.e. using the same
numbers above:
src = 10.0.0.1
dst = HAv4
UDP src port = 15000 dst port = DSMIPv6port
src6 = HoA
dst6 = HA6
ESP
BU

Is this correct? My question above is how did you setup this SA?

Hesham

---

From: <[email-masked]>
Date: Tue, 23 Oct 2007 13:42:17 +0200

Hi, 

> Sent: Tuesday, October 23, 2007 5:25 AM
> To: Nielsen Karen E
> Cc: [email-masked]; [email-masked]

Ok, that's the reason, I understand. But let me say this:

We are running a number of protocols, Mobility, IPSec and IKE
and they each have their build-in way of traversing NAT 
- well the first we are defining now.
I think the wise thing is to build with 
the NAT traversal mechanism of each of the protocols
and not make too many special shortcuts. 
Yes, it may take several exchanges, but it is robust.

> => So you're saying that all IPsec tunnel encapsulated 

Right.

> customer part of your traffic will take 1 RTT for handovers 

Well, yes, but they also know that there is almost
always a price to pay for security. 

> detail on the IKE messages as possible please. 

The IPSec SA that is used to protect the BU should be ESP transport on
IPv6 level.
Therefore IKE and IPSEc does not need to know anything about the outer
UDP and IPv4 encapsulation of DSMIP.
As IKE and IPSec does not need to know anything about the destination
option and
the routing header in standard MIP.

IKE can negotiate ESP transport SAs given the right IPv6 selectors 
(MN v6HoA and HA v6 address, protocol = MH of BU type) 
in the IKE payload.

Details:

New IKE_SA and IPSec SA establishment situation:

IKE messages, as they arrive at IKE/HA, appears as if the arrive from 
the address set A destined for HA v4 address and port 4500.
But transport SA negotiations is not dependent on the 
endpoint addresses of the IKE connection. [Tunnel SAs however are !!]

First there is the IKE_SA_INIT exchange (one message going back and
forth)
which establishes the IKE_SA credentials. The IKE_SA is established
between
address set A and HAv4 adresss and port 4500.

Secondly there is the IKE_AUTH exchange (one message going back and
forth).
This exchange authenticates the first exchange as well as it negotiates 
a child IPSEC SA, which in this case will be an ESP Ipv6 anchored
transport IPSec SA.
The IPSec SA is established based on the traffic selectors and the SA
material (crypto algorithms and such)
proposed by the initiator and included in the IKE message contents, the
traffic selector will in this situation say
MN v6HoA, HA v6 address and MH type BU.

The IPSEC SA may also be established as a child to an existing IKE_SA,
in this situation
we only have one message exchange carrying the same selector set, SA
material and more as above.

In both cases, again to stress, the transport SA is by no means related
to the
characteristics of the underlying connection from address set A to HAv4
addresss and port 4500.

> Is this correct? My question above is how did you setup this SA?

The SA is set-up as described above, 
if it has not been set-up before the MN moved.
Most likely it is set-up prior to the move.
And in this situation, as it is not bound to anything 
but the IPv6 addresses of the MN and the HA,
it will survive the move until 
the associated IKE_SA dies or the IPSec_SA needs to be re-keyed.

The associated IKE_SA needs to be refreshed and updated 
regularly as does all IPSec SA's under it. But
it takes some time before IKE calls a peer out and 
tears down the IKE_SA and the IPSEc SA's, so the
SA should work after the movement.
Yes there are corner cases, but let's not go there.
All this is no different from standard Mobile Ipv6.

Based on the BU, the HA may update the address
of the MN end-point in the IKE_SA and the tunnel IPSec SAs.
Further the HA (DSMIP code) will know whether 
this is sufficient depending on whether there is NAT or not.

If there is no NAT now, we are done. But the above step may* include
changing the
IKE_SA from an IKE_SA with NAT to an IKE_SA with no NAT as well as it
may* include
changing all RFC 3948 IPSEC tunnels associated with the IKE_SA to
standard IPSEc tunnel SAs
with no NAT.

* for the situation where there was a NAT before the move.

All this may also include changing the IP address version, if we are
moving from Ipv4
to Ipv6 or the other way around.

Now assume that there is a NAT now.

The HA (DSMIP code) must make sure that the nature
of the IKE_SA and the associated IPSec tunnel SAs is put in accordance
with the fact that there's a NAT. If there was no NAT before this means
changing
the nature of the IKE_SA to an IKE_SA with NAT and changing all tunnel
IPSEC SAs to RFC 3948 ones.

The DSMIP does not need to keep track of whether there was a NAT before,
only it must ensure that
everything now is in accordance with the fact that there is a NAT.

Now we are set to update the MN address and 
port end-point information in the IKE_SA and in
the RFC 3948 tunnel SAs. 

This can be done in two ways:

1. IKE dead peer detection:

If the MN sends an appropriately authenticated IKE dead peer detection
packet when it has received the BACK,
this will automatically make the IKE at the HA update the IKE_SA and all
associated IPSec 3948 Sas with the correct
port and addressed of the MN as mapped by the NAT.

This to the IKE entity at the HA corresponds to the situation whether
the NAT has changed its mappings
and the above reaction is a SHOULD in RFC 4306 (Section 2.23).

2. If there is payload to be sent towards the HA via an IPSEc 3948
tunnel SA, the receipt of
this packet at the HA should result in the same updating being done by
the HA.

Now as a MN may not always have a IPSec tunnel SA to the HA, we cannot
rely on 2. as a general mechanism.
Further it should be stressed that this does not mean that the RTT delay
for IPSec tunneled packets is only 1 RTT,
because in the reverse direction from HA to MN, the ports and addresses
are first being updated after the receipt
of the tunneled packet at the HA, thus 1,5 RTT (not 2 RTT, but not 1 RTT
either).

Instead of doing all this complex (but standard compliant) fiddling, one
could also use MOBIKE to move the endpoint
of the IKE_SA and the associated tunnel SAs, but it may not be so nice
to have to require MOBIKE (?)

A third alternative is no rerun IKE entirely and re-negotiate all SAs
after the BU/BACK exchange. Again
the delay caused only impacts secure traffic.

Karen

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 24 Oct 2007 13:31:04 +1000

> Yes, it may take several exchanges, but it is robust.

=> Robustness is not an absolute. You're talking about robustness of the
implementation, but an operator wants robustness of other things like
handover in a mobile system. Telling them that half the traffic will need
more RTTs doesn't sound like an attractive feature for them. They don't care
how you implement it as long as it's stable.

 > always a price to pay for security. 

=> I'll have to agree to disagree with this logic. If I were running a
mobile network I wouldn't accept *this* price. 

 > characteristics of the underlying connection from address 

=> Ok, got it thanks. So we'll end up with the same packet for the BU in
both cases but the only difference is what we already discussed, i.e. two
NAT traversals Vs one, which will affect secure traffic only. Thanks for the
details below as well. 
I'll send a summary email to the list to finish this issue. 

Hesham