On Tue, May 01, 2007 at 02:55:56AM -0700, UNIX admin wrote: > > If you're separating two sites, you need tunnels > > anyway. And if you're using > > tunnels, why do you need AH? What problem do you > > think AH will solve that > > ESP won't in this case? > > For what I understand, ESP just encrypts the packet payload, but it is AH > that guarantees that the packet headers or the payload aren't tampered with > in transit.
ESP has the capability for using authentication on its encapsulated payload. It makes AH *mostly* redundant. You should specify *either* ESP authentication or AH. > Unless I misunderstood, it is theoretically possible for a malicious third > party to modify the packets in transit with a completely different > encapsulated security payload, or even completely replace packets, since > there would be no AH to check the packet's integrity? You're correct. And these theoretical attacks are becoming practical. I had early conversations with someone who's writing a paper on such attacks. See this blog entry: http://blogs.sun.com/danmcd/entry/esp_without_authentication_considered_harmful for details. > On top of that, I read somewhere (could be docs.sun.com or wikipedia) that > use of ESP without AH is strongly discouraged. ESP without *AUTHENTICATION* is discouraged. You can pick ESP-auth or AH. If you're using tunnels, there's no difference and you should use ESP-auth. > Well, it's not like I have a choice. When one has two firewalls, one must > NAT to the external IP addresses of those. One *must* not. One *may* for any number of practical reason's, but you can choose to implement a completely internal private network and use proxies for inner nodes to access Internet resources. > Yes. The firewalls would be IPSec gateways. Absolutely. ObCapNit: "IPsec". :) > Like this: > > +------+ +---------+ > LAN A | |1st NAT | ADSL |2nd NAT > ---------+ FW A +---------+ "modem" +----------------+ > | |priv. | |ext. IP addess | > +------+IP +---------+ | > | > 3rd NAT |ext. IP address > +---+--+ > | | > | FW B | > | | > +--+---+ > | > | LAN B > | Ahh... cool. So really the only NAT you have to worry about is the DSL modem. This means FW A is the only node that can practically initiate IKE Phase I. Traffic flow originating from A or A's network can keep this from being a problem. Otherwise, just make sure LAN A and LAN B have different prefixes and you can set up a tunnel between FW A and FW B. The tsrc/tdst from FW A's point-of-view will be the 1st-NAT-private-IP and B's external address. The tsrc/tdst from FW B's point-of-view will be B's external address and the DSL Modem's external address. If the DSL modem is *completely* out of your control w.r.t. address renumbering, you will have to figure out a way to communicate the ADSL modem's external address to FW B periodically. A transport-mode-protected non-ping(1m)-ping of some sort would do the trick. We implement tunnels-as-network-interfaces in Solaris, so we have to keep the tsrc/tdst fixed on an instance. If your ISP psychotically changes external addresses on you every so often, you'll have to make FW B aware of it so it can reset tsrc/tdst on it's tunnel. NAT is such a steaming pile... and it's situations like yours that illustrate it. Your ISP could give you a dynamically-assigned external IP... it's not that hard. Oh well... I'm sure you complained to them about that already. A small ESP-protected UDP app running on FW B could receive packets from FW A, and if the peer address changes, it could re-plumb its tunnel with a new tdst. That's how you'd protect against psychotic ISPs. Dan
