Subject: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings

From: <[email-masked]>
Date: Wed, 13 Jul 2005 17:54:03 +0300

Tero Kivinen wrote: 

> It is very simple to say in the MOBIKE protocol, that
> implementations MUST NOT do dynamical address update if MOBIKE
> extensions are enabled, i.e. they MUST always do address
> updates only when receiving CHANGE_PATH message in case MOBIKE
> extensions are enabled.
>
> That will take care of all the problems using normal IKEv2
> packet to test path.
>
<snip>
>
> > Note that if the responder has NAT Traversal enabled, it 
> > can update the addresses in both the IKE_SA and IPsec SAs 
> > as usual (if it implements the "SHOULD" from [IKEv2] 
> > Section 2.23.
>
> There is no reason for the other end to enable the SHOULD in 
> case the MOBIKE is used. We can simply say that it MUST NOT do 
> the dynamic address updates in case MOBIKE is enabled.

Hmm... it seems the issue of a separate path test message
vs. using normal informational exchange for path testing 
depends a lot on how we handle changes in NAT mappings (if 
e.g. NAT is rebooted or keepalive interval is too long).

It seems that we have several possibilities here. Some
preliminary thoughts of what the alternatives might be (but
other alternatives might exist too):

Option 1: Existing IKEv2 NAT Traversal and its dynamic updates
(when using NAT-T, host outside NAT automatically updates the
address/port from any authenticated packet).

Option 2: Disable the NAT-T dynamic updates, and create a new
mechanism for handling NAT mapping changes in MOBIKE.

   Option 2a: Responder (outside NAT) could notify the initiator
   when it sees that the port changed, but wait for initiator's
   CHANGE_PATH message before updating anything.
 
   Option 2b: Initiator could send CHANGE_PATH messages all the
   time just in case the NAT mappings might have changed (even
   though from its point of view, nothing has changed).
  
   Option 2c: More alternatives certainly exist..

Option 3: Disable NAT-T dynamic updates, but don't specify any
alternatives for handling NAT mappings changes (==essentially
break when NAT mappings change).

I'm strongly for option 1 here (although it seems that we
probably need a separate path test message then). Option 3 
does not sound very attractive compared to 1, and at least 2a
would IMHO require rechartering the WG.

(The charter says "the WG shall NOT develop mechanisms for the
following functions: [..] IP address changes done by third
parties (NATs, firewalls etc). [..] MOBIKE handles IP address
changes initiated by one of the endpoints of the security
associations. NAT traversal handles other address changes.")

Best regards,
Pasi
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 14 Jul 2005 11:19:50 +0300

> e.g. NAT is rebooted or keepalive interval is too long).

Not really. The problem only occurs if we want to use the path test to
test previously broken path without affecting the currect path and
there is NAT-T between. If we use path test only when the operational
address pair has already broken down then we do not need to modify
dynamic address updates of the NAT-T. 

> address/port from any authenticated packet).

Note, that the dynamic automatically NAT-T address updates is SHOULD
in the IKEv2 draft, and it is SHOULD because implementors said they
will not implement it, and do not want it to be MUST so they can leave
it out...

I do not know if anybody has yet really implemented it (I know that
our code do have some hooks for it so it can be added, but currently
it is still not implemented).

I do not even know if anybody ever implemented that on the IKEv1
NAT-T. I think most of the implementors consider that feature so small
corner case, that they do not bother implementing it and testing it.

> mechanism for handling NAT mapping changes in MOBIKE.

As IKEv2 NAT-T does not need to do dynamic updates, we might want to
implement our own mechanism anyways, if we consider problem important.

>    CHANGE_PATH message before updating anything.

I do not see need for that. The rebooting of the NAT already caused
lots of packets to be dropped, so the user is going to notice it
anyways. For the non NAT-T user rebooting of the NAT did cause all the
connections to be broken.

We can simply assume that the initiator fixes the issue when it
notices it (by not receiving any packets).

>    though from its point of view, nothing has changed).

Initiator does not know if anything has changed, but something might
have changed, so he might want to make sure that both peers share the
same view of the operational addresses, thus sending CHANGE_PATH
messages, when it sees no traffic from the other end.

>    Option 2c: More alternatives certainly exist..

One option is the initiator to start DPD with NAT-D payloads, and when
it receives reply from the other end, he can compare those NAT-D
payloads to the NAT-D payloads it received earlier, and if they do not
match, he knows the NAT has been rebooted, and can start corrective
actions (i.e. send CHANGE_PATH).

I think 2b is simpliest and offers fast enough recovery in the
rebooting NAT case. The good thing about that is that it does not
require any extra code in the responder (except that responder needs
to disable dynamic automatic updates in case it happened to support
those, and MOBIKE is enabled), and requires very little code in the
initiator (i.e. if NAT-T was enabled, add CHANGE_PATH notify to DPD
packet). 

> break when NAT mappings change).

I think this is the most common case of the IKEv1 and IKEv2 NAT-T
handling today. And would be quite ok for us too, but as the 2b is
better, and it requires so small implementation changes that it will
get implemented, I think that is better.

The MOBIKE implementations needs to implement the CHANGE_PATH anyways
(and yes, I think most of the implementations will at that point also
implement the dynamic automatic updates for regular NAT-T (when no
MOBIKE) as it comes almost free after the infrastructure required for
MOBIKE and CHANGE_PATH is there.

> probably need a separate path test message then).

Option 1 does not require separate path test unless you want to be
able to test unidirectional broken paths, and do not want to cause any
lost packets during the process. 

> Option 3 does not sound very attractive compared to 1, and at least
> 2a would IMHO require rechartering the WG.

Yes, I do not think the option 3 is really useful option, as it simply
leaves the problem open.

> associations. NAT traversal handles other address changes.")

I am not sure if even the 2a would require rechartering, at least 2b
and 2c is more or less describing "how they interact" (NAT-T and
MOBIKE).

Actually the original idea behind the charter was that MOBIKE would
not do anything about NATs, i.e. if NAT is detected, then we do not
use MOBIKE, but simply use normal NAT-T (note the "if any" in the text
saying "MOBIKE should not be tightly coupled with the NAT traversal
function, but it is necessary to specify in which cases (if any) they
can be used together, and how they interact"). This was already
decided in the WG that we do want to use MOBIKE and NAT-T together.

My understanding of the that charter text is that we are not allowed
to modify actual UDP encapsulation part of the NAT-T, and we must use
the NAT-T mechanisms in the IKEv2, but we can profile the NAT-T (i.e.
say which features are mandatory to implement and which are not, or
which features must be enabled or disabled).
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Sun, 31 Jul 2005 10:46:54 +0200

In your previous mail you wrote:

   can be used together, and how they interact").

=> the original idea was the right one IMHO...

   This was already decided in the WG that we do want to use MOBIKE
   and NAT-T together.
   
=> and this even there is no real world case of MOBIKE+NAT-T...

=> if you mean that the NAT-T dynamic update is mandatory to implement
I agree!

Regards

[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike