Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt

From: RJ Atkinson <[email-masked]>
Date: Wed, 2 Apr 2014 11:53:13 -0400

All,

Working primarily from the HTML diff, towards the end of Section 3, 
the draft -03 text says in part:

     "The IPsec community generally prefers ESP with NULL encryption
      over AH, but AH is required in some protocols; further, AH is
      more appropriate when there are security-sensitive options in
      the IP header"

The 1st part of this assumes that IP-layer options aren't in the
packet (which most commonly is true) and that the deployment threat
model does not consider option insertion attacks to be a major threat
(a widely held belief for the commercial portions of the Internet).

The 2nd part of this is vague, unclear, and a bit misleading.  It
could be read as indicating that ESP with NULL encryption is able to
protect IP header options, but AH is preferred for that case.

In fact, ESP is *NEVER CAPABLE* of (A) protecting IPv4 options or 
(B) of protecting IPv6 options that are seen & processed by 
intermediate systems (e.g. routers, security gateways, other 
middleboxes).  ESP also NEVER can prevent option insertion attacks.

Lastly, it is ALWAYS possible for an intermediate system (e.g. router
with ACLs) to parse past the AH to see transport-layer headers, 
but even the best of the heuristics for parsing past an ESP header 
are not 100% reliable.

[IMPORTANT NOTE: A previous employer of mine shipped IPv4/IPv6 routers
with forwarding silicon that could parse AH and any other IPv4/IPv6
options - at wire-speed for 10 Gbps interfaces - 10 years ago.  I am
aware of 2 other very widely deployed implementations with the same
ability to parse past AH to read TCP/UDP ports and apply ACLs at
wire-speed.  So this is a widely deployed capability, rather than
theory. :-]

We owe it to readers to be crisp, clear, complete, and accurate 
with the text in this draft.

Candidate new text:

     "When no IPv4 options or IPv6 optional headers are present, and 
     in environments without concerns about attacks based on option
     insertion (e.g. inserting a source routing header to facilitate
     pervasive eavesdropping), the IPsec community generally prefers
     ESP with NULL encryption over AH.  However, some protocols
     require AH.  Also, AH always protects all IPv4 options and IPv6
     optional headers, while ESP NULL is unable to protect any IPv4
     options or to protect IPv6 options that are seen & processed by
     intermediate systems (e.g. routers, security gateways, other
     middle-boxes).  Some IP-layer options, for example IPSO [RFC-1108]
     and CALIPSO [RFC-5570], today are deployed in some environments 
     while using AH to provide both integrity protection & authentication.

     Further, deployed routers from multiple vendors are able to parse
     past an AH header in order to read upper-layer protocol
     (e.g. TCP) header information (e.g. to apply port-based router
     ACLs) at wire-speed.  By contrast, there is no 100% reliable way
     to parse past an ESP header, although some ESP header parsing
     heuristics have been documented [RFC-5879] that work in some cases.

Yours,

Ran Atkinson

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Apr 2014 10:25:29 -0700

> protect IP header options, but AH is preferred for that case.

That was certainly not the intention.

> middleboxes).  ESP also NEVER can prevent option insertion attacks.

Sure.

> but even the best of the heuristics for parsing past an ESP header 

Yep.

> wire-speed.  So this is a widely deployed capability, rather than

That's not an important note for this discussion, which is about what the IPsec community has expressed as a general preference. You feel that preference is wrong, and you have stated that in earlier WG discussions.

>     heuristics have been documented [RFC-5879] that work in some cases.

That is neither crisp nor clear; it is more complete; it is inaccurate about the parameters that the IPsec community cares about. The proposed text comes off as an advertisement for AH, but that's exactly the opposite direction that the WG has been leaning for this document.

If the problem is the lack of clarity in the current text, let's just make it clearer:

The IPsec community generally prefers ESP with NULL encryption over AH. AH is still required in some protocols and operational environments when there are security-sensitive options in the IP header, such as source routing headers.

Reducing the readability of this document to meet your views of AH does a disservice to the overall value of the document.

--Paul Hoffman

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 2 Apr 2014 15:33:39 -0400

> That was certainly not the intention.

OK.

> That's not an important note for this discussion, ...

Ah, but it is important, because it talks about deployed reality,
and many many users and implementers DO care about the ability 
to apply ACLs.

> which is about what the IPsec community
> has expressed as a general preference.

You are mis-characterising the "VPN community" (e.g. VPNC)
as being the whole "IPsec community".  This I-D supposedly
is NOT a VPN-focused draft, but instead claims to address 
the whole audience of IPsec implementers, users, and usages.

> You feel that preference is wrong, and you have stated
> that in earlier WG discussions.

No.  That is not what I believe or feel, NOR is the quote 
a correct summary what I have expressed in past discussions.
Instead, that is a mis-apprehension of what I have said.

In fact, I don't think that the preference for ESP with an integrated
transform is wrong or bad - for VPN uses.  Indeed, there are 
well-understood and broadly agreed reasons why - for VPNs -
ESP with an integrated transform is preferable.  Further, we all 
agree and understand that VPN is the most widely deployed use case.  
However, it is not the only deployed IPsec use case.  

A general IPsec Requirements document ought to be addressing
all deployed use cases, and ought not be limited to VPN uses.

> That is neither crisp nor clear; it is more complete;

> it is inaccurate about the parameters that the IPsec community cares about.

Precisely HOW is it inaccurate ?

I believe that everything in my text is accurate.
If there is something inaccurate, please do say precisely what.

> The proposed text comes off as an advertisement for AH, but that's exactly
> the opposite direction that the WG has been leaning for this document.

I'm open to having you or others propose some alternative text, provided
that text makes clear that ESP can't protect IP options in transit, 
while AH can.  This difference in the provided security properties is
entirely factual.  For VPN deployments, this might not matter, but
for other existing IPsec deployments it is known to matter.  Again,
this document is not about a VPN profile of IPsec, it is about the
entirety of IPsec.

> The IPsec community generally prefers ESP with NULL encryption over AH.
> AH is still required in some protocols and operational environments
> when there are security-sensitive options in the IP header, such as
> source routing headers.

This does not make clear that ESP can't protect the IP options,
which is an important-to-document limitation of ESP.

It also should mention IP sensitivity label options, such as RFC-1108 
and RFC-5570 as a use case for AH, in addition to source-routing headers.

Yours,

Ran

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Apr 2014 13:17:35 -0700

Yaron obviously gets to call consensus on this.

> and many many users and implementers DO care about the ability 

You have not said why that is important for *this discussion* which is about the document on cryptographic algorithm implementation requirements. If an implementer cares about what your previous employer shipped and so on, they are welcome to implement AH; nothing in the wording of this document says otherwise.

> as being the whole "IPsec community".  

No, I'm talking about what has been said in the WG on this topic to date. This WG is the best representation of the IPsec community that we have.

> This I-D supposedly

Correct. If it was VPN focused, it would probably not even mention AH.

> No.  

Actually, yes. Looking in the archives, I see you stating it in a few different threads.

> That is not what I believe or feel, NOR is the quote 

That is what you have said on earlier threads, so I'm not sure how you could say that what I said is wrong.

> all deployed use cases, and ought not be limited to VPN uses.

If that's what the WG wants, great. In me reading the list as a document author, I don't see people agreeing with that.

> Precisely HOW is it inaccurate ?

There has been no one on the list other than you who has given those parameters for the statement "the IPsec community generally prefers"...

> If there is something inaccurate, please do say precisely what.

Done so, now twice.

> which is an important-to-document limitation of ESP.

Good catch. Proposed improvement:

The IPsec community generally prefers ESP with NULL encryption over AH.
AH is still required in some protocols and operational environments when
there are security-sensitive options in the IP header, such as source routing headers;
ESP inherently cannot those IP options.

> and RFC-5570 as a use case for AH, in addition to source-routing headers.

Having this document listing all of the IP options from Informational RFCs would undermine the value of this document.

--Paul Hoffman

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 2 Apr 2014 16:34:52 -0400

On 02  Apr 2014, at 16:17 , Paul Hoffman wrote:
> Actually, yes. Looking in the archives,
> I see you stating it in a few different threads.

Again, that's not what I said, but instead 
what you have mis-read.

