[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
security protocols versus MTU
When an encryption header is added to an MTU-length packet, the encryptor
will have to fragment its output intentionally, with all the problems
that entails. The obvious answer is to reduce the MTU advertised
upstream. But that's problematic for bump-in-the-cord encryptors or
for anything below of the IP layer. Furthermore, if a receiving
bump-in-the-cord decryptor is to handle such packets, it would need
a full IP reassembly mechanism. (In-kernel decryptors could, of course,
let the existing mechanisms reassemble the packet, and pass the result
*up* to the IPSP protocol module.) So we need some way to make sure
that fragmentation does not happen at this point.
The right answer is Path MTU. But only a small fraction of hosts have
deployed that to date. (The answer may be different for IPv6, of course.)
I suggest, therefore, that whenever we agree on a key management protocol,
it include an MTU that can be passed upwards. Thus, machines on the
end of, say, PPP links with a 256 byte MTU will advertise a small packet
size during any key management negotiations.
I should note that the context here is quite concrete. David Wagner
is implementing the IPv4 security protocols as a packet driver shim
for DOS and Windows. This operates at the link layer, below IP, and
while it can tell IP its effective MTU, we don't want to have to
reimplement IP fragment reassembly for input packets. So we need some
way to make sure that folks don't send us large packets. (By contrast,
it's relatively easy for this module to fragment a jumbogram and send
out complete IPSP packets whose payload is a single fragment. The
normal reassembly mechanisms can cope with that quite nicely.)
--Steve Bellovin