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

From: <[email-masked]>
Date: Thu, 14 Jul 2005 15:21:33 +0300

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

---

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

> the current path is working (and without disrupting ongoing

Yes, I know it was discussed earlier, but simply pointed it out here
to explain why we need to do things here like I explained. So now
people can really decide wheather they want that complication to the
protocol for that feature. 

> product" or "Not invented here / We just like doing things

I do not think it was solved in the IKEv2 NAT-T. If the IKEv2 NAT-T
would be ok, then there would be not need at all to MOBIKE, simply use
IKEv2 NAT-T all the time. We would loose the multihoming aspect and
would waste some bytes on packets, but it would work for the mobility
part.

I do not think the dynamic automatic updates are good for MOBIKE. I
want MOBIKE to be more secure than IKEv2 NAT-T, which means more
controlled way on changing paths on MOBIKE than in IKEv2 NAT-T. If we
also do the same thing on the NAT-T with MOBIKE, then we can get more
security for that part too.

If we only do updating of operational address pair on explicit notify,
then the attacker cannot take any packet and change the addresses of
packet to redirect the packets to some other address.

Instead attacker needs to first distrupt the normal processing of the
packets to get the initiator to do the DPD with address pair update
notify, before he can change the operational address pair, and in that
case it is also processed in the responder site as normal addres pair
updating, which means it is subject to the return routability checks
etc.

If we do use the dynamic automatic update of the IP address of the
IKEv2 NAT-T, then we do not do return routability checks, thus we do
not have as good protection against flooding attacks as we would have
in case of MOBIKE style address update. 

> used with and without MOBIKE?

Yes, it would be marginally simplier for the NAT-T case, but we add
more complexity for all other cases, by adding new protocol to be
implemented. And then we do not get the protection provided by the
MOBIKE. No return routability checks, no N(COOKIE2) etc.

I do not think we want to add new protocol to do path testing, as it
can be done without any extra effort inside the normal IKEv2 MOBIKE
processing. 

What are the benefits of the separate path tests? Can you list me
reasons why we need to have that?

My reasons why I do not want to have separate path test protocol is:

1) I do not want to add yet another extra protocol to same port as
   IKEv2 (we already have 4 there (IKEv1, IKEv2, UDP encapsulation,
   UDP encapsulation keepalives)). (It is not IKEv2 exchange, as it
   does not follow encryption, authentication, message-id, windowing
   etc specifications of the IKEv2).

2) Security implications of non-encrypted, non-authenticated protocol
   are not completely tought out (at least yet).

3) We have already existing code we can use inside the MOBIKE IKEv2
   implementations which can do the same thing. This code is needed to
   be there regardless wheater we have or have not separate path test
   protocol (i.e we need to be able to handle the situation when the
   path breaks down during the IKE negotiation, i.e. we must be able
   to retransmit the IKE packets to alternative addresses).

   This means that by reusing that code we can do the path test, with
   less added code implementations, which means fewer bugs. (The code
   that needs to be added is: disable the (probably not yet
   implemented) automatic dynamic updating of NAT-T address changes;
   add check to DPD that if we are behind NAT and MOBIKE is enabled
   add N(CHANGE_PATH) to the DPD message).
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 14 Jul 2005 21:35:04 -0700

Pasi,

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

<snip>

BR,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 15 Jul 2005 13:07:40 +0300

Mohan Parthasarathy writes:
> mohanp> is sent (section 2.3 ).

Actually I think the responder will change the path, but the initiator
will simply issue new CHANGE_PATH when the first one finishes and the
window again has space. The second one will make sure they have same
information of the current operational address pair.

> mohanp> If there is a NAT in this path, are we not

In my opinion any of the messages should not update the address pair
unless there is explicit CHANGE_PATH notify in the packet. The problem
case can happen when when we are sending that CHANGE_PATH and then we
notice that the address pair we tried to use to send that one (i.e.
the one where we tried to change the address pair to) is broken, and
we need to retransmit it again with different addresses.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike