Subject: encapsulation PMTU-friendly proposal

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

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

draft-richardson-ipsec-fragment-00.txt, at an ID mirror near you soon.

2. Heuristic

   Summary: If the system is keeping per flow state, preferentially
   error packets that suddenly reach a new high-water mark for each
   particular flow, because they arelikely to be probes, or classic
   PMTUD.

   For systems that have per-flow [Host to Host] (Ed.  per-microflow -
   5-tuple?) tracking, step 1 is included.  Otherwise, it is skipped.

2.1 Step 0 - selection

   Is the datagram is too big for the tunnel, and has the DF bit set? If
   not, encapsulate as normal.

2.2 Step 1 - tracking

   Keep track of the largest datagram size received.  When there is a
   new high water mark, do standard ICMP Need Fragment processing.  If
   this is the first time the datagram was too big, then goto step 4.
   If not, then drop datagram.

2.3 Step 2 - size check

   Is the amount that the packet is too big exactly due to the tunnel
   overhead? (In particular, this would never apply when the media on
   both sides is dissimilar).  If not, do standard ICMP processing, and
   drop the datagram.

2.4 Step 3 - error throttling

   Does error rate limiting permit an ICMP error message be sent at this
   time? (rate limited to about 1 packet per second) If so, then do
   standard ICMP Need Fragment processing, and drop the datagram.

2.5 Step 4 - send

   Fragment the datagram prior to encapsulation.  Divide the datagram
   into two equal pieces and encapsulate each one seperately.  No
   attempt to send an ICMP is made.

3. Example

   A 1500 packet to which a 20 byte IP and 28 byte ESP header is added,
   trying to fit on a 1500 byte network is fragmented anyway.

   A 9000 byte packet with a 20 byte IP and 28 byte ESP header trying to
   fit on a 1500 byte network is dropped.