Subject: [Mip6] DSMIP and IKEv2

From: <[email-masked]>
Date: Wed, 31 Oct 2007 08:27:51 +0100

Hi Vijay, Hesham

I do not have the strength to go into each and every individual mail.

Hesham, RFC 3948 and IKEv2 NAT traversal implies automatic update
of the port numbers at the gateway side (node not behind a NAT) and 
the DoS issues was considered when the RFC's was written. 
The DoS attack requires the MiTM to continuously intercept all traffic
from the MN
and this kind of DoS there is no remedy against anyway.

Let us not here question the NAT traversal mechs of IKEv2 and RFC 3948.
Given the people
who made it, it is safe !

Vijay:
ESP tunneling works in both scenarios. I have tried to explain that in
numerous
earlier mails.

In Situation 1 it requires extra tunneling :
IPv4
UDP
IPv6
ESP tunnel
IPv6
payload

and IKEv2 to know nothing about anything but the inner Ipv6 layer.

I haven't understood Vidya's point why this doesn't work. This may
change things, of course.

But I think that it is both difficult to implement, unmodular and unwise
not to
build with IPSec and IKEv2 traversality mechanisms.

In Situation 2, it requires some tricky interaction in between the MIP
and the IKE/IPSec modules
and then on top of that NAT and RFC 3948 nat traversal.
I have tried to explain this in earlier emails. Now I am lazy and I am
just copying from one of those:

******

> => 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. 
> 

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.

>  > 
>  > 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'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?

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 [inserted: with appropriate NAT detection options] 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

************************************************************************
*****************
Karen Egede Nielsen
System Manager

TietoEnator Corporation
IP Solutions, Telecom & Media
Skanderborgvej 232, 8260 Viby J, DK-Denmark
Phone: +45 89385100
Fax: +45 89385101
Direct Phone / Mobile +45 25134336
E-mail: [email-masked]
************************************************************************
*****************
www.tietoenator.com  

Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, you are hereby notified
that any unauthorised use, distribution or copying of this communication
is strictly prohibited. If you have received this communication in
error, please notify us immediately by replying to the message and
deleting it from your computer. Thank You.

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