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

Re: some issues about IPSec



Ben,

>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.

Traffic between SGs, or between a host and an SG is always in tunnel mode,
so case 1 does not apply.

The first text in architecture document to express the requirement for host
support of transport mode arises in Section 4.1, which notes "a transport
mode SA is a security association between two hosts."  Later in this
section it states that "Two hosts MAY establish a tunnel mode SA between
themselves." These two statement imply a requirement for a host to support
both transport and tunnel mode SAs, though I admit it could be more direct
in making this point.

In Section 4.5, Case 1 requires support for both modes by hosts for
host-to-host communication.  At the end of this section, there is an
attempt to make a concise statement about requirements: "The following
combinations of AH and ESP MUST be supported in the indicated contexts:
	- Cases 1, 3, 4   ... AH in transport mode, ESP in transport mode,
AH followed by ESP in transport mode ..."  During the reading party in
December we did discover some ambiguities between the concise description
and the case-by-case descriptions, and agreed to fix these problems, but
the text cited here was not one of the cited problem areas.

The cited text in 4.1 is in the draft from July, not new in the November
draft, as are the diagrams and Case 1 text.

In the ESP and AH documents, Section 3.1 describes the applicability of
transport mode  to hosts (vs. security gateways) and includes an explicit
note about the possible complications arising in BITS and BITW host
implementations due to possible fragmentation and reassembly problems.  The
need to provide such support for conformance, despite the potential
problems, is explicit here.

>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.

We have a lot of differences between the old RFCs and the current
documents, and there is no claim that the two are generally interoperable,
so I don't think that the old RFCs are very relevant to our current
discussion.  We've changed algorithm details, sequence number processing
and location, the order of ESP processing, etc.   Also, I'm not sure I
understand how blurring the distinction between transport and tunnel mode
makes IPsec more powerful and generally useful.  Can you cite some
instances where you feel this is true?

Finally, it occurs to me that perhaps we're focusing on the wrong issue
here.  My impression is that you have a BITS or BITW imlementation that
does not implement transport mode. The motivation for requiring host IPsec
implementations to support transport mode is, I think, largely one of
bandwidth efficiency, though there may be other reasons too.  We want all
host implementations to be able to comunicate with one another, and we want
to allow the host admin to be able to determine whether transport or tunnel
mode is preferred.  This leads to a requirement for any host
implementation, incluidng BITS and BITW, to implement transport mode.  If
the WG wants to expempt BITS and BITW iplementations from this requirement,
understanding that this will result in some host-to-host communications
being forced to tunnel mode where transport mode would have sufficed, then
ask he chairs to call for a vote and move on. On the other hand, if folks
feel that transport mode support is important for hosts, for efficiency
and/or other reasons, and want to maintain the status quo in the specs,
let's just move on now.

Steve




References: