Subject: RE: [Mobike] issue 34 proposal

From: <[email-masked]>
Date: Wed, 7 Sep 2005 17:16:55 +0300

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

---

From: <[email-masked]>
Date: Thu, 8 Sep 2005 21:02:44 +0300

Right, this and the explanation from Jari makes it clear that there
isn't that much advantage in "dynamic updates". So IKE approach is 
fine with me. 

And for path testing, I don't see why separate path_test message
should be used (implemented), so I support IKE version here too.

Mika

-----Original Message-----
From: ext Tero Kivinen [mailto:[email-masked]]
Sent: 08 September, 2005 16:05
To: Joutsenvirta Mika (Nokia-TP/Tampere)
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Mobike] issue 34 proposal

[email-masked] writes:
> there is one situation where "dynamic updates" has clear
> advantage: voice. Dynamic updates survives much faster 
> 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.

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

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: "Stephane Beaulieu (stephane)" <[email-masked]>
Date: Fri, 9 Sep 2005 10:43:08 -0400

> 
> Stephane Beaulieu (stephane) writes:
> > > 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).
> > 
> > Not sure I follow your second point.
> > 
> > You're saying that the original NAT mapping was bi-directional, but 
> > after the reboot, a new NAT mapping was given but this one is 
> > uniderctional?  I admit my experience with NAT is limited, 
> but I have 
> > never seen this happen.
> > 
> 
> When the NAT mapping is lost most commonly it can only be 
> recreated from the behind of NAT. This will create 
> bi-directional mapping.
> 
> The problem with the automatic updating of the address pair 
> when receiving valid packet from the remote end is that if 
> you have working address pair A1, B1 (with NAT), and you are 
> using it. You also have another address pair A2, B1 (with or 
> without NAT) and you do not know if it works yet. So now if 
> you send IKEv2 probe packet with A2, B1 to the remote host, 
> the remote host will notice that this is valid packet for the 
> IKEv2 SA, thus it will move the traffic immediately to that 
> A2, B1 pair when receiving that packet.

OK.  So you're assuming that when we dectect a port change at the ESP
layer, then we'll send probes to all possible paths.  I was not making
this assumption.

> 
> Now if that A2, B1 path happened to be uni-directional for 
> some reason, so the reply packets B1, A2 will not get through 
> then we managed to cause connection problem while we still 
> had completely valid and working address pair A1, B1. Even 
> when we later retransmit that packet to A1, B1 address pair, 
> the other peer now notices as this retransmission, and 
> replays its old answer back. It might not update the mapping 
> at that point (it is not clear from the ikev2 draft wheather 
> replays should be consider "valid authenticated packet").
> 
> If we disable the IKEv2 automatic updating of the remote 
> peers address, then we can send that probe packet, and it 
> will not cause any connection problems. After a while when we 
> notice that we are not getting reply back, we retransmit that 
> using other addresses, i.e. A1, B1, and other end would then 
> reply to us to B1, A1 address and the exchange is finished.
> 
> I would actually say that replay is not "valid authenticated packet"
> as it would be too easy for the attacker to grab one "valid 
> authenticated packet" from the link, modify the IP headers 
> and the replay that every second, to make sure the traffic is 
> all the time redirected to the host he wants to attack. 

This is a good point.  An attacker could fool us into changing our
database just by modifying our outer headers.  I hadn't thought of this.
I think what you're saying is that the only way to prevent this, is to
do a probe to 'confirm' the peer's new address, but that doing so might
cause you to choose a bad path.

Could you not do a probe (or some other exchange) JUST to the new
address to verify that the peer is indeed reacheable on this new
IP/port?.  Of course you'd have to rate-limit this to avoid someone
forcing you to build/send endless probes.

> 
> > I have however seen NAT mappings get lost many, many times.
> 
> Was the problem there NAT rebootting, or too long keepalives 
> or something else? 

I've seen it all :)  

> 
> > BTW, have you seen the number of home/SOHO router/NAT boxes you can 
> > buy today for about $5.  Reliability is not the first word 
> that comes 
> > to mind.
> 
> True, but in that case I would assume they know who to 
> blame... :-) Still most of those small NAT boxes have enough 
> memory and so small amount of traffic that they do not have 
> really reason to remove NAT mappings very fast. And I do not 
> think they crash that often. Again if they crash that will 
> cause long delay anyways.

Who are you going to call though?  The guy who sold you a $10,000 box
with a support contract, or some 1-800- support number which is now
disconnected. ;)

> 
> > I'm willing to implement it both ways because the 
> cost/complexity is 
> > fairly low, and I can see how doing it via ESP detection 
> only might be 
> > more difficult for some vendors.
> 
> So perhaps we should say you MUST NOT do automatic update 
> with IKEv2 packets (breaks the probing), but you MAY do it 
> for ESP packets? It will add the another module causing 
> address updates, and you need to make sure the policy for the 
> MOBIKE and that automatic update module are same.
> 
> I really like the explicit address update because it will put 
> the all policy decision about address changes in exactly one 
> place, i.e in the MOBIKE module.

It would be ideal, but I would also like to be able to recover from
badly-behaving NAT boxes, if we can with a relatively low cost.

---

From: "Stephane Beaulieu (stephane)" <[email-masked]>
Date: Wed, 28 Sep 2005 08:42:02 -0400

I had indeed missed that text.  Thanks.

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Wednesday, September 28, 2005 2:52 AM
> To: Stephane Beaulieu (stephane)
> Cc: [email-masked]; Jari Arkko; [email-masked]; 
> Tero Kivinen
> Subject: Re: [Mobike] issue 34 proposal 
> 
>  In your previous mail you wrote:
> 
>    > => we are speaking about ESP so I don't understand the "with 
>    > NATD payloads" (BTW with NATD payloads only the real source 
>    > can put a fake address as they are protected).
>    
>    What I'm saying is that if I detect a NAT change at the ESP layer
> 
> => how NAT-T/implicit update (ESP detection is a part of it) 
> and MOBIKE/explicit update can interfere is a closed point 
> (which both has no interest for me and does what you like).
> 
>    >    In fact, I'm beginning to think that ESP detection 
> might cause more
>    >    problems than it solves...
>    >    
>    > => ESP detection is in IKEv2, if you believe it you should 
>    > have objected during the IKEv2 last call.
>    
>    I think we must be talking about different things.  I see 
> nothing in the
>    ikev2-17 that describes how NAT decisions are made using 
> ESP packets.
> 
> => it is at the end of 2.23 page 39:
> 
>       There are cases where a NAT box decides to remove mappings that
>       are still alive (for example, the keepalive interval is 
> too long,
>       or the NAT box is rebooted). To recover in these cases, 
> hosts that
>       are not behind a NAT SHOULD send all packets (including
>       retransmission packets) to the IP address and port from the last
>       valid authenticated packet from the other end (i.e., dynamically
>       update the address). A host behind a NAT SHOULD NOT do this
>       because it opens a DoS attack possibility. Any authenticated IKE
>       packet or any authenticated UDP encapsulated ESP packet can be
>       used to detect that the IP address or the port has changed.
> 
>       Note that similar but probably not identical actions will likely
>       be needed to make IKE work with Mobile IP, but such 
> processing is
>       not addressed by this document.
> 
>    All I see is text describing how to use ISAKMP NAT-D 
> payloads to detect
>    if a NAT box is present in the network.  The draft is 
> rather large, so I
>    may have missed it.  Can you point me to some text that 
> describes how
>    ESP pkts are used to detect a NAT, or a NAT mapping change?
>    
> => now you have the text about NAT mapping change detection, 
> including IKE, ESP and implicit update. And in a past message 
> in this list you have the decision (and proposed text) about 
> application of this in a mixed NAT-T/MOBIKE context:
>     References: 
> <[email-masked]>
> 
>     Based on discussion, it appears that most people prefer
>     the following:
> 
>        1) NAT-detection payload -based NAT reboot/change detection
>        as a complement to existing source address -based
>        mechanisms. This mechanism would be used if MOBIKE
>        is on, because otherwise MOBIKE probing would become
>        harder.
> 
>        Detection would be done by including NAT detection
>        payloads in dead peer detection messages.
> 
>        Existing source address -based detection is still allowed in
>        limited manner:  "MUST NOT do automatic update with
>        IKEv2 packets when MOBIKE is used (breaks the probing),
>        but you MAY do it for ESP packets."
> 
>        2) Use IKE messages for the path testing that is needed
>        in MOBIKE.
> 
>     I (Jari) have specifically left out the conclusion about whether
>     to do return routability after a NAT change is detected.
>     I'm hoping its covered by the policy that we already have
>     for return routability usage. If people disagree about this
>     we'll open a separate issue on it.
> 
> Regards
> 
> [email-masked]
>