Re: TO COMPRESS OR NOT TO CMPRS (please reply)

Bill Sommerfeld <sommerfeld@apollo.hp.com> Wed, 19 February 1997 19:22 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26072 for ipsec-outgoing; Wed, 19 Feb 1997 14:22:07 -0500 (EST)
Message-Id: <199702191926.AA116680384@relay.hp.com>
To: "C. Harald Koch" <chk@utcc.utoronto.ca>
Cc: ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-Reply-To: chk's message of Wed, 19 Feb 1997 14:10:33 -0500. <97Feb19.141142est.11653@elgreco.rnd.border.com>
Date: Wed, 19 Feb 1997 14:26:22 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

> Yes, but isn't that a Hard Problem (tm) unless you keep state (either
> "virtual interfaces" or individual packets) at the tunnel endpoints?

Well, given that you already need per-outbound-SA state (for the
session key and replay detection) this doesn't seem to be a major
burden.  A per-outbound-SA MTU would seem to be the Right Answer..

> How else do you convert an ICMP Fragmentation Required message for a
> tunneled (and auth'd and 'crypted) packet back into an ICMP
> Fragmentation Required for the original, untunnelled packet?

well, one "cheat" occurs to me: don't send a "FR" when you receive a
FR; instead, just record the MTU and let the packet fall on the floor;
if it was important, the sender will retransmit it; when this happens,
and (assuming it's too large), generate a new "fragmentation required"
ICMP message.  One drawback is that it takes two packets (instead of
one) for a new tunnel to learn the MTU..

					- Bill