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

Pasi,

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

mohanp> Yes, this would be nice. By having the path test outside the SA,
mohanp>  you never update any SA with the new addresses while
mohanp>  testing the new path. Hence, you avoid changing the
mohanp> existing NAT-T behavior (which may or may not be desirable).

mohanp>  But there a case in the draft today for which the message
mohanp>  is sent with the different address from that of the operational
mohanp>  pair and the peer does not update the address i.e when  
mohanp>  the operational pair does not work, you reransmit the existing
mohanp> message in the window with the new address but the peer
mohanp > does not update with the new address until the CHANGE_PATH
mohanp> is sent (section 2.3 ). If there is a NAT in this path, are we not
mohanp> changing the behavior already ? So, why can't this be extended
mohanp> to path test message also i.e path test messages don't update
mohanp> the addresses on the SA  unless explictly notified? Am i missing 
mohanp> something....

-thanks
mohan


 > > 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
_______________________________________________
Mobike mailing list
[email protected]
https://www.machshav.com/mailman/listinfo.cgi/mobike