[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC AH -- document
Marc,
The text I added re BITS/BITW implementations was intentional, but
maybe too strongly worded. No, there was no mention of this on the list;
it was something that occurred to me while preparing the last revision and
so I added it in for review this time around. Both the AH and ESP specs
have been silent about these sorts of implementations in the past and
because such implementations are being developed, I thought it was
important to highlight what I thought might be a problem. Note that this
comment is not a prohibition, just a recommendation, re this mode of use.
You are right that the PMTU/DF note did not make any mention of this,
because it did not occur to me in that context, when the work was done
several weeks ago.
The reason for the additional text is exactly what it says, i.e.,
because of the need to deal with fragments transmitted by the host.
Perhaps the wording was too strong, and should merely be a warning that
these implementations must be aware of the requirement to apply AH (and
ESP) only to complete datagrams. I note that fragments created by the
host might exist via two different interfaces in a multi-homed host, so a
BITW device or very low level BITS code might not be able to do reassembly,
IPsec, and then refragmnent, in that instance. Such implementations would
have a similar problems for incoming fragements that arrive on separate
interfaces and would be reassembled in the native IP implementation. So,
those worst case scenarios motivated my recommendation. Still, I'm happy
to change the wording to merely refelct the requirement that special care
must be taken in these implementations to ensure the ability to properly
perform AH and ESP, on both outbound and inbound traffic. Would that be OK?
Steve
Follow-Ups:
References: