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

Re: Alternative transform encapsulation scheme



Perry E. Metzger writes:
> 
> Karl Fox writes:
> > Now that we're heading toward individual do-everything transforms
> > rather than layered orthogonal functions, the concept of separate AH
> > and ESP protocols seems a bit awkward.
> 
> ESP is not the "encrypting protocol". It is the OPAQUE protocol.

My apologies; it's fairly easy to miss that point, since RFC 1827
mentions encryption and decryption 64 times while only mentioning
`opaque' twice in a fairly minor way in the syntax section.

> The idea always was that AH was there to provide for non-opaque
> encapsulated packets in which it was possible to determine what the
> contents were without understanding the SPI, and ESP was always
> intended to provide for any combination of
> (encryption/authentication/replay/etc) that did not need to be
> transparent.

So will these forthcoming authentication+opacity transforms
authenticate the outermost IP header the way AH does?  If they don't,
won't we have to use AH anyway and thereby authenticate the packet
twice?  If they do, then it looks like RFC 1827 will have to have some
significant changes to allow the transform to operate on the
encapsulating IP headers.  For example, section 4.1, `ESP in
Tunnel-mode' says to discard the outside cleartext headers, and
section 4.3, `Authentication', says

   Some transforms provide authentication as well as confidentiality and
   integrity.

It then goes on to talk exclusively about how to use AH in combination
with ESP.
-- 
Karl Fox, servant of God, employee of Morning Star Technologies
3518 Riverside Drive, Suite 101, Columbus, Ohio 43221    +1 614 451 1883


Follow-Ups: References: