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

Re: AH (without ESP) on a secure gateway

Folks,

	A general problem arises with the use of AH at gateways.  AH is
nominally a "transport" mode security protocol, using the terminlogy
adopted for ESP in the IPSEC context.  In this mode, AH cannot be used
unambiguously by a pair of firewalls, because it conflicts with possible
use of AH by subscriber hosts served by these firewalls.  Since the choice
of SPIs is totrally within the purview of the receiving systems, the
firewalls have no way to control which SPIs are selected by hosts served by
them.  So, irrespective of the other points argued by contributors to this
debate, the fundamental problem here is the potential conflict between end
systems and intermediate system use of the same header and SPIs.

	One can address this problem by tunneling between the firewalls,
and using AH in the exterior IP header.  There is a very, very brief note
on such tunneling in the AH spec that Ran published a while ago.  It is
mostly a cautionary note aimed at other concerns, so it does not really
alert the reader to this aspect of the problem.  One also can achieve a
similar (though not identical)  capability by using ESP in tunnel mode, but
NOT electing to perform encryption.  Since ESP is being revised to be
general enough to NOT requre encryption, this would address the export or
import concerns cited earlier.

	Also, I agree with several of the observations about source address
filtering. This too is an area where we need agreement of what a compliant
implementation supports.  I tend to favor a receiving host or gateways
checking the source IP address against the (possibly singleton) set of
addresses that are  associated with the SA.  As we define different
granularities for selecting traffoc to map to a single SA selector, it
seems appropriate to be able to verify that the received traffic is
consistent with the definitions established during SA establishment.  If
this technlogy is widely used, it will not be appropriate to claim that any
source with which one establishes an IPSEC-secured connection will be
"trusted."  They will merely be well identified in most cases.

	This has been a useful discussion threat and it points out the need
to define required, and permitted, configurations for AH and ESP in hosts
and security gatewayas, as well as other processing requirements for
compliant implementations.  I don't think we included this detail in the
recent revisions of the RFCs that have been completed, so we will need to
go back and add this.  I look forward to a discussion of this topic of
appropriate combinations of AH and ESP atunneling in San Jose.

Steve