Issue 34: Separate path test, handling changes in NAT mappings

[email protected] writes:
> 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).

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. 

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

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.

> Option 2: Disable the NAT-T dynamic updates, and create a new
> 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.

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

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

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

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

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

> I'm strongly for option 1 here (although it seems that we
> 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.

> (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.")

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 protected]