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

Tero Kivinen wrote:
> 
> [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.

This was discussed already in May 2005... At least some people
thought that it would be useful to allow path testing even when
the current path is working (and without disrupting ongoing
communication).

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

Linux (Open|something)SWAN implements it for IKEv1 NAT-T. 
I don't know about others...

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

I'm not quite sure how important problem this is, but since the
problem is already solved in IKEv2 NAT-T, I think we should have
really good reasons for not using that solution. (Much better
ones than "I didn't bother to implement that SHOULD in my
product" or "Not invented here / We just like doing things
differently").

<snip>

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

If that's the case, wouldn't it be simpler to just use the 
same mechanism (dynamic automatic updates) when NAT-T is
used with and without MOBIKE?

BR,
Pasi