Re: issue 34 proposal

 In your previous mail you wrote:

   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.

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

[email protected]

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.