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

Re: AH (without ESP) on a secure gateway



Bill Sommerfeld writes:
> > 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).
> 
> All things which aren't illegal aren't necessarily also good ideas.

Well...  It seems to me that it might be a good idea to allow IPSEC to
be used over multicast packets.  Then, your destination address (that of
the multicast group) would be constant, but there would be many source
addresses.  You would need to use an AH, but that should be sufficient
to verify the sender.  I don't see what security a check on source
address of authenticated packets adds.  Of course this all changes if
you are talking about the packet after it has been extracted from the
tunnel.

> Let's consider the case where you're attempting to add AH/ESP
> protection to an existing network which *currently uses IP-address
> based access controls*.  Naturally, you don't want to create security
> holes while doing this.
> 
> Let's assume you have a network of cooperating but mutually suspicious
> organizations, like the auto industry net which Bob Moskowitz is
> building.
> 
> For simplicity, let's assume orgs A, B, and C, connected in a "full
> mesh" of leased lines (A-B, A-C, and B-C).  Assume filtering routers
> on each leased line, so that C can't impersonate B when communicating
> with A.  We now want to migrate to IPSEC without causing a flag day.
> 
> Let's start by replacing the leased line between C and A with a tunnel
> over an untrusted network protected with AH or ESP.
> 
> What stops C from tunnelling a packet to A with a source address on
> B's network?  You need a policy check that the packet emerging from
> the tunnel is from a source address which is allowed to use that
> particular tunnel..

Unfortunately, I misinterpreted this the first time it came around.
I'll diagram several "packets" to illustrate :

original packet :
  IP_HEADER(gateC->gateA)
  AH(gateC->gateA)
  IP_HEADER(hostB->hostA)
  PACKET

de-encapsulated packet :
  IP_HEADER(hostB->hostA)
  PACKET

There are no checks that we want to do on the original packet.  I was
assuming that you wanted to check the source address on the original
packet, which is made immaterial by checking the AH.  The policy
decision you are talking about is on the source address of the
de-encapsulated packet, which I agree is necessary.

In most cases it wouldn't be necessary because you share the tunnel with
a *trusted* gateway.  But in this case, there is certainly need for
additional machinery to do the policy work.


ben


References: