Subject: RE: [Mobike] issue 34 proposal

From: "Stephane Beaulieu (stephane)" <[email-masked]>
Date: Thu, 8 Sep 2005 10:37:13 -0400

> 
>  In your previous mail you wrote:
> 
>    Francis Dupont wrote:
>    
>    >=> note that I disagree.
> 
>    Ok. Can you expand the above a bit with
>    some reasons and/or alternative proposals?
>    
> => I am for making the standard mechanism for IKEv2/NAT-T 
> (update by ESP) simply mandatory in MOBIKE environments (option 1bis).
> This is not against the charter (no new things for NAT-T) and 
> can be considered as a MOBIKE profile compatible with the 
> "mainstream" IKEv2.

Francis,

Can't both be done?  If I notice that packets are coming in using a SPI
for which the IP/port doesn't match what I expect, can't I just process
them anyway, and update my sadb?  There doesn't appear anything
interoperability wise to stop you from doing this.  If you update, you
recover NOW.  If you wait for DPD/NAT-T, it will take longer, but still
eventually update.

It means more code to write (since we have to be able to handle 2
different ways of changing NAT mappings), but it does satisfy both
camps.

Stephane.

> 
> Regards
> 
> [email-masked]
> 
> PS: I don't buy the hardware argument (nor such hardware :-).
> _______________________________________________
> Mobike mailing list
> [email-masked]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
> 
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2005 18:04:19 +0200

Can't both be done?

=> yes but the standard NAT-T mechanism is the ESP update and
I don't see why we have to replace it.

   If I notice that packets are coming in using a SPI
   for which the IP/port doesn't match what I expect, can't I just process
   them anyway, and update my sadb?  There doesn't appear anything
   interoperability wise to stop you from doing this.

=> just options >=2

   If you update, you recover NOW.  If you wait for DPD/NAT-T,
   it will take longer, but still eventually update.
   
=> or you don't restrict the SPI to ESP, i.e., you handle all the
port 4500 packets. BTW you don't need to get the IKE SA SPI from
IKE (nor any SPIs in fact), you just have to cache the address/port
per SPI and to detect changes.

=> I am afraid this is no easy to code... In fact, IMHO the issue
is the #34 tries to mix implicit and explicit updates which is
a bad design. This is why I still believe we should have kept
MOBIKE and NAT-T separated.

Regards

PS: I believe the peer behind the NAT has to send some ESP packets
from time to time even it has no traffic in order to keep the state
in the NAT(s). This seems a better way to ensure the ESP update than
to add a DPD-like mechanism for IKE processed at the level.
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 9 Sep 2005 11:44:23 +0300

> recover NOW.  If you wait for DPD/NAT-T, it will take longer, but still

For ESP packets you could do that, but for IKE packets you need
separate path test exchange if you do that, as then you cannot probe
if the path is working with IKE packet, as the probe can break the
link (it would cause traffic to move to that address pair and if that
address pair was unidirectional the connection would be lost because
of that). 

> different ways of changing NAT mappings), but it does satisfy both

Why would you want to write more code just to cover very corner case?

We do not expect the NATs be rebooted or loosing mappings regularly,
it might happen to some people every few months or so, and some people
will probably never see that.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike