[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

PMTU discovery for tunnels: issues 78, 49, 81


Matt and I came up with a heuristic for what IPsec gateways should do
when encapsulating. The goal is to permit a solution that IPsec gateway
vendors can use *TODAY* to deal with ICMPs going missing, that still works
if the ICMPs are effective, and will not break the new proposal for
PMTU, which does not rely on getting ICMPs back. 

My strawman text needs a revision as it was overly complicated in its
wording, which I hope to do before Monday.  

RFC2401bis specifies more behaviour for PMTU, which I think that
this (PMTUD) WG should take on as a review item.

What I don't know is what we can do for IPsec gateways to determine
actual (outer) size of the tunnel in question. (in the case where
the tunnel experiences an MTU constraint between security gateways).
This affects whether or not the DF bit should be copied - if the ICMPs
are missing, (or ineffective, as they don't return enough info, of
it the tunnel carries multiple sources of traffic) then it isn't clear 
how to make things work.

Note that fragmentation before encapsulation can present risks if in high
speed networks, particularly when they use large TCP windows. Matt explained
the situation to me, which made my mouth hang open when I realized what was

Fragmentation of the ESP packet is somewhat better, if the ESP is doing
integrity, as it has much stronger integrity check than the tunneled
TCP. I.e. if the fragments get reassembled wrong, the integrity check is
almost guaranteed to fail. 

] Collecting stories about my dad: http://www.sandelman.ca/cjr/ |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@xxxxxxxxxxxxxxxxxxxxxx http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys