--Apple-Mail-58-101105844
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed


On May 28, 2004, at 2:34 PM, Daniel Carosone wrote:

> The second issue is whether PMTUD can discover even smaller path
> segments between B==C.  This requires the DF bit set (or copied) to
> the outer header, so that B or C can get ICMP notifications for their
> ESP packets, which is the sysctl we've been talking about.  It ALSO
> requires that B and C do something useful with those packets to then
> expose the yet narrower tunnel to A and D.
>
> It's this last bit I'm not convinced we do right, though of course the
> problem may also be earlier. There's at least the reasonable concern
> that packets outside the cryptosystem can now influence the protected
> tunnel.

Yes, I agree that is a problem.  However, just ignoring an endpoint 
that said "don't fragment" is also just plain wrong.

Again, I ask "how does IPv6 handle this"?  In IPv6, a router doesn't 
even have the option of fragmenting packets.

As for "packets outside the cryptosystem can now influence the 
protected tunnel" .. as long as you are relying on non-private 
infrastructure (merely virtually private) then this is something that 
can't really be avoided.  I mean, an intermediary router that drops 
every 9th packet is still exercising some influence over the protected 
tunnel.

I guess that has to happen to handle your A-B=C-D case properly is for 
{B,C} to manufacture a NEEDS FRAG packet for {A,D} upon reception of 
one corresponding to the tunnel.

Sigh, if our IPsec tunnel implementation actually created netif 
instances then it would be a simple matter of cranking down the MTU of 
that interface when a NEEDS FRAG message was received on the outer 
shell of the tunnel it corresponds to.  Then everything else would just 
figure it out.

However, we could also certainly change our IPsec tunnel data structure 
to hold the same type of MTU information, and consult it, as well.

         -- Jason R. Thorpe <thorpej@wasabisystems.com>


--Apple-Mail-58-101105844
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFAt7nYOpVKkaBm8XkRAnthAKCcwdAsrzOtK1ckxz2uTPR5/Hd+jQCgveg7
HPhr4vQgzTY4uC7ucfpCzlg=
=5nEH
-----END PGP SIGNATURE-----

--Apple-Mail-58-101105844--