[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: some issues about IPSec
Stephen Kent writes:
> Xuechen,
>
> >I like to have your opinions on some issues. Basically we already got a
> >bump-in-the-stack implementation for Windows 95 and Windows NT working.
> >This implementation supports multiple security channels between two hosts
> >or host and security gateway or two security gateways. User can configure
> >which application protocol to protect (FTP, TELNET, HTTP...) and what kind
> >of algorithm to use. Now it only works with manual key management and only
> >in tunnel mode.
>
> Manual keying is not a problem, but the new I-Ds do require you to support
> both tunnel and transport modes, unless your BITS implementation is
> destined for use only on security gateways.
Stephen,
Could you point out where this is stated? The requirements in section
4.5 seem to imply that transport mode is required of all hosts who might
communicate under 'Case 1'. While this does not cover the bulk of the
traffic between security gateways, it will certainly occur some times.
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.
At one time I proposed
> restricting BITS implementatiions to tunnel mode only, but at least one
> vendor was implementing transport mode and argued against that, so ...
> Also, there is a need to support administrative configuration that may be
> more sophisticated than the preceeding paragraph would suggest.
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?
ben
Follow-Ups:
References: