[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ESP revisions straw poll

Dan,

	We have a serious communication problem here. ESP has always had a
tunnel mode; the previous AH I-D and the architecture I-D lacked references
to a tunnel mode for AH, and this has been fixed in the latest versions.
I'm sure you are familiar with the existing RFCs and they explicitly do not
mandate authentication for ESP, i.e., not all transforms include such
functionality.  I don't recall if you were a participant in the early days
of the WG, but originally AH was envisioned as providing just
authentication and ESP just encryption.  We later expanded ESP to provide
authentcation, because it was more efficient than having a separate AH
layer.  I recall this clearly, because I argued that it was appropriate.

	ESP is a clean encapsulation protocol, with a header and trailer.
AH is a rather ungainly protocol, in that it reaches forward and
selectively protects portions of the IP header.  As I noted in another
message today, this complicates implementations striving for a high degree
of hardware integration.  In IPv6, what is protected can become even more
complex, given the increased complexity of the IP header structure.

	In most cases, not including the few parts of the IP header that
are covered by AH (at least in IPv4) would seem to have relatively few
security implications; in tunnel mode it seems largely superflous as most
of the outer header fields would be discarded upon receipt anyway.  In
transport mode the source IP address would be unique relative to the SPI,
so here too the need for such coverage seem minor.  The obvious v4
motivation for AH is use of security labels, but these are very, very
rarely used in the Internet; RFC 1108 is now historical!  In v6, the source
route extension is the best candiadte for coverage, so far.  Thus there
appear to be relatively few IP header fields (or options/extensions) that
ARE covered by AH and that have security implications.
Exactly what security problems do folks feel arise if none of the IP header
is integrity protected, in each of the contexts cited above?

	I do have a suggestion, though, to help reach closure on this
topic.  What if we say that an IPSEC implementation MAY elect to send
packets that are authenticated, but not encrypted?  That makes the existing
implementations compliant in this regard, yet holds open th opportunity for
future implementations to offer this feature if there is sufficinet demand.
An attempt to negotiate a set of algorithms that includes no encryption can
be rejected just like an attempt to negotiate use of an encryption
algorithm that is not supported.  One could even encode this as a null
encryption algorithm, as Bill Simpsom noted, if that would make processing
any more uniform.

Steve
Follow-Ups: References: