Subject: PMTU discovery for tunnels: issues 78, 49, 81

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Nov 2003 13:00:29 -0500

-----BEGIN PGP SIGNED MESSAGE-----

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

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[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: Yoav Nir <[email-masked]>
Date: Mon, 17 Nov 2003 14:35:17 +0200

Hi Michael,

For those of us who weren't there, can you please explain the 
situation?  What are the risks?

> -----BEGIN PGP SIGNED MESSAGE-----
<snip>
> the situation to me, which made my mouth hang open when I realized 
<snip>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Nov 2003 10:19:06 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Yoav" == Yoav Nir <[email-masked]> writes:
    Yoav> For those of us who weren't there, can you please explain the 
    Yoav> situation?  What are the risks?

  I am not the best person to explain risk of PAWS with fragmentation.
  Matt said he would write something.

  Here is the summary of the discussion:

  Assume
      - very fast networks using large window TCP 
      - networks that connect them, with MTU constraints in them
      - that we ignore the DF bit and fragment anyway at the constraint,
	between dissimilar media. (9000 byte ethernet vs 1500 byte ethernet)
 
  Assume that a TCP segment gets fragmented into two pieces. The first
fragment gets lost. The second fragment stays in the end-host's queue.  Given
how fast the network is, it wraps the fragment ID several times a second. 

  So, a second packet gets fragmented in the same way, the first part arrives
and matches the queued fragment. The datagram is assembled, and if we are
lucky, it fails the TCP checksum. 
  The second part arrives, finds no first part and gets queued, and waits
for the next ID wrapping.

  However, given the speed of the connection, in short time, odds are the
TCP checksum will match, and the segment will get accepted. 

  If the PAWS does proper PMTU discovery, then this can't happen.