[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC fragmentation scheme
>These RFCs do not mention what to do if a packet needs
>to be fragmented because of the AH & ESP security overhead.
Well, if the packet has to be fragmented because of the added AH/ESP
overhead, then you simply fragment it using the normal IP
fragmentation scheme. However, if the packet being protected in
"tunnel mode" has the DF (don't fragment) bit set, you bounce it back
to the sender in an ICMP message along with an estimate of how large a
packet could be acommodated without the AH/ESP overhead causing
fragmentation. In this way a sender that implements MTU Discovery can
reduce its packet size to avoid fragmentation in the first place.
A host that implements AH/ESP directly ("transport mode") can somewhat
more easily avoid local fragmentation due to the AH/ESP header. For
example, many TCP implementations already ask the IP layer at
connection setup time for the MTU of the interface that will be used
to reach the specified destination. By subtracting the IP and TCP
header sizes they arrive at the maximum segment size that can be sent
without local fragmentation. When you implement AH/ESP on such a
host, it's a simple matter to add code that further reduces the MTU
reported from the IP layer by the worst-case AH/ESP header
overhead. I've already done this in my KA9Q code and it works well.
Phil
References: