RE: issue 34 -- ESP vs. IKE based NAT reboot detection

Hmm... I think both alternatives 1 and 3 have good arguments for them.

>From implementation point of view, alternative 1 (IKEv2 NAT-T) places
implementation complexity in the peer outside NAT (typically VPN
gateway), while in alternative 3 the peer behind NAT (e.g., VPN
client) does most of the work. The latter would perhaps be more 
consistent with the "initiator decides" approach (and seems "nicer" 
in other ways, too). My only concern with it is that it could result 
in non-insignificant increase of IKEv2 exchanges for the responder... 
(if people who care about NAT mapping changes start lowering the 
threshold "X" for doing DPD).

On the other hand, a gateway that is worried about this increase does
have ways of preventing the peer from doing unnecessary DPD.  For
instance, if it's currently receiving packets from the peer, but not
sending anything (because it hasn't received anything from the network
"behind the gateway"), it could send "dummy" (TFC padding only) ESP
packets every now and then. If these reach the peer (behind NAT),
it will know the gateway is still alive and NAT mapping OK, so it 
would not do DPD unnecessarily.

Specification-wise, alternative 3 would be quite simple. It looks like
the main addition would be that implementations that support NAT-T can
include NAT_DETECTION_* payloads in any Informational request (and if
they're included in the request, the responder must also include them
in the response, but no other action is necessarily taken).  This
allows the initiator to detect when a NAT mapping has changed,
and send UPDATE_SA_ADDRESSES.

(On the other hand, alternative 1 -- pointing to IKEv2 NAT-T spec --
is quite simple as well...)

Best regards,
Pasi

> -----Original Message-----
> From: ext Jari Arkko [mailto:[email protected]]
> Sent: Tuesday, August 16, 2005 4:05 PM
> To: MOBIKE Mailing List; Tero Kivinen; Eronen Pasi 
> (Nokia-NRC/Helsinki)
> Subject: issue 34 -- ESP vs. IKE based NAT reboot detection
> 
> 
> I'd like to open discussion on this issue. Please read
> the slides and notes from
> 
>  http://www3.ietf.org/proceedings/05aug/slides/mobike-2.pdf
>  http://www.machshav.com/pipermail/mobike/2005-August/000912.html
> 
> and post your thoughts on this issue. As far as I can
> determine, we are primarily discussing two alternatives:
> 
> Alt 1: The approach in -01 which retains what IKEv2 does
> when NAT mappings change. I.e., there's a SHOULD in the
> IKEv2 spec that allows implementations to update mappings
> based on what they see happening for the UDP-encapsulated
> ESP packets.
> 
> Alt 3: Tero's approach, which says not to use this feature
> in IKEv2 when MOBIKE is employed, and instead relies on
> periodic IKE probes.
> 
> Based on the discussion in IETF-63, it seems that both
> approaches work, but the tradeoffs are mainly in the
> area of ease of implementation vs. pressure to decrease
> probing/keepalive intervals.
> 
> We do know that there are some (even if few) implementations
> of IKEv1/v2 that employ the ESP-based check. Similarly, some other
> implementations aren't doing it.
> 
> Note also that we need to keep in mind what the requirement
> level for this feature is or will be. If its not a MUST, this means
> that whatever bad effect there may be (implementation diffuculties
> or additional messaging), you do NOT have to suffer from that
> unless you also need to support this feature.
> 
> --Jari
> 
>