Subject: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection

From: <[email-masked]>
Date: Tue, 16 Aug 2005 18:46:39 +0300

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

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 16 Aug 2005 20:15:57 -0700

Pasi,

Sorry if this was discussed at the meeting. I did not understand a couple of things in this mail

1) You mention implementation complexity. I saw some reference to it in the slides if i am not
     mistaken. Also, Jari mentioned something in his mail. Is this general "complexity" of MOBIKE ?
     or something specific to this feature i.e NAT traversal ? Having implemented NAT traversal,
     i don't know how it can be considered complex considering the complexity of IKEv2 itself :-)
     So, i am missing something..

2) Could you clarify how alt.2 increases the IKEv2 messages for the responder ? I understand that
     there is an explicit message to update the address. But you seem to be talking about a different
     thing. So, could you clarify ?

thanks
mohan

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 16, 2005 8:46 AM
Subject: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT reboot detection

Best regards,
Pasi

---

From: Jari Arkko <[email-masked]>
Date: Wed, 17 Aug 2005 08:03:01 +0300

>     So, i am missing something..
I guess the main complexity that people were worried about
is that the *ipsec* part needs to detect a changed address
and tell this to the IKE part. This may involve a PFKEY extension,
among other things, and may be hard on a hardware that
does IPsec but does not have this address detection function.

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 18 Aug 2005 18:34:53 -0700

> among other things, 
Linux (2.6) uses netlink sockets for this purpose. The hook is there and the
event does not get generated from IPsec to IKE. But it is trivial to implement.
So, if some one wants to cook up a PF_KEY extension, they can do so
and it should not be a problem. If someone feels that this functionality is needed,
i don't think this is hard to implement. Perhaps, the real reason is nobody
needs it and hence it does not seem to be there. So, i don't agree that this
is complex.

> and may be hard on a hardware that
Ok. Again, i am not sure whether the reason it does not exist in hardware today
is because there is a lack of need for it or it is difficult to do it in hardware ?
As VPN gateway most likely will use hardware acceleration and as this
feature does not seem to be present in the hardware, would it not make
sense to use alt.3 ? Note that we can't help with the current IKEv2 NAT
traversal. At least  there is some *reason* (complexity, no hardware support,
 security etc.) why it does not exist today. Perhaps, we can make this work
with MOBIKE if we don't rely on the IKEv2 NAT traversal mechanism.

-mohan

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 19 Aug 2005 13:48:20 +0300

Mohan Parthasarathy writes:
> Ok. Again, i am not sure whether the reason it does not exist in
> hardware today is because there is a lack of need for it or it is
> difficult to do it in hardware ?

Mostly because it has not been needed before this. And we are now
talking about the IPsec hardware, not just basic crypto hardware.

There is two issues there.

Firstly you need to be able to do the actual update of the outer
tunnel address. I think none of the hardware drivers support APIs for
doing that, and I am not sure if any of the actual hardware support
that. You can probably do it by reading information from old SA,
removing the old SA and install new SA, with new outer address, but
with same SPI, keys, window and sequence number. The problem there is
that hardware might not give ability to read the window and sequence
number from inside the chip.

That feature is needed for mobike anyways, so we need to find solution
for that (might require new hardware, but hopefully hardware driver
updating is enough (depending on the hardware limitations)).

The second case is to get the notifications from the hardware when the
outer IP-numbers do not match the ones configured to the SA. This is
case that is only needed for the NAT-T dynamic updates. I am doubtful
that any current hardware supports that, and I haven't really found
out suitable workaround to be able to emulate that on hardware. It
might require software check for each packet, which might destroy the
hardware speedups... 

> As VPN gateway most likely will use hardware acceleration and as
> this feature does not seem to be present in the hardware, would it
> not make sense to use alt.3 ?

Thats why I am saying alternate 3 is better, as it requires less
changes or updates to the hardware.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Aug 2005 13:03:27 +0300

>changes or updates to the hardware.
One could also support ESP-based updates on devices
that can do this, and say "this feature is not supported"
on others -- we are still talking about a corner case.
But people may have different opinions as to how
important support for this is under all circumstances.

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 31 Aug 2005 18:09:11 -0700

> important support for this is under all circumstances.
If you do IKEv2 like updates, then you need a separate PATH_TEST
message (outside the SA) so that PATH_TEST does not cause updates
to SA. By requiring an explicit update, we avoid a separate PATH_TEST
message. Is that an advantage ?

-mohan