Subject: RE: [Mobike] issue 34 proposal

From: <[email-masked]>
Date: Thu, 8 Sep 2005 09:48:46 +0300

Hi,

there is one situation where "dynamic updates" has clear
advantage: voice. Dynamic updates survives much faster 
than IKE approach and call would stay up.

And yes, I know VoIP is out of the scope, but still IPsec is used to
protect voice traffic as well, and if possible that should be taken
into account.

Regards,

Mika

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 07 September, 2005 17:17
> To: [email-masked]; [email-masked]
> Subject: RE: [Mobike] issue 34 proposal
> 
> 
> Although I have earlier supported the "dynamic updates"
> approach, I'm starting to think that handling this with explicit
> IKE-level messages might be easier.  Since we already send
> the DPD messages anyway, allowing them to contain NAT_DETECTION 
> payloads is very simple (and might be worth doing even if we 
> chose dynamic updates, the two are not totally exclusive).
> 
> And if we do this, then there isn't that much need for a separate
> path test message, so perhaps it's simpler to leave it out...
> 
> So I support your proposal on issue 34.
> 
> Best regards,
> Pasi
> 
> > -----Original Message-----
> > From: ext Jari Arkko
> > Sent: Wednesday, September 07, 2005 1:05 PM
> > To: [email-masked]
> > Subject: [Mobike] issue 34 proposal
> > 
> > 
> > This is a suggestion for a potential resolution of issue 34.
> > First, it seems that issue 34 is really about two separate
> > problems:
> > 
> >    Part a: How do we survive NAT reboots? ESP vs. IKE update?
> >    Part b: Do we have a separate path test message or not?
> > 
> > For part a, we have discussed probing frequencies and hardware
> > issues. List discussion on the probing seems to converge to
> > the conclusion that IKE-based messages for this purpose would
> > be OK. I'm not sure if we have come to any conclusion on the
> > hardware/implementation problem issues: There's a difference
> > where IKE-based messaging does not need hardware support
> > for ESP address changes. On the other hand we're not quite
> > sure if lack of hardware support is an issue for the ESP-based
> > approach either -- hardware evolves while deployment of new
> > features is ongoing. And as we are talking about a special case
> > to begin with, it may not be critical to have this support in
> > all devices at all times.
> > 
> > For part b, we have discussed whether the separate message
> > is easier to describe or not, and whether the separate message
> > can be sent in cases where additional IKE messages would have
> > to be delayed due to the usual IKE processing rules (e.g., when
> > connectivity breaks during an already ongoing movement operation).
> > In the latter discussion, it seems that we came to the conclusion
> > that if this happens, the worst that can happen is delay of
> > one roundtrip.
> > 
> > Based on the above I'd like to suggest that we pick
> > IKE based messages for NAT reboot/change detection,
> > and IKE messages for the path testing. Comments?
> > 
> > I asked Pasi to write some text for this, see below.
> > 
> > 2.X Changes in NAT Mappings
> > 
> >    IKEv2 performs Dead Peer Detection (DPD) if there has 
> recently been
> >    only outgoing traffic on all of the SAs associated with 
> the IKE_SA.
> > 
> >    In MOBIKE, these messages can also be used to detect if NAT
> >    mappings have changed (for example, if the keepalive internal is
> >    too long, or the NAT box is rebooted).  More 
> specifically, if both
> >    peers support both this specification and NAT Traversal,
> >    NAT_DETECTION_*_IP payloads MAY be included in any INFORMATIONAL
> >    request; if the request includes them, the responder MUST also
> >    include them in the response (but no other action is 
> taken, unless
> >    otherwise specified).
> > 
> >    When the original initiator is behind a NAT, it SHOULD include
> >    these payloads in DPD messages, and compare the received
> >    NAT_DETECTION_DESTINATION_IP payload with the value from the
> >    previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT
> >    response).  If the values do not match, the IP address 
> and/or port
> >    seen by the responder has changed, and the initiator SHOULD send
> >    UPDATE_SA_ADDRESSES as described in Section 2.3.
> > 
> >    When MOBIKE is in use, the host not behind a NAT SHOULD 
> NOT use the
> >    dynamic updates specified in [IKEv2] Section 2.23 (where the peer
> >    address and port is updated from the last valid authenticated
> >    packet).  This ensures that both peers have a consistent view of
> >    when addresses are to be changed, and prevents conflicts between
> >    MOBIKE-originated updates and NAT-T dynamic updates.  It 
> also means
> >    that an INFORMATIONAL exchange that does not contain
> >    UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be
> >    used for, e.g., testing whether a particular path works.
> > 
> > (And remove Section 2.5 about separate PATH_TEST exchange.)
> _______________________________________________
> 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: Jari Arkko <[email-masked]>
Date: Thu, 08 Sep 2005 11:20:12 +0300

>protect voice traffic as well, and if possible that should be taken
VoIP is not necessarily out of scope. The group's
intention is not to develop a protocol that goes
together with a large set of optimizations for
various scenarios (like in Mobile IPv6, for instance).
But its still OK to choose our base mechanisms
in a manner that covers as many application
needs as possible, even VoIP.

Re: specific issue with dynamic updates. If I recall
Pasi's text correctly, it said "SHOULD NOT" for
using the dynamic updates -- this means that it
would still be possible for, say, a MOBIKE-based
IMS phone to go against the SHOULD NOT and
use the dynamic updates, given that the importance
of this was determined to be high in the given
environment. However, I would like to remind
that the path testing, MOBIKE mechanisms, DPD,
dynamic updates, other L3 mechanisms are not the
best option when fast detection is desired. They
are necessary when (a) there are no other mechanisms
and when (b) problems occur somewhere along the
path and not the first link.

However, it seems to me that most practical
problems occur on the first link and
are detectable by L2 indications, IPv6 NUD
and the like. Many path problems also have
a more permanent nature (e.g., firewall doesn't
let you through) that allows them to be avoided
by the path test mechanism.

In conclusion I think MOBIKE can work pretty
efficiently when it comes to first link problems
and permanent path problems. The dynamic
updates would help, but only in the case of
rebooting/forgetful NATs. (I'm not saying thats
not important, just trying to quantify the impact.)

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 8 Sep 2005 16:04:42 +0300

> than IKE approach and call would stay up.

NAT rebooting will cause probably tens of seconds or even minutes of
network lossage anyways, so that will normally cause people to break
the connection and try to reconnect before that. I think most of my
friends will usually allow about 2-10 seconds of bad connection in gsm
phone, before they will hang up and redial trying to fix the problem.
Most of the NATs boot much slower than that.

> protect voice traffic as well, and if possible that should be taken

I do not think VoIP makes any difference here. If the NAT is really
rebootted, it does not really matter if the connection is restored in
120 seconds (when the first ESP packet reaches the other end after NAT
if finally up), or if it takes little longer before the DPD kicks in.

Another case of causing NAT mapping disappearing is the too long
keepalive, but that should not really matter in VoIP traffic, as there
is traffic going on fast enough to keep the NAT mappings up.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2005 17:27:08 +0200

In your previous mail you wrote:

   
=> here NAT rebooting includes NAT loosing its state and unfortunately
this kind of events is more frequent and fast.

=> another case so there still are other cases...

Regards

[email-masked]

PS: please don't forget that NAT traversal is explicitely outside
the WG charter.
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Mohan Parthasarathy <[email-masked]>
Date: Thu, 8 Sep 2005 10:49:06 -0700 (PDT)

> PS: please don't forget that NAT traversal is

I don't know what this means. Do you mean to say
MOBIKE should not care about NATs ? The "issue 34" is
about a specific case of dynamic updates which also
has an impact on PATH_TEST messages. So, just arguing
about dynamic updates alone does not get us anywhere.

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2005 23:58:14 +0200

> PS: please don't forget that NAT traversal is
   
   I don't know what this means.

=> simply: In particular, the WG shall NOT develop mechanisms for the
following functions:

o IP address changes done by third parties (NATs, firewalls etc). In
  particular, MOBIKE shall not replace or modify IKEv2 NAT traversal
  function. MOBIKE handles IP address changes initiated by one of the
  endpoints of the security associations. NAT traversal handles other
  address changes. MOBIKE should not be tightly coupled with the NAT
  traversal function, but it is necessary to specify in which cases
  (if any) they can be used together, and how they interact.

So this discussion itself is in the charter (last statement) but
some proposed solutions can be outside.

   Do you mean to say MOBIKE should not care about NATs ?

=> I mean it should care only inside the limits described in the charter.

   The "issue 34" is
   
=> one can consider than #34 is about the interaction between MOBIKE
and NAT-T in cases they are used together.
   
Regards

PS: http://www.ietf.org/html.charters/mobike-charter.html
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 8 Sep 2005 19:02:43 -0700

> => I mean it should care only inside the limits described in the charter.
To me the charter is too restrictive and the above paragraph is very ambiguous.
It would be a waste of time discussing it now. 

> and NAT-T in cases they are used together.
No, it is more than that. If you use implicit updates (as in IKEv2 NAT-T), then
you also need a mechanism to prevent implicit updates so that you can
find working path between the peers. We have discussed enough on this
topic now :-)

-mohan

---

From: Jari Arkko <[email-masked]>
Date: Mon, 12 Sep 2005 17:22:37 +0300

>this kind of events is more frequent and fast.
This is true.

--Jari