4

Tunnel mode ESP (encapsulated in UDP so that it can traverse IPv4 NAT) is used as the basic building block of most of the modern VPNs that I've used and studied. In it, packets are encrypted and authenticated so that neither the headers nor the payload can be inspected or altered in transit.

The IPsec standards (RFC4301 etc.) also define several other modes of operation—which offer only a subset of end-to-end encryption and authentication:

  • ESP transport mode, in which headers and routing information are left intact but packet payloads are still encrypted
  • Authentication headers (AH) in which there is no encryption at all, but headers are authenticated so that they cannot be altered without detection.

What I'm wondering is whether there is any significant real-world usage of these less-than-fully encrypted and authenticated modes of IPsec, as of 2017.

Are there current, or historical, applications that actually benefit from the partial transparency of the traffic carried?

Any specific proprietary or open-source software that could be cited?

Community
  • 1
Dan Lenski
  • 313
  • 2
  • 7
  • 1
    AH mode could be useful if you want something on the link to be able to scan or block traffic for unauthorized behavior such as malware, while still keeping all the integrity benefits of IPsec (an attacker not being able to *tamper* with traffic). – André Borie Jan 16 '17 at 11:52
  • Interesting, I was wondering about that. Do you know of any software that actually uses AH in that way? – Dan Lenski Jan 16 '17 at 19:45

1 Answers1

3

ESP / tunnel mode is often used when you want to connect two different POPs' networks together: you're basically implementing a full network and routing layer on top of an encryption layer, and the networks have zero knowledge that they crossed a public network (like the internet). When you simply want to encrypt everything between two endpoints without a routing layer (usually when those two endpoints want to talk to each other, but not networks behind them) it's burdensome to create an additional routing layer.

Transport mode is used all the time between two endpoints when a full tunnel with separate routing and networking is not required. This is somewhat analogous to when you create an TLS connection between your computer and a website; you don't care that someone can see traffic between the two of you, but you do want it encrypted.

Transport mode is roughly the equivalent of a TLS connection to your bank's website, while tunnel mode is roughly the equivalent of using a VPN client to connect to your employer's internal network. There are exceptions, of course, but that's the general gist of it.

Example: say you have two machines with public IPs and you want them to make RPC calls to each other. You obviously don't want them to communicate over the internet with no encryption or authentication. You could do it via TLS (layer 7), but you may as well do it via IPsec transport (layer 4), as that removes the burden of encryption on any software you're using; this is especially important if that software has no understanding of TLS at all. With transport mode everything between the two machines is encrypted, from ping requests to telnet to any random traffic you open between the two.

Now you COULD do this over an ESP tunnel, but 1) this requires all your software to be aware of the new routing endpoints, IPs, and gateways, rather than the public IPs that already exist and 2) it's less efficient, as now you have the encrypted traffic plus additional tunnel-wrap overhead.

As for AH, I've rarely seen it implemented, as its primary purpose is to verify any payloads arrive unchanged from the source. The situations where you care about verification but not encryption are fairly small and often better served with full encryption anyway, but theoretical places where it would be used would include things like anti-virus/malware being injected by third parties in transit but where full encryption might be too costly for the hardware on hand. Again, these are very niche applications.

lidocaineus
  • 211
  • 1
  • 2
  • "Transport mode is used all the time between two endpoints when a full tunnel with separate routing and networking is not required." Makes sense, but I've never actually seen this done. SSL/TLS appears to be used for almost all applications these days, where end-to-end encryption is desired without changing or hiding the network-level routing. – Dan Lenski Jan 17 '17 at 20:35
  • I've just never seen a case where (a) traffic is being sent over an untrusted network and thus must be encrypted, however (b) it's desirable to expose the IP headers to the local routers and (c) there is no transport-level or application-level encryption (e.g. TLS or SSH). It seems *plausible* that something like this would exist when, say, running some ancient legacy applications that lack encryption through a corporate network, but I've never **seen one**. And that's what I'm curious about. – Dan Lenski Jan 17 '17 at 20:38
  • 1
    Simple example: GRE tunnels. We use them all the time because the IPsec ESP tunnel mechanism is not the most flexible and differs from vendor to vendor. We also use them all the time for debugging of web-based applications that require public IPs and have zero understanding of TLS, and are not on any back-network that is directly reachable from ours; you either tunnel networks or transport traffic to them encrypted. These are not legacy in the least bit. – lidocaineus Jan 17 '17 at 20:43
  • Thanks for the examples! I've gotten used to working in network environments where everything public-facing uses TLS, and everything "internal" is on a trusted network that can only be accessed via a tunnel. Clearly, the real world is more complicated. – Dan Lenski Jan 17 '17 at 23:09
  • 1
    Instead of using AH, you could also use ESP with ESP_NULL encryption (cf. https://tools.ietf.org/html/rfc2410). Also related: https://routingfreak.wordpress.com/tag/ah-vs-esp-null/ – mike Feb 13 '18 at 18:17