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

[Paul Hoffman <[e-mail]>]

On Apr 2, 2014, at 8:53 AM, RJ Atkinson <[e-mail]> wrote:

> 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.

That was certainly not the intention.

> 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.

Sure.

> 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.

Yep.

> [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. :-]

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.

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

Yes, but:

> 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.

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