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

Re: AH (without ESP) on a secure gateway

C. Harald Koch writes:
> In message <199611262230.RAA27739@carp.morningstar.com>, Ben Rogers writes:
> > 
> > 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.
> 
> and 
> 
> > 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.
> 
> I disagree. The counter example: firewalls (or John Gilmore's "cryptowalls").
> 
> I see an incredible advantage for firewalls to add IPsec information to
> packets, acting as proxies for the machines they're protecting. Keeps all
> your Security Association information in one place, where it can be easily
> configured and monitored.
> 
> People aren't going to start ripping out their firewalls just because they
> have IPsec support on their hosts; firewalls allow much more security
> control than IPsec does.  (Analogy: you don't unlock the front door just
> because everyone can lock their own filing cabinets).

Hmmm.... This statement doesn't seem to disagree with my original
statement.  I said that the gateway should never do encapsulation in
*transport* mode.  Tunnel mode is still acceptable, and would be the
perfect thing to use in this case -- the "cryptowall" would ben one of
the tunnel endpoints.

The problem in using transport mode on a gateway lies mainly in the
fragmentation of packets.  Imagine that the "cryptowall" receives a 1500
byte fragment, and adds a header to it.  The authenticated packet is
then again too big to send out on ether, and so it must be fragmented
again.  The problem is that we changed the size of the total packet by
adding the AH to it.  You *cannot* calculate fragment offsets in an
unambiguous manner without keeping the enough state to calculate new
offsets for all the other fragments.

> You also write:
> 
> > 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).
> 
> A security association is *indexed* by destination address and SPI. However,
> It can include information about the source, including strong authentication
> checks, and instructions to reject packets from an invalid IP address. It's
> not illegal for several hosts to using the same SPI, but it's also not
> secure (it would allow all hosts with the same keying information to spoof
> each other, for example).
> 
> I think it's much more likely that a host would enforce the use of different
> SPIs (and different keys) for each different source host.

This is definitely the more secure method, and should be used when you
are dealing with untrustworthy peers.  However, if you trust your peers,
there is no reason to disallow a priori several "source" hosts sending
you packets on the same security association.  If all you want to do is
to authenticate that someone sending to the multicast address is allowed
to, and not to authenticate their individual identity, then this should
be sufficient, and should save space (in not having to have seperate
security associations for a large number of "identical" peers).

You can still check on source address if you want (for example, in a
"cryptowall"), but it seems that this should be a policy decision, and
should be separated from plain vanilla IP security.


ben
References: