Re: [secdir] Topic for our SecDir lunch: The PTB-PTS ICMP-based Attack against IPsec Gateways

["Moriarty, Kathleen" <[e-mail]>]

We can touch on this at the meeting.  There should be time, but I agree with Yoav.

Thanks,
Kathleen

Sent from my iPhone

On Nov 10, 2014, at 1:40 PM, "Vincent Roca" <[e-mail]<mailto:[e-mail]>> wrote:

Thanks Yoav. Yes, having this discussion on IPsec related mailing lists is needed, but I think SecDir
can also be appropriate if the problem applies to other tunneling techniques as well (which we didn’t test).
Honestly speaking, I’m trying to figure out how to proceed the best and advices like yours are welcome.
Cheers,

  Vincent

Le 10 nov. 2014 à 13:20, Yoav Nir <[e-mail]<mailto:[e-mail]>> a écrit :
Hi, Vincent.

Not at all opposed to bringing this up at SecDir lunch, but wouldn’t the IPsecME working group session and the ipsec mailing list be the more appropriate venue?

The SecDir is made up of people with (hopefully) enough knowledge about security to review an arbitrary draft and check that security has been considered and appropriate considerations documented.

The attack described in that paper is not even specifically related to IPsec. It could plague any tunneling mechanism such as L2TP, GRE, PPTP, IP-in-IP. Although this is an attack, it might be appropriate for the transport area.

Yoav

On Nov 10, 2014, at 11:13 AM, Vincent Roca <[e-mail]<mailto:[e-mail]>> wrote:

Hi everybody,

There’s a subject I’d like to discuss with you tomorrow during our SecDir lunch if we have time for that.
It’s about a DoS on IPsec we have found with my previous PhD student, Ludovic. It’s described here:

« Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gateways », GLOBECOM’14.
PDF is freely available at: https://hal.inria.fr/hal-01052994/en/

The study has limits since it only focusses on IPv4 and a single OS (stable Squeeze Debian distribution).
That being said, we have an exploit using default IPsec configuration, either preventing end-hosts to open
new TCP connections (when relying on PMTUd) or creating large initial delay/performance penalties
(when relying on PLPMTUd). And UDP connexions will be affected too…
The only thing an attacker needs is to be on the IPsec tunnel path with the ability to eavesdrop encrypted
traffic and send back a forged packet (e.g., a non encrypted Wifi network should be sufficient, I see many
of them available at IETF ;-)

So we’d like to have your feedback in particular on the following two points:

- Is there an appropriate way to manage Path MTUs in presence of IPsec tunnels when we are already
at the minimum PMTU size?

- Is there an appropriate way to make the end-host (in the « red » protected LAN) and its IPsec gateway
understand each other when we are already at the minimum PMTU?

This is clearly a tricky situation that may not be well addressed today. Is it described somewhere in an RFC
so that implementers have clear guidelines? We didn’t find anything, but it does not mean there’s nothing.
And may the problem be extended to other tunneling technologies that perform encapsulation?

Your feedback is welcome.
Thanks,

  Ludovic and Vincent

--
   Vincent Roca, PhD/HDR, Inria research institute, France
   http://privatics.inrialpes.fr/~roca
_______________________________________________
secdir mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview


_______________________________________________
secdir mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview