Subject: [Mip6] draft-ietf-mip6-nemo-v4traversal-05 and IKE

From: <[email-masked]>
Date: Wed, 19 Sep 2007 12:36:56 +0200

The draft-ietf-mip6-nemo-v4traversal-05 mentions the use of security
associations and the use of ESP (for example see section 2.2), but
does not mention IKE.  IKE could be used to negotiate
dynamically both the ESP transport to protect the binding updates
and the ESP tunnels between the mobile node and the home agent
to protect the payload traffic between the mobile node and the
correspondent node.

As long as the mobile node is at home or visits an IPv6 foreign
network, the possible use of IKE is defined in RFC 4877, 
and RFC 4877 defines two procedures, one for the mobile node and 
another for the home agent, where the successful exchange of 
binding updates leads to updating the IKE SA end points and 
the ESP tunnel end points, ie no new IKE negotiation.  
(There is no modification to the ESP transport.)

Now suppose the mobile node visits an IPv4 foreign network.  The
draft-ietf-mip6-nemo-v4traversal-05 defines a mechanism for detecting
and traversing NAT boxes using vanilla UDP and a UDP port number to
be defined.  However, the UDP ports learned for that
traversal cannot be used by IKE, because IKE is expected to use UDP
port 4500, and IKE has its own technique for NAT traversal based on
UDP encapsulation as defined in RFC 3948.  Thus
the successful exchange of binding updates can be used to move the
IP addresses of the IKE end points and the ESP tunnel end points, 
but the UDP ports must be discovered by IKE itself.  
Therefore the successful exchange of binding updates
must be followed for example by an IKE liveness check initiated by the
mobile node in order to detect presence of NAT boxes.  This issue is
not discussed in draft-ietf-mip6-nemo-v4traversal-05.

Following the successful exchange of binding updates, the
ESP tunnel end points were moved.  Shall those ESP tunnels use the UDP
ports from the binding updates or the UDP ports from IKE?  I think it
most straightforward if the ESP tunnels use the UDP ports learned
from IKE, because then there is no difference whether the ESP tunnels
are negotiated first time when the mobile node visits the IPv4
foreign network or the ESP tunnels are just moved.  This choice
also allows reuse of the mechanism for updating the port number in case
the NAT suddenly forgets the old mapping and defines a new one.

A final remark: the ESP transport mode protection of binding
updates is not affected.  After having applied the ESP protection of
the binding updates, those binding updates are subjected to UDP
encapsulation and IPv4 tunneling as described in the draft.

I have assumed RFC 3948 UDP encapsulation is the same as vanilla
UDP.

Christian

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

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 19 Sep 2007 21:19:16 +1000

> (There is no modification to the ESP transport.)

=> IKE is the only standard method defined for MIPv6 SA establishment. We
don't have any other choice but IKE(v2) in MIPv6. We can add that reference
to be sure.

 > not discussed in draft-ietf-mip6-nemo-v4traversal-05.

=> Good point. I don't think this was raised before. What the draft needs to
do is:

1. IKE exchange for the SA establishment.
2. BU/BA exchange over the UDP port allocated to DSMIPv6 by IANA (not 4500).

3. Go to step 1 for SA renewal.

 > ports from the binding updates or the UDP ports from IKE?  

=> What do you mean by the "UDP ports from IKE"? You mean 4500? 
We need to allocate a specific port for the HA to listen to MIPv6 messages
whether they are protected by ESP or not. Therefore we need a different
port. 

Hesham

---

From: <[email-masked]>
Date: Wed, 19 Sep 2007 13:40:43 +0200

The MIPv6 messages will have an IPv4 header followed by a UDP header,
and a specific port is to be allocated, and that port must be
different from 4500.  Agreed.  Is this specific UDP
port only for MIPv6 messages?  I suggest the answer YES, such
that the ESP tunnels, which may traverse the same NAT, must
await the next IKE exchange.  This next IKE exchange will allow
the mobile node to change the ESP tunnels using UDP local port 4500
and UDP remote port 4500, whereas the home agent will change the ESP
tunnels using UDP local port 4500 and UDP remote port say 25001.

Christian

> -----Original Message-----
> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: 19. september 2007 13:19
> To: Kaas-Petersen Christian; [email-masked]
> Subject: RE: [Mip6] draft-ietf-mip6-nemo-v4traversal-05 and IKE
> 
> 
>  >

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 19 Sep 2007 22:59:40 +1000

> port only for MIPv6 messages?  I suggest the answer YES,

=> Correct.

   such
 > tunnels using UDP local port 4500 and UDP remote port say 25001.

=> I'm not sure I understand the last sentence but as far as the *HA*, which
is a MIP
function, is concerned, the local port is say 25000 (allocated by IANA for
this spec) and the remote port is ephemeral. 

Hesham

---

