[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: some issues about IPSec
osgroup@laurent.osgroup.com writes:
> >
> > Perhaps at this time someone can also explain to me the benefit of
> > classing an SA as either tunnel or transport. I am still a strong
> > proponent of the old-style (RFC 1825) formatting which allows the IPsec
> > protocol to be more powerful and more generally useful.
> >
>
> I really don't see the benefit of transport mode at all from our
> perspective. None of our customers require it because we can communicate
> securely peer to peer (This is from a VPCOM (our product) perspective).
> Also, even going through a third party security gateway, peer to peer can
> be done.
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.
> > I guess I don't see why we should restrict the functionality of an
> > implementation based on the implementation method at all. If the
> > packets emerging from the _box_ don't give any indication of what method
> > was used to encapsulate them, why should we even care?
> >
>
> The questions here are what are the beneifits of transport mode that are
> not provided in tunnel mode ?
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?
ben
Follow-Ups:
References: