4

I am refreshing my understanding of IPSEC.

IPSec is an IETF defined set of security services that use open standards to provide data confidentiality, integrity, and authentication between peers.

IPsec involves two security services:

  • Authentication Header (AH): This authenticates the sender and it discovers any changes in data during transmission; incompatible with NAT.
  • Encapsulating Security Payload (ESP): This not only performs
    authentication for the sender but also encrypts the data being sent
    (confidentiality).

Why would anyone ever use AH? ESP does it plus more. In other words, why is AH specified? Also, has anyone ever deployed or used AH-only IPSEC?

|improve this question|||||
  • Authentication with ESP is only guaranteed over each packet in Tunnel mode. Not transport. So it really depends on the use case which is appropriate. – RoraΖ May 25 '15 at 3:33
  • That is wrong. ESP can (upon request/configuration) provide authentication and/or encryption in both Tunnel and Transport mode. – Mouse Aug 29 '19 at 15:37
4

AH can be easily inspected by firewalls. ESP with NULL is similar but (AFAIK) the firewall doesn't know that it's the NULL cipher and has no easy way to tell after a connection has been established.

So if you want authentication only then that's a plus for AH.

|improve this answer|||||
  • I understand that AH is incompatible with NAT. Based on the feedback so far, it appears that nobody uses AH. Why would they when basic 56 bit DES on ESP probably runs just as easily. – Ronnie Royston May 25 '15 at 21:57
2

In my experience, and in EXTREMELY rare cases, I have found a provider or some hop between endpoints that blocks ESP (IP protocol 50). A tunnel successfully establishes, but no traffic gets through. When I see this happen and rule out standard probable causes, I look to AH.

I've used AH to 'prove' that to providers to get them to at least check their end. If it cannot be corrected, it at least provides a transport mechanism in those rare cases where ESP hasn't worked.

|improve this answer|||||
0

One more reason you might want to use AH and not ESP: Encryption is prohibited for your application.

For example, in Amateur Radio, data links over the licensed spectrum are explicitly prohibited from any encryption. We can use AH, though, as an anti-spoof or to do outright VPN tunneling without breaking the law.

Other countries may have similar issues, and sometimes companies' network policies will prohibit most people from encryption as that blocks their ability to inspect the data.

So in short, there do exists cases where encryption is not desirable or allowed, and AH exists to meet those cases.

|improve this answer|||||
0

Encryption over the wire may not be a requirement or the hardware is incapable of encryption at high rate. On platforms without encryption offload, ESP might tax heavily on control plane.

|improve this answer|||||
0

IPsec was designed in the time when Export Restrictions applied to cryptographic products were much stricter than now.

There was a requirement to ensure that there is no way to hack a deployed application, forcing it to encrypt traffic (within the standard). To satisfy this requirement, the design included:

  • ESP that can handle encryption and authentication, either together or separately/individually (authentication only, or encryption only), according to user's needs, and controlled by configuration; and
  • AH that could only do authentication. AH was intended only for sales to crypto-restricted customers.

ESP was designed to accommodate cases where encryption is not desirable. AH was for the cases where one had to guarantee that no matter what the end-user does, enabling/adding encryption to this product would not be possible (again, within the given standard, of course).

|improve this answer|||||
-1

AH is used for non-repudiation that ESP cannot provide.

Also, ESP doesn't provide protection from traffic analysis

|improve this answer|||||
  • Can you expand this answer? How does AH provide non-repudiation? How does ESP not provide protection from analysis? – schroeder♦ Jul 23 '19 at 7:30
  • The PUBLIC IP header for ESP is not hashed<encrypted> whereas in AH it is. – Shweta Jul 24 '19 at 13:58
  • This is also the reason that AH is incompatible with NAT – Shweta Jul 24 '19 at 13:59
  • Please edit your answer with these details – schroeder♦ Jul 24 '19 at 15:17
  • ESP can authenticate the PUBLIC IP in Tunnel mode. That still has nothing to do with non-repudiation, which means - the sender cannot deny that he sent the message/traffic. In case of IPsec there's no way to prove that, e.g., the recipient didn't share the session (SA) keys, or didn't forge the traffic himself (e.g., by colluding with the ISP or logging authority). Non-repudiation means there's no way others could collude to forge your traffic. – Mouse Aug 29 '19 at 15:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.