[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ESP/AH draft comments
--- On Sat, 16 Aug 1997 16:51:41 -0500 Stephen Kent <kent@bbn.com> wrote:
On the topic of SAs, I have also long used the terminology that:
"An IPsec Security Association is uniquely identified by the Destination
IP Address, SPI, and Security Protocol triple."
The underlying ambiguity about whether the Security Protocol was part of
the identification criteria was my editorial error in the original RFCs,
which I had attempted to clarify in last Fall's posted I-Ds. Mea Culpa.
> >3. I think we should get rid of the references to the special cases
> >for debugging. The couple of instances we have is either too many or
> >two few -- why do we *just* have these?
>
> This is partly a holdover from the previous drafts, but also a
> clarification that was discussed on the list, where there was agreement
> that an SPI of 0 MUST not be transmitted. Since we earlier say that 1-255
> are reserved, it begs the question as to the status of 0, so I think we
> need to say something, either here or in the arch doc.
Proposed replacement text about the case of SPI 0:
" The SPI value of zero (0) is permanently reserved for
implementation-specific use and MUST NOT be sent on the wire.
For example, a key management API implementation MAY use the
zero SPI value to mean "No Security Association Exists" in the
context of the IPsec implementation requesting that its
key management entity establish a new IPsec Security Association."
I think that more clearly indicates both the interoperability issue
(never send SPI of zero) and gives a reasonable illustration of
one possible implementation-specific use (without constraining
any particular implementation).
I know that we found it incredibly useful as implementers to have
the zero value be reserved to mean "No SA exists", not only in
Key Management API space but also more generally in other bits
of implementation-specific code. I've heard from several other
implementers that they have also found this useful. Removing
that restriction now will make existing conforming implementations
suddenly non-conforming, which seems highly undesirable.
> >5. My working definition of transport mode has been: the crypto peers
> >are both the same as the endpoints for the "original" IP datagram.
> >Tunnel mode is when they both aren't the same.
> >
> >I've heard sentiment that a so-called security gateway should allow
> >transport mode connections to/from itself to an IPSEC host/another
> >gw. I'm personally somewhat neutral, but we should resolve this.
>
> One might argue that two hosts could establish a tunnel mode ESP SA between
> them to provide better traffic flow security than would be offered by a
> transport mdode ESP SA, so I am reluctant to define the difference between
> tunnel and transport mode as you suggest. A transport mode SA to a GW
> would be OK if the gateway was the destination, e.g., a secured Telnet
> session for managing the gateway. But otherwise a transport mode SA should
> not be made to a gateway.
I fully concur with Steve here.
In particular, there are a number of situations in which a pair of hosts
that both implement IPsec might (by local policy) wish to create an ESP tunnel
between them rather than using ESP transport-mode. Current host implementations
generally support this capability, so it would seem counterproductive to
eliminate that feature. Also, I agree that a transport-mode sessions ought
to be used as he describes.
Ran
rja@inet.org
References: