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

Re: some issues about IPSec



Ben,

>It is really not my intention to deny transport mode altogether just
>because _we_ don't see any need for it.  I am intending to question the
>validity of classifying an SA as tunnel mode or transport mode.  The
>current RFC's truly only define transport mode.  Tunnel mode can be
>inferred by the existence of RFC 1853 (IP-in-IP), or any similar raw
>tunneling protocol.  They make no attempt to restrict the use the SA
>concept based on some preconceived notion that one header implies the
>existence of some other header further down the chain.  That approach is
>both more simple to describe and understand, and provides far more
>functionality.  Interoperability issues simply do not exist assuming
>vendors are capable of correctly understanding the drafts.  Their
>concise language effectively guarantees this.  It should be evident that
>the classification of SA's (both as tunnel/transport, and by the
>selector concept) in the current drafts is a bad idea simply because of
>the incredible amount of language required to describe them.  We should
>be looking for something much more simple.

The notion of tunnel and transport modes has been a part of IPSec for quite
some time.  Section 3.1 of both AH and ESP define the modes, and I think
they do so fairly clearly.  We go into a fair amount of detail to try to
avoid ambiguity, not because the notions are intrinsically complex.  At
this late date, I don't think that changing the specs to remove these mode
distinctions is a viable option.

>No.  The question is more along the lines of the following.  Supposing
>my box produces packets correctly in _some_ mode (either tunnel or
>transport) and puts them out on the line in a manner indistinguishable
>from your box.  Do we care that my implementation lies in the core IP
>code while yours is a BITS?  Should yours be subjected to different
>criteria than mine, simply because we chose different implementation
>methods?  Why can't we describe the protocol as being generated by a
>black box, and leave the implementation details to the various
>implementors?

The specs are not trying to overly constrain implementations; the intent is
to ensure interoperability in more than just the simplest cases, and to
provide users with a reasonable degree of functionality.  Transport and
tunnel modes have different representations on the wire, due to the extra
encapsulation in the latter mode, and differenmt requirements with respect
to fragmentation.  The later differences were adopted because of the
problems that can arise in dealing with fragments of encrypted datagrams,
support for fine granularity SAs (e.g., based on port fields) etc.


Steve




References: