Subject: RE: [Mobike] issue 34 proposal

From: "Stephane Beaulieu (stephane)" <[email-masked]>
Date: Fri, 9 Sep 2005 08:06:15 -0400

> 
> Stephane Beaulieu (stephane) writes:
> > Can't both be done?  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.  If you 
> > update, you recover NOW.  If you wait for DPD/NAT-T, it will take 
> > longer, but still eventually update.
> 
> 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.

I have however seen NAT mappings get lost many, many times.

> 
> > 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.
> 
> Why would you want to write more code just to cover very corner case?

Job security :)

Nah, seriously though, I prefer the automatic updates because of the
speed of recovery.  Though you claim that NAT mapping drops are rare, my
experience is different.  Yes, they might be rare enough, but every time
it happens, I have to spend 1 hour looking through customer's syslogs to
figure out why things stopped working.  I hate doing that ! :)

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.

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.

> 
> We do not expect the NATs be rebooted or loosing mappings 
> regularly, it might happen to some people every few months or 
> so, and some people will probably never see that.
> --
> [email-masked]
> 
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 9 Sep 2005 17:15:08 +0300

> uniderctional?  I admit my experience with NAT is limited, but I have

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.

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. 

> I have however seen NAT mappings get lost many, many times.

Was the problem there NAT rebootting, or too long keepalives or
something else? 

> today for about $5.  Reliability is not the first word that comes to

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.

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Sep 2005 14:05:38 +0300

Tero Kivinen wrote:

>packets (breaks the probing), but you MAY do it for ESP packets? 
>  
>
This would work for me (and the complexity cost would be
only on those implementations that actually do the MAY).

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 15 Sep 2005 12:58:44 -0700

> only on those implementations that actually do the MAY).
Agreed.

-mohan