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

Re: AH (without ESP) on a secure gateway

Bill Sommerfeld writes:
> >      My question is whether AH on a secure gateway even makes sense at all 
> >      if ESP is not being performed.
> >      
> >      Consider hostA sending a packet to hostB.  If gatewayA places an AH on 
> >      the packet, it would appear as if it was authenticated by hostA, not a 
> >      good idea in my mind.
> 

It seems to me that gatewayA should never try to place an AH, nor do an
ESP encapsulation on the packet using transport mode (assuming that
gatewayA did not originate the packet).  A gateway that put IPSEC
headers on packets in transport mode would not only cause confusing
problems like this, but would have severe problems dealing with
fragmented packets.

> The "policy engines" on each end need to be sophisticated enough to
> deal with things like this.  In particular, if ip-address based access
> controls are in use, then the policy engine should probably do
> consistency checks between the SPI and the source address..

Why?  I believe the RFC states that the Security Association(SA) is
chosen using only the destination address and the SPI.  It doesn't seem
to be illegal for several hosts to send us packets using the same
Security Association (SPI).

It makes sense to only check the headers on packets that are destined
for the local machine.  Otherwise, we would be intercepting (and
probably modifying) packets not destined to that machine, and violating
many of the ideas that make IP work.  Thus, I don't see any reason that
a gateway could use transport mode to tack on an AH to a packet from
hostA to hostB.

To address the original question, using the following scenario:

>       secure                 (untrusted)         secure
>       hostA  gatewayA---------------------------gatewayB  hostB
>        |      |                                     |      |
>       ----------                                   -----------
>      (trusted subnet)                             (trusted subnet)
     
the packets should look like (on the untrusted segment)

hostA -> hostB :
  IP_HEADER(gateA->gateB)
  AH(gateA->gateB)
  IP_HEADER(hostA->gateB)
  AH(hostA->gateB)
  IP_HEADER(hostA->hostB)
  PACKET

hostA -> gateB :
  IP_HEADER(gateA->gateB)
  AH(gateA->gateB)
  IP_HEADER(hostA->gateB) 
  AH(hostA->gateB)
  PACKET
or
  IP_HEADER(gateA->gateB)
  AH(gateA->gateB)
  IP_HEADER(hostA->gateB) 
  AH(hostA->gateB)
  IP_HEADER(hostA->gateB) 
  PACKET

gateA -> gateB :
  IP_HEADER(gateA->gateB)
  AH(gateA->gateB)
  PACKET
or
  IP_HEADER(gateA->gateB)
  AH(gateA->gateB)
  IP_HEADER(gateA->gateB)
  PACKET

gateA -> hostB
  IP_HEADER(gateA->gateB)
  AH(gateA->gateB)
  IP_HEADER(gateA->hostB)
  PACKET

to avoid any ambiguity.  Note that this never allows AH, AH and assumes
that no machine will attempt to de-encapsulate a packet whose
destination address is not assigned to that machine.  As a result, none
of the machines ever has to make any complicated policy decisions (on
whether to look at the AH, or how to handle the assignment of SPI's).  I
feel that this is the best way to handle all such multiple
encapsulations.


ben
Follow-Ups: References: