Re: Path MTU Discovery

["Angelos D. Keromytis" <[e-mail]>]

In message <[e-mail]>, Dan McDonald writes:
>Let's consider one other property about router-to-* tunneling.  Since the
>router is the _originator_ of the outermost packet, it does not need to obey
>the inner packet's "Don't fragment" bit.  Remember, I'm originating the
>packet.

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

>WRONG FOR OUTBOUND PACKETS!!!  This is in clear violation of RFC 1825.  Lemme
>quote:
>
>>> 3.1 AUTHENTICATION HEADER
> 
><SNIP!>
>
>>>   Fragmentation occurs after the Authentication Header processing for
>>>   outbound packets and prior to Authentication Header processing for
>>>   inbound packets.  The receiver verifies the correctness of the
>
>There actually isn't text in the ESP section, but I'll bet small sums that
>either Ran A. or Steve K. will back me up on this one.
>
>If you meant inbound packets, my bad.

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.

>Any implementors out there not doing this?  I can only see this in the
>router-to-host tunnel.

JI and me have an implementation that does not use multiple ViFs. SOS
Corp. as well, last i checked. Don't know about others. So, the way
our implementation works is that a ViF is really used as a way
to force packets to go into the IPsec engine uppon receiving
(actually, just the IP-in-IP packets - the rest is handled by
ip_input()) Changing the ip_input() a bit would make those unnecessary
too. 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.

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 :-)

>It'll know.  Before that SYN or SYN/ACK gets sent, it can consult endpoint
>state (socket, pcb, whatever) and make an appropriate guess.

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