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

Re: Path MTU Discovery

> Well, wouldn't ignoring the DF bit defeat the original endpoint's
> PathMTU ?

DF applies to the IP datagram on which it is set.  DF is not inherited by any
encapsulating IP headers.

A packet arrives looking like:

	src	10.8.20.69
	dst	10.69.51.50
	proto = tcp
	bits = DF

The router then encapsulates:

	src	10.20.20.20
	dst	10.9.1.25
	proto = ip
	<Above IP datagram is in here>

This outer packet is now a datagram originating from the router.  It can
fragment as it sees fit.  Yes, it may violate the spirit of no intermediate
fragmentation, but it certainly is legal.  This is legal in IPv6 too, where
there is an implicit DF bit on all packets.

> My phrasing was "fragmentation checking", not fragmentation; what i
> mean is that one should check whether a packet, after the overhead
> imposed by IPsec, would be fragmented. If so, don't apply the
> transforms but drop it and send back an ICMP toobig. Sorry if i was
> not clear enough.

That explains things a little better, thanks.

<SNIP!>
> So one can establish multiple tunnels to different (or the same) hosts and
> use the same ViF. In this case, if you receive an ICMP toobig, you don't
> know who if "belongs" to until you parse the internal packet a bit and
> check the destination/SPI of the original packet. And then of course you
> can't (shouldn't) change the "MTU" of the ViF.

I question your choice of abstraction.  How do you configure these multiple
tunnels?  Or are they automatic tunnels ala. IPv6's ::<v4-address> syntax?
Since you probably have to configure the tunnels, you might as well provide a
halfway decent abstraction to take into account Path MTU ratcheting down.

> Q: does the NRL implementation create ViFs dynamically (as needed) ?
> I have a fairly old copy of it (1 year+) - available at
> idea.dsi.unimi.it:/pub/security/crypt/code/IPv6-domestic.tar.gz for
> those wondering how i got a copy of it :-)

Glad to see the code has slipped out elsewhere.  Funny thing is, last time I
touched the code was about 1 year+ ago.  It does not do automatic tunneling,
IIRC.

> Well, that's what i'm saying too. That we should make it a
> requirement. In fact, even what you've been saying about ViFs is
> non-standard; keeping track of ICMP toobigs and back-propagating that
> value is not standard behaviour and not specified anywhere.

OTOH it uses defined behavior and available underspecifications to make
implementations (IMHO) less complex.  Security holes come out of complexity,
just ask any sendmail user.

Dan
References: