Subject: [IPsec] Does ESP provide all functionality offered by AH?

From: Vilhelm Jutvik <[email-masked]>
Date: Sun, 13 Nov 2011 22:30:42 +0100

Dear all,

I am writing this as I have a question that I've failed to clarify by
other means.

It is commonly stated that the ESP protocol covers all of the
functionality afforded by AH (integrity and authentication) in
addition to confidentiality, with the exception that AH also protects
the parts of the IP header that are nonmutable in transit (the source
and destination fields most notably). This is then used as leverage in
the argument to justify the need of applying two SAs to a single
traffic pattern (i.e. connection): "ESP for authentication, integrity
and confidentiality. AH for protecting the source and IP address". It
should be noted that this only applies to transport mode as the whole
"tunneled" IP packet can be protected by ESP while in tunnel mode.

However, RFC 4301 stipulates that after AH / ESP processing the
addressing information of the packet must be successfully matched with
the traffic pattern of the associated SAD entry. In my eyes, this
would make it impossible for an attacker to alter (most importantly)
the source address of a packet as it would be discarded.

>From page 62, RFC 4301:

  ...
4.  Apply AH or ESP processing as specified, using the SAD entry
    selected in step 3a above.  Then match the packet against the
    inbound selectors identified by the SAD entry to verify that the
    received packet is appropriate for the SA via which it was
    received.
  ...

This, if true, would imply that all functionality offered by AH could
be provided by ESP. Is this true? The only "loopholes" I could come up
with is the case of extension headers in IPv6 which are not protected
by ESP, or issues arising in conjunction with multicast.

In any case, I would be very happy if someone could clarify this
question for me.

Sincerely,
Vilhelm Jutvik

---

From: Paul Wouters <[email-masked]>
Date: Mon, 14 Nov 2011 13:39:59 -0500 (EST)

On Sun, 13 Nov 2011, Vilhelm Jutvik wrote:

> be provided by ESP. Is this true?

I agree. The people who prefer transport mode usually mutter something about
a few saved bytes and how that is better for the MTU. But tunnel mode works
much better through NAT then transport mode, which needs ackward hacks that
are all vendor-specific. ESP-null is basically the equivalent of AH. It has
been about a decade now that Ferguson and Scheier said to get rid of AH and
transport mode altogether - as a result of which FreeS/WAN 2.05 was released
that removed support for it.

See further: http://www.schneier.com/paper-ipsec.pdf

Paul

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Nov 2011 00:55:23 +0200

What Paul said, mostly, but see below.

> See further: http://www.schneier.com/paper-ipsec.pdf

FreeS/WAN did eliminate transport mode, but that project is dead. The project that is active now (strongSwan) does have it.

RFC 3191 (L2TP over IPsec) says that transport mode MUST be supported for L2TP over IPsec. That, and the fact that this is the way Microsoft implemented their L2TP client is the reason why most gateway vendors have implemented transport mode. That and the fact that Cisco like to encrypt their GRE tunnels in transport mode.

---

From: Richard Graveman <[email-masked]>
Date: Mon, 14 Nov 2011 18:42:37 -0500

About transport mode, true enough, and see also 4891 for an IPv6 flavor.

But transport mode is not the reason for AH. These things could easily
have avoided transport mode.

In IPv4, the place to look for different functionality with AH is to
look away from unicast to multicast and perhaps anycast.

Rich Graveman

On Mon, Nov 14, 2011 at 5:55 PM, Yoav Nir <[email-masked]> wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 14 Nov 2011 19:09:23 -0500 (EST)

> FreeS/WAN did eliminate transport mode, but that project is dead. The project that is active now (strongSwan) does have it.

<openswan hat>

So does openswan, which is the continuation project from FreeS/WAN, and had its most recent software
release just a few weeks ago. But we wish people would not use either transport mode or AH.

> RFC 3191 (L2TP over IPsec) says that transport mode MUST be supported for L2TP over IPsec. That, and the fact that this is the way Microsoft implemented their L2TP client is the reason why most gat…

openswan also supports multiple L2TP clients behind the same NAT router
and multiple L2TP clients on the same overlapping pre-NAT IP address
using the KLIPS stack with SAref tracking using two new socket options and
ip_conntrack. The NETKEY builtin stack for Linux has no such capability.

See:

http://www.openswan.org/docs/ipsecsaref.png
https://gsoc.xelerance.com/projects/openswan/wiki/L2TPIPsec_configuration_using_openswan_and_xl2tpd
https://gsoc.xelerance.com/projects/openswan/wiki/Building_and_Installing_an_SAref_capable_KLIPS_version_for_DebianUbuntu

The same funcionality is used with Openswan to support multiple connections with customers with
unknown RFC1918 address space that overlaps, which is common in large cloud deployments.

Paul

---

From: Frederic Detienne <[email-masked]>
Date: Tue, 15 Nov 2011 09:51:41 +0800

Can you please explain your point about transport mode being bad ? We do not see any problem with it in real world deployments. It is quite the opposite actually.

I agree that AH is a hindrance, especially that it protects the non-mutable fields of the IP header and therefor prevents NAT and ToS re-marking. I.e. the main difference between AH and ESP_NULL is really this outer IP header protection which is detrimental in most practical networks.

---

From: Nico Williams <[email-masked]>
Date: Mon, 14 Nov 2011 20:03:59 -0600

> Can you please explain your point about transport mode being bad ? We do not see any problem with it in real world deployments. It is quite the opposite actually.

RFC4301, section 4.1 has some text on this, though, quite frankly, I
don't think there's any reason not to use transport mode in end-to-end
and end<->GW communications, and also, for the latter, no reason that
using an IP tunnel inside transport mode ESP shouldn't work just fine
(Dan McDonald used this approach for a VPN system at Sun Microsystems
[RIP]).

> I agree that AH is a hindrance, especially that it protects the non-mutable fields of the IP header and therefor prevents NAT and ToS re-marking. I.e. the main difference between AH and ESP_NULL is…

Yes, this is why we all dislike AH.

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Mon, 14 Nov 2011 21:05:51 -0500 (EST)

> Can you please explain your point about transport mode being bad ? We do not see any problem with it in real world deployments. It is quite the opposite actually.

I meant the kludge where transport mode (host-host) has to deal with NAT-T where the inner IP of the client
is used, making it kinda a tunnel mode ( internalip/32-host-host)

> I agree that AH is a hindrance, especially that it protects the non-mutable fields of the IP header and therefor prevents NAT and ToS re-marking. I.e. the main difference between AH and ESP_NULL is…

Yes. we've seen cellphone manufacturors that use Linux specifically patching Openswan KLIPS to allow ToS rewriting.

Paul

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Nov 2011 21:05:11 -0500

In most contexts, there is no real benefit to using two SAs (AH + 
ESP) as you describe.  I agree that, in almost every case, just using 
ESP will suffice. Using ESP in tunnel mode is certainly good enough, 
and less expensive than 2 SAs.

Steve

---

From: Frederic Detienne <[email-masked]>
Date: Tue, 15 Nov 2011 11:10:19 +0800

> is used, making it kinda a tunnel mode ( internalip/32-host-host)

I see what you mean but we have found tunnel mode to be impractical in similar protocol suites but different scenarios. 

Transport turns out to be really efficient and elegant in our cases. This is really an implementation issue and vendors have to tune their codes to their customer's use cases.

Additionally, there are many customers out there who really want to reclaim every possible byte. When the average clear text packet size is small, the overhead that tunnel imposes is significant.

I would say that transport mode is actually very useful actually but really depends on your usage.

> Yes. we've seen cellphone manufacturors that use Linux specifically patching Openswan KLIPS to allow ToS rewriting.

I think most people would agree that AH is really not a good idea. :-)

---

From: Frederic Detienne <[email-masked]>
Date: Tue, 15 Nov 2011 11:19:46 +0800

