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

Re: ESP revisions straw poll



  Steve,

  As Strother Martin said in Cool Hand Luke, "What we haf he-uh, is a
faili-yure to com-yune-a-cate". (It's hard to effect an accent in email, 
but I'm sure you're familiar with that famous quote and the southified
manner in which is was made).

  I'm not a IPsec old timer but I am familiar with the existing RFCs; I
know ESP has always had a tunnel mode and I know that the previous AH doc
did not. I also remember the discussions to add authentication to ESP.
  What I was suggesting was to have uniformity in authentication. That is,
to have ESP include the intransient fields of the outer IP header in its
integrity check in the same fashion as AH does. I was not suggesting that AH
be scrapped nor was I suggesting adding tunnelling capability to a protocol
that already has it.
  I know this is a new suggestion and perhaps it will be shot down but
since the changes being discussed on this list will change the bits-on-the-wire
I felt it was not inappropriate to suggest it. The ungainlyness of such a
protocol is in the eye of the beholder, I guess.
  To me, ESP is a security protocol, not a generic tunnelling protocol. It 
could be made into a generic tunnelling protocol by making encryption and 
authentication optional I don't see the point. If you need a "clean 
encapsulating protocol" then why not use GRE tunnels (RFC1701)? 
  My proposal is that AH does authentication, ESP does encryption with 
authentication. And the scope of the integrity check is identical for each.

  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.



References: