[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ICMP must fragment and IPsec
> To: ipsec@tis.com, tcp-impl@cthulhu.engr.sgi.com
> CC: vjs (Vernon Schryver)
> One way might be to have an ICMP or TCP option that requests the
> other end to provide a response, giving the size of the largest
> fragment received. This would be enclosed in the SA that the TCP data
> is flowing in. This is in some sense a variation of the TCP MSS option.
What is this "other end"?
If talking to the other end of a TCP connection were enough, then the
MSS negotiation would be enough and the Path MTU Discovery mechanism
would not be needed. In fact, the MSS negotiation is often not enough
because a vast number of boxes between the ends might legitimately tell
you to reduce your MTU. The boxes in the path vary, as routes change.
Not only might every router that might sometimes be in the path need to
send a reduce-MTU indication of some kind, but so might bridges (e.g
FDDI-Ethernet bridges that necessarily IP fragment, honor the DF bit,
and send the ICMP message.)
The trouble with authenticating path MTU information (regardless of its
form) is key distribution. How would you get the right key to all of
the boxes that might be in the path so that you could trust them?
Given the implications for the security of the keys in sending them to
every router in the net that might touch youyr packets, who would want
to? You can't just determine that a box is who it says it is. After
you authenticate box99.bad.guy.com as the sender of the ICMP error
message telling you to use an MTU of 68, what do you do?
The only response to worries about path MTU messages, as well as source
quences, port, net, and host Unreachables, and many other such
indications is to be to cross your fingers and ignore any that would
have serious consequences, such as an message telling you to use an MTU
of 68.
> ...
> I can't think of many cases in the current deployed internet where
> the MTU might change during a connection. Usually, the smallest MTU is
> on the edges at that 28.8 (or that 2400 baud modem) link, and that
> isn't likely to change suddendly. I can see mobileip possibly changing
> this. If/when mobileip is deployed en-mass, it will definitely include
> IPsec.
There is a vast amount of topology on the edges, what with ATM (9180),
FDDI (4352), Ethernet (1500 or 1492), PPP (256 to more than 1500), and
Frame Relay.
Besides, if you stay away from the edges and in the center where routes
don't flap among links with different MTU's, you may as well fix your
MTU=1500 and forget Path MTU discover.
> Getting Path MTU information back to the sending TCP is not an
> unsurmountable challenge to VPN uses of IPsec, but it isn't easy.
On the contrary, I think the key distribution problem is insurmountable
and makes authenticated path MTU information impossible. For example,
look at any real life network and see how many FDDI-EThernet bridges
there are that have not been given a IP address (manually or by bootp
or DHCP) and so cannot send the ICMP message when the drop an packet
with the DF bit set. If people cannot manage to set their IP addresses
(thus wrecking not only MTU discovery but SNMP), how can you expect
them to do something useful about keys?
Vernon Schryver, vjs@sgi.com
Follow-Ups: