Subject: [Mip6] IKEv1 NAT Traversal and DS-MIPv6

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Mar 2006 23:05:57 +0200

For DS-MIPv6 I suggest using concepts described in RFC 3947 "Negotiation 
of NAT-Traversal in IKE" when dealing with NAT changing port numbers. 
Not necessarily using IKE as described there, but I'd contemplate 
similar mechanisms.

These mechanisms should offer secure detection of changing UDP port 
numbers and cope with dynamically changing port numbers.

Alex

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

---

From: Francis Dupont <[email-masked]>
Date: Mon, 27 Mar 2006 23:14:08 +0200

In your previous mail you wrote:

   
=> ¿ do you mean (quoted from RFC 4306 IKEv2):

      There are cases where a NAT box decides to remove mappings that
      are still alive (for example, the keepalive interval is too long,
      or the NAT box is rebooted).  To recover in these cases, hosts
      that are not behind a NAT SHOULD send all packets (including
      retransmission packets) to the IP address and port from the last
      valid authenticated packet from the other end (i.e., dynamically
      update the address).  A host behind a NAT SHOULD NOT do this
      because it opens a DoS attack possibility.  Any authenticated IKE
      packet or any authenticated UDP-encapsulated ESP packet can be
      used to detect that the IP address or the port has changed.

Regards

[email-masked]

PS: BTW we'll finish with port number 4500 (:-)...

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Mar 2006 23:25:00 +0200

> => ¿ do you mean (quoted from RFC 4306 IKEv2):

i Yes I kind of mean IKE :-)

>       used to detect that the IP address or the port has changed.

I think it is still possible to use similar mechanism that IKE uses to 
deal with dynamically changing NAT mappings but not necessarily add the 
IKE message exchanges.  Or so.

Alex

---

From: Francis Dupont <[email-masked]>
Date: Mon, 27 Mar 2006 23:30:45 +0200

=> there is no IKE exchanges involved. The idea is increadibly simple:
just use the address of the last seen valid packet. The security comes
from the word valid but in fact even without it the mechanism is not
unsafe because an attacker has to enter a course with the real peer,
so it has to expose itself. Of course this mechanism is very attractive...
   
Regards