> (Dan McDonald used this approach for a VPN system at Sun Microsystems

Many vendors do that IP tunneling + ESP Transport and yes, this is a very fine use. This is why I questioned why "transport" was criticized.

I understand the issues section 4.1 raises but these are really implementation and network design issue again. Once tunnels are being used, the whole security aspect is actually factored into the overlay network design. The whole comment there apply to a pure IPsec Security Gateway. The section would really deserve to be either deflated altogether or augmented with a use case (c) where the Security Gateway has other network and security mechanisms to meet the security requirements.

> Yes, this is why we all dislike AH.

It will be hard to find someone to defend AH :-)  I still would be happy to hear if someone has a good argument.

	fred

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 14 Nov 2011 20:46:30 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Frederic Detienne
> Sent: Monday, November 14, 2011 8:52 PM
> To: Paul Wouters
> Cc: [email-masked]; Yoav Nir; Vilhelm Jutvik
> Subject: Re: [IPsec] Does ESP provide all functionality offered by AH?
> 
> 
> Can you please explain your point about transport mode being bad ? We
> do not see any problem with it in real world deployments. It is quite
> the opposite actually.
> 
> I agree that AH is a hindrance, especially that it protects the non-
> mutable fields of the IP header and therefor prevents NAT and ToS re-
> marking.

One minor correction: the DSCP field is mutable, and hence ToS remarking
is not a problem.

> I.e. the main difference between AH and ESP_NULL is really
> this outer IP header protection which is detrimental in most practical
> networks.
>

---

From: Frederic Detienne <[email-masked]>
Date: Tue, 15 Nov 2011 14:13:00 +0800

> One minor correction: the DSCP field is mutable, and hence ToS remarking

you are right. Thanks for the correction! :-)

	fred

---

From: Steven Bellovin <[email-masked]>
Date: Tue, 15 Nov 2011 01:56:33 -0500

> In any case, I would be very happy if someone could clarify this

The notion of discarding AH entirely has been discussed for many years.
I've long been in favor of it, though I can't find a copy of anything old I
had posted in my mail archives at the moment.  The counter-argument
-- and again, it's been presented many times over many years -- is that
AH protects some IP options.  That's useless in IPv4; the assertion is
that it's important in IPv6.

		--Steve Bellovin, https://www.cs.columbia.edu/~smb

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Nov 2011 04:38:59 -0500

At 1:56 AM -0500 11/15/11, Steven Bellovin wrote:
>  > De...

4301 deprecates AH, by making support for it a MAY, vs. a MUST for 
ESP, as part of a compliant IPsec implementation.

Steve

---

From: Vilhelm Jutvik <[email-masked]>
Date: Tue, 15 Nov 2011 23:16:03 +0100

Hello all!

I would like to thank everyone for the much enlightening discussion.

>From what I've gathered from the discussion and the documents that
have been referred is that ESP provides the same level of security in
the IPv6 unicast transport mode case, with one exception:

ESP doesn't protect the immutable parts of the IPv6 header nor those
of any extension header. Both source as well as IP destination field
can be verified by comparing them to the information found in the
associated SA's traffic selector, but extension headers can be added,
removed and altered at will. It's clear that this security hole can be
used in malicious ways, the only question is how much trouble an
attacker could cause. Is there anyone who could come up with an
example of a nasty attack?

As for the (apparently widely held) belief that transport mode is
redundant I would like to voice my opinion in defense of it: Tunnel
mode incurs an overhead due to the extra IP header. In the case of
IPv6 that overhead will be over 40 bytes and will hardware resources
as well as bandwidth. Ferguson and Schneier proposes a compression
scheme (section "Protocols") for reducing this overhead, but that
suggestion is tantamount to proposing a new mode and would take much
time and work to introduce in the current implementations.

Regards,
Vilhelm Jutvik

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Nov 2011 11:37:00 -0500 (EST)

> time and work to introduce in the current implementations.

L2TP/IPsec stacks I know (Microsoft, OSX, xl2tpd/pppd, iOS) set the
MTU/MRU on the ppp address to about 1200 anyway. So any argument that
it saves so many bytes is lost in actual deployments where people put a
huge safetely margin in to avoid mtu and fragmentation issues.

If your assigned IP goes to mtu 1200, you really have not gained a few
bytes by picking transport mode over tunnel mode.

Paul

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 16 Nov 2011 18:53:02 +0200

By the way, header compression in IPsec is standardized in RFC 5856/7/8. 
I don't know if anybody's implemented this stuff.

     Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Nov 2011 04:32:26 +0200

> example of a nasty attack?

Note, that you can protect the IPv6 extension headers by putting them
after the ESP header. Hop-by-Hop options are not issue, as the
intermediate hops do not have keys to verify the message
authentication code so they cannot really be protected anyways.
-- 
[email-masked]