From: <[email-masked]>
Date: Wed, 19 Sep 2007 15:24:57 +0200

I'll start with IKE.  The mobile node enters an IPv4 foreign network
and IKE is told to do NAT detection.  The mobile node sends

      IP
      UDP src = 500, dst = 500
      IKE payloads, including N(NAT_DETECTION_SOURCE_IP) 
                          and N(NAT_DETECTION_DESTINATION_IP)

and gets a response.  The mobile node examines the notification payloads
and detects the packet has passed a NAT box, and then sends

      IP
      UDP src = 4500, dst = 4500
      4-bytes non-ESP marker
      IKE payloads

This packet hits the NAT box, and when leaving the NAT box, the
packet is

      IP
      UDP src = 25001, dst = 4500
      4-bytes non-ESP marker
      IKE payloads

25001 was chosen by the NAT box.

This packet is received by the IKE peer, the home agent.  After the
home agent's response has been received by the mobile node,
the mobile node knows it is behind NAT, and
the mobile node updates the ESP tunnels with UDP encapsulation using
UDP local = UDP remote = 4500, whereas the home agent will update the
other
end of the ESP tunnels with UDP local = 4500, UDP remote 25001.

For the binding updates, the mobile node will in the UDP header 
use an ephemeral src port and the IANA defined destination port,
say 25000.  The ephemeral source port will be changed by the NAT box.

Christian

> Sent: 19. september 2007 15:00

---

From: <[email-masked]>
Date: Wed, 19 Sep 2007 16:04:45 +0200

Hi,

Just to add.

If I have understood things correctly, then what Christian is pointing
out
 is that there is a discrepancy in between how IKE and, respectively,
the MIP HA would update the ports in the RFC 3948 IPSec ESP tunnel SAs -
AND -
that the updating performed by the MIP HA
based on ports in BU messages will not be RFC 3948 compliant.

Consequently it seems that one needs to specify how this must instead be

done with a special run of IKE. 

Further on the IKE SA themselves,
then wrt. the solution given by you, Hesham:

i.e.:

***

1. IKE exchange for the SA establishment.
2. BU/BA exchange over the UDP port allocated to DSMIPv6 by IANA (not
4500).

***

Then I suppose that you mean IKE_SA renewal, not SA renewal - right ?

BR, Karen

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Wednesday, September 19, 2007 3:25 PM
> To: [email-masked]; [email-masked]

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 20 Sep 2007 14:17:42 +1000

Yes I think this is how things should work. I think I should add text to the
draft to reflect this discussion.  Does anyone else have something to add to
this? 

Hesham

 > Sent: Wednesday, September 19, 2007 11:25 PM
 > >  > > Subject: RE: [Mip6] 
 > draft-ietf-mip6-nemo-v4traversal-05 and IKE
 > >  > > 
 > >  > > 
 > >  > >  >

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 20 Sep 2007 14:22:23 +1000

> done with a special run of IKE. 

=> Can you please explain why we need a special run of IKE? Is there
something in Christian's last email that alludes to the need for anything
special to be done in IKE? There is no surprise about the different port
numbers needed to run this, but I'd like to know during this LC if we missed
anything related to IKE's operation.

 > Then I suppose that you mean IKE_SA renewal, not SA renewal - right ?

=> I meant the IPsec SA renewal (for the BU protection), which is done using
IKE, which will hopefully not happen more than once a day. 

Hesham

 > > >  > >  > ESP tunnel end points were moved.  Shall those 
 > ESP tunnels 
 > > >  > >  > use the UDP
 > > >  > > whether they are protected by ESP or not. Therefore 
 > we need a 
 > > >  > > different
 > > >  > > port. 
 > > >  > > 
 > > >  > > Hesham
 > > >  > > 
 > > >  > > 
 > > >  > > 
 > > >  > 
 > > > 
 > > > 
 > > > 
 > >

---

From: <[email-masked]>
Date: Thu, 20 Sep 2007 09:15:10 +0200

Hi, 

> anything related to IKE's operation.

The point is that you can not update an RFC 3948 IPSEC ESP based on the
information received in the BU if the BU was not send using port 4500.

The ports and addresses of the RFC 3948 IPSec ESP (and the associated
IKE_SA) is based on UDP
port 4500 communications.

So it seems, that it is not possible (as in standard MIPv6) to assume
that the IPSEc tunnel ESP SA (which  would
be an RFC 3948 one if negotiated by IKE through a NAT) will survive
movement without special action taken by MN IKE.

Please see below, also.

> IKE, which will hopefully not happen more than once a day. 

The point is that regardless of whether the HA update the IKE_SA with
the the new CoA address of the MN, IKE_SA is still now invalid unless 
updated with appropriate ports and NAT external IP address of the MN
associated with an
IKE exchange through the NAT.

This means that if the HA IKE performs dead peer detection (or NAT keep
alive of ports/external addresses
used on a previous MN=HA path), the HA IKE will destroy the IKE SA and
the IPSec SAs associated with the IKE SA.
However if an IKE renegotiation or IKE dead peer detection is done from
the MN side,
this will create a mapping associated with port 4500 UDP in the NAT and
the IKE_SA can be fully updated. In fact
the updating of the IKE_SA will be done automatically by IKE provided
the IKE 
packet is appropriately authenticated using the IKE_SA credentials
and the new CoA (the latter which then must have been updated in IKE by
the MIP HA, when it received the BU).

Thus, if we are not to require a new
run of IKE each time the MN moves, there are special considerations
around 
how to make this interwork with IKE (considerations which
didn't apply to the simple Mipv6 case nor to the DSMIP case when there
are no NATs). 

But, Christian knows this stuff much better than me, and he may correct
me or clarify.

BR, Karen

---

From: <[email-masked]>
Date: Thu, 20 Sep 2007 09:48:37 +0200

Changing an end point of IKE and possibly doing a NAT detection is
the purpose of MOBIKE.  MOBIKE is useful in the case where only one
end point changes is address, and this is exactly the case between
the mobile node and the home agent.

Christian  

> Sent: 20. september 2007 06:18

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 28 Sep 2007 17:37:15 +0900

Hi Christian,

Sorry for the late reply, but I have some comments. Please
find them inline:

> not discussed in draft-ietf-mip6-nemo-v4traversal-05.

Ok, I see the problem.

> the NAT suddenly forgets the old mapping and defines a new one.

I agree.  If we assume that the BU message is sent over an
IPv4-UDP-ESP tunnel (conforming to RFC3948), then I think
it would be reasonable to let IKE to use the port it discovers
through its NAT detection mechanism.

> encapsulation and IPv4 tunneling as described in the draft.

That's true.  For the above reason, I prefer protecting BU/BA
with ESP transport mode SA (rather than IPv4-UDP-ESP tunnel)
in DS-MIPv6.  Requiring IKE exchange prior to the MIPv6 home
registration is not desirable simply because the disruption time
would be long.

I personally think that tunneling everything (DS-MIPv6 signaling
messages) over IPv4-UDP-ESP tunnel makes little sense.  I mean,
such scenairo implies that IKE implements certain movement
detection mechanism.  Then I see no value of DS-MIPv6 because
MOBIKE alone is far simpler than the combination of DS-MIPv6
plus modified IKE.

So, IMHO, there should be a clear statement in the DS-MIPv6
spec exactly how IPsec should be employed.

Regards,
Shinta

---

From: <[email-masked]>
Date: Fri, 28 Sep 2007 11:28:00 +0200

I stated the continued use of ESP transport for the BU/BA exchange,
and therefore I did not assume the BU message sent over an
IPv4-UDP-ESP tunnel; I just had a comment on the movement of the
IKE SA and the ESP tunnel SAs.  Please note, that IKE doesn't
implement any movement detection.  Movement detection is done
elsewhere.  But IKE/IPsec should be able to have its end points
moved (if  K bit is set by both ends).

Christian

> From: Shinta Sugimoto [mailto:[email-masked]] 
> Sent: 28. september 2007 10:37
> To: Kaas-Petersen Christian
> Cc: [email-masked]
> Subject: Re: [Mip6] draft-ietf-mip6-nemo-v4traversal-05 and IKE
> 
> Hi Christian,
> 
> dynamically both 
> > the ESP transport to protect the binding updates and the 
> ESP tunnels 
> > between the mobile node and the home agent to protect the payload 
> > traffic between the mobile node and the correspondent node.
> > 
> and RFC 4877 
> > defines two procedures, one for the mobile node and another for the 
> > home agent, where the successful exchange of binding 
> updates leads to 
> > updating the IKE SA end points and the ESP tunnel end points, ie no 
> > new IKE negotiation.
> > and traversing NAT boxes using vanilla UDP and a UDP port 
> number to be 
> > defined.  However, the UDP ports learned for that traversal 
> cannot be 
> > used by IKE, because IKE is expected to use UDP port 4500, 
> and IKE has 
> > its own technique for NAT traversal based on UDP encapsulation as 
> > defined in RFC 3948.  Thus the successful exchange of 
> binding updates 
> > can be used to move the IP addresses of the IKE end points 
> and the ESP 
> > tunnel end points, but the UDP ports must be discovered by 
> IKE itself.
> > Therefore the successful exchange of binding updates must 
> be followed 
> > for example by an IKE liveness check initiated by the 
> mobile node in 
> > order to detect presence of NAT boxes.  This issue is not 
> discussed in 
> > draft-ietf-mip6-nemo-v4traversal-05.
> 
> Ok, I see the problem.
> 
> ESP tunnel 
> > end points were moved.  Shall those ESP tunnels use the UDP 
> ports from 
> > the binding updates or the UDP ports from IKE?  I think it most 
> > straightforward if the ESP tunnels use the UDP ports 
> learned from IKE, 
> > because then there is no difference whether the ESP tunnels are 
> > negotiated first time when the mobile node visits the IPv4 foreign 
> > network or the ESP tunnels are just moved.  This choice also allows 
> > reuse of the mechanism for updating the port number in case the NAT 
> > suddenly forgets the old mapping and defines a new one.
> 
> IPv4-UDP-ESP tunnel (conforming to RFC3948), then I think it 
> would be reasonable to let IKE to use the port it discovers 
> > A final remark: the ESP transport mode protection of 
> binding updates 
> > is not affected.  After having applied the ESP protection of the 
> > binding updates, those binding updates are subjected to UDP 
> registration is not desirable simply because the disruption 
> time would be long.
> 
> messages) over IPv4-UDP-ESP tunnel makes little sense.  I 
> mean, such scenairo implies that IKE implements certain 
> movement detection mechanism.  Then I see no value of 
> DS-MIPv6 because MOBIKE alone is far simpler than the 
> combination of DS-MIPv6 plus modified IKE.
>

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 28 Sep 2007 19:56:24 +0900

