I have an architectural and implementation concern which stems from the
excerpted (below) section 3.1 text from the latest AH document. I'm
concerned that additional text has crept into this latest AH document,
which is either simply incorrect or is going to limit flexibility of
implementations.
On this:
3.1 Authentication Header Location
Like ESP, AH may be employed in two ways: transport mode or tunnel
mode. The former mode is applicable only to host implementations and
provides protection for upper layer protocols, in addition to
selected IP header fields. (Use of transport mode in "bump-in-the-
stack" or "bump-in-the-wire" implementations, as defined in the
Security Architecture document, is not recommended as these
implementations may receive outbound IP fragments from the attached
host and thus be unable to process these packets according to this
specification.) ...
I completely disagree with the parenthetical comment which has been
added to this newest version of AH unless we're now getting into the
business of restricting vendors/implementers on how they can implement
their products. And for what benefit? Also, I don't recall seeing any
discussion (either on the list or at Memphis) that led to this
additional note. Perhaps someone could supply the background if
there's something I've overlooked in the following? I didn't see any
reason in the architectural PMTU/DF note last month dated 4/22, in fact
in that note the bump-in-the-stack (BITS) approach was marked as being
both Transport and Tunnel mode capable, along with the fragmentation
issues.
Transport mode *can* be properly implemented by a BITS IPSEC
implementation ("underneath" the native IP stack), allowing end-hosts
to avoid the overheads of Tunnel mode and to be configurable
identically to native/integrated IPSEC implementations. As a vendor I
see it can be attractive to customers to bring their older systems to
full IPSEC protocol compliance without having to upgrade their OS or
native protocol stack or buy external boxes. The text above about
"outbound IP fragments" doesn't give an adequate reason for supporting
the recommendation that BITS IPSEC implementations can't/shouldn't do
Transport mode. In the extreme case (not that I recommend any
implementers do this) one could have the BITS code "catch" all
fragments before passing outbound to the driver/wire, reassemble/move
them into contiguous memory, perform AH *exactly* as specified in this
spec, and then refragment and pass on the packet fragments down to the
driver/wire. There would be no "on the wire" difference from a
native/integrated IPSEC implementation. So, other than implementation
work to minimize performance impacts (which can be very low anyway if
the native IP stack implements PMTU discovery itself), there's no
protocol or interoperability problem with a BITS approach implementing
Transport mode "according to this specification".
Let the vendors and customers make the upgrade/cost/feature/performance
trade-offs, lets not specify beyond what "goes on the wire". Or, since
we sometimes have to describe how "to process these packets" to ensure
that secure procedures are followed *within* a node lets do so in a
manner which doesn't make certain implementation approaches, such as
BITS, seem non-compliant. My text change recommendations would be to
delete the above parenthetical text, since I hope its now clear its not
"the full story". The other BITS-related text change I see (if we
don't just want a "BITS implementations must perform the same on the
wire as a native IPSEC stack" catch all) would be to follow the first
sentence in the 3.2.4 Fragmentation section with something like: "For
Transport mode BITS implementations, outbound fragments from the native
stack of a single packet must be effectively reassembled back into a
single IP packet before AH processing." Don't specify any more than
that, I don't think any more needs to be specified for interoperability.
-- Marc --