> If that's what the WG wants, great. In me reading the
> list as a document author, I don't see people agreeing with that.

If this I-D is NOT addressing all IPsec use cases, then why isn't
this I-D titled the "IPsec VPN Requirements" document ?

>   there are security-sensitive options in the IP header, such as source
>   routing headers; ESP inherently cannot those IP options.

I assume you meant to write:  s/cannot those/cannot protect those/

If I understand the intended text, that is an important and very helpful 
improvement, and I very much appreciate it being added.

> Having this document listing all of the IP options from Informational RFCs
> would undermine the value of this document.

  Adding s/source routing headers;/source routing headers or sensitivity
label options;/  plus adding those 2 RFC citations to your "proposed 
improvement" text above could not possibly "undermine the value of this 
document", particularly since both RFCs are examples of currently
deployed use cases.

  Please re-consider applying the brief text edits I've provided just above 
and the corresponding citations to those 2 RFCs.

Yours,

Ran

---

From: Paul Wouters <[email-masked]>
Date: Wed, 2 Apr 2014 18:13:10 -0400 (EDT)

> which is an important-to-document limitation of ESP.

In my 15 years of IPsec work, I've hardly seen requests for AH. When our
KLIPS stack per default disabled AH support in the kernel module, no one
complained.

> and RFC-5570 as a use case for AH, in addition to source-routing headers.

There are people that still accept source routing? How archaic....

I'm with Paul Hoffman here. I think the current text is fine.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Thu, 3 Apr 2014 09:41:05 +0300

> KLIPS stack per default disabled AH support in the kernel module, no one

FWIW nobody complained when we removed AH from our firewall in 2003, but our product uses IPsec only for VPN.

I’m also with Paul on this.

Yoav

---

From: Richard Graveman <[email-masked]>
Date: Thu, 3 Apr 2014 08:52:54 -0400

IPsec ESP and AH have a long history with user communities that pre-date
any discussion of IKE, VPN, or use cases. It is important not to damage
this history by citing comments like "my customers do not use IP or the
Internet that way." Fifteen years do not not capture this. I count
somewhere around 21 years, but I'm usually off by one or two (which is why
I don't write software anymore :-)).

One of the leading, still breathing, IPsec authors said about 20 years ago,
"There will never be an ESP NULL encryption option. Over my dead body."
Tines change, But legitimate differences exist. No one is asking for a MUST
do AH here.

In addition to what Ran said about options, there may also be protection AH
can provide for multicast that cannot be done otherwise. This has been
discussed but to my knowledge never fully resolved.

That being said, I think Ran's proposed text mixed what should be in the
document with why something should be in the document, and these aspects
should be separated.

BR, Rich Graveman

On Thu, Apr 3, 2014 at 2:41 AM, Yoav Nir <[email-masked]> wrote:

> I'm also with Paul on this.
>
> Yoav
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 4 Apr 2014 12:17:58 +0300

> this I-D titled the "IPsec VPN Requirements" document ?

I think you are wrong there. VPN uses cases do not use ESP NULL (nor
does it use AH). In all VPN cases the encryption is the important part
there. I do not really see anybody running VPN tunnels in the internet
using ESP NULL (or AH).

As Paul said if this would be VPN specific then it would not say
anything about AH or ESP NULL.

> I assume you meant to write:  s/cannot those/cannot protect those/

ESP in tunnel mode can protect end to end options without any
problems, and also protects the whole inner IP header. ESP cannot
protect options which are used by the intermediate devices, but on the
other those intermediate devices do not have the keying material to
verify the authentication header anyways so whether AH or ESP NULL is
used it does not matter.

And if the intermediate devices do have the keying material then they
can even parse through ESP NULL too as they do know the parameters.

The main problem with the AH is that it does not work with NATs which
makes its use in lots of environments difficult in the internet. It
does work in the enterprice or other controlled environments.

> document", particularly since both RFCs are examples of currently

As those options cannot be protected in transit with AH or ESP NULL
without sharing the keying material to the intermediate devices, I see
no point of listing those. 

> and the corresponding citations to those 2 RFCs.

I see no point of adding those citations, nor adding those examples.
-- 
[email-masked]