Hi Christian,

Thanks for your clarification. Please see my comments below.

[email-masked] wrote:
> IKE SA and the ESP tunnel SAs.

Ok, I mis-interpreted your email.

Let me clarify.  So, you are pointing out that when the MN
is behind NAT, the only way for updating the endpoint of IKE
and tunnel mode IPsec SA is to run re-keying initiated by the
MN.  Is my understanding correct?

Then the question is how we can assure that re-keying is kicked
by the MN whenever it attaches to a new private IPv4 network,
right?

>  Please note, that IKE doesn't

Yes, I agree that plain IKE does not implement any movement
detection mechanism.

Regards,
Shinta

>>>The draft-ietf-mip6-nemo-v4traversal-05 mentions the use of 
>>
>>security 
>>
>>>draft-ietf-mip6-nemo-v4traversal-05 defines a mechanism for 
>>
>>detecting 
>>

---

From: <[email-masked]>
Date: Fri, 28 Sep 2007 13:41:48 +0200

> Sent: 28. september 2007 12:56
> > IPv4-UDP-ESP tunnel; I just had a comment on the movement 
> of the IKE 
> > SA and the ESP tunnel SAs.
> 
> Let me clarify.  So, you are pointing out that when the MN is 
> behind NAT, the only way for updating the endpoint of IKE and 
> tunnel mode IPsec SA is to run re-keying initiated by the MN. 
>  Is my understanding correct?
> 
> Then the question is how we can assure that re-keying is 
> kicked by the MN whenever it attaches to a new private IPv4 
> network, right?

Short version: no re-keying (the term rekeying has a special
meaning in IKE).  IKE is partly updated as a result of the
BU/BA exchange, and partly by its own NAT detection.  It is a
local implementation issue how the mobility functionality
triggers IKE's dead-peer-detection-with-NAT-discovery.

Long version:  The mobile node moves, and by this I mean 
some algorithm detects an IP address has been changed on an 
interface.  This detection leads to the sending of a BU.  The BU is sent
from the IPv6 home address to the IPv6 home agent address, and so the 
existing ESP transport is used to protect the BU.  If the new
address is IPv4, the ESP packet is provided with an UDP header
and an IPv4 header where the IPv4 header uses the new address
as source address and the home agent's IPv4 address as destination
address.  After having sent the packet, a BA packet is received,
and the mobile node now knows the IPv4 addresses in the two 
ends and whether the exchange passed through a NAT box.  This
information is used to trigger IKE: IKE is given the new 
IPv4 addresses and instructed to send a dead peer detection packet
and at the same time doing NAT detection.  (At the same time, the
home agent has become aware of the new IP addresses, and has
ensured listening for IKE packets on the home agent's IPv4 address.)
As a result of the dead peer detection exchange, IKE delivers the
result of the NAT detection, and if a NAT box was found, the UDP
port numbers to be used.  The changed IPv4 addresses and the
UDP ports are now used to update the ESP tunnels previously 
negotiated by IKE.  (The home agent will do a similar update.)

Christian   

> > elsewhere.  But IKE/IPsec should be able to have its end 
> points moved 
> > (if  K bit is set by both ends).
>

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 28 Sep 2007 21:22:31 +0900

Hi,

(snip)

> triggers IKE's dead-peer-detection-with-NAT-discovery.

Ok, I see.

> negotiated by IKE.  (The home agent will do a similar update.)

Ok, now I understand it better.  I liked the longer version, thanks.

Regards,
Shinta