Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts

RJ Atkinson <> Tue, 04 March 2014 09:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8AA451A0449 for <>; Tue, 4 Mar 2014 01:26:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iIfLIYZnrAjb for <>; Tue, 4 Mar 2014 01:26:41 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::230]) by (Postfix) with ESMTP id 835671A042E for <>; Tue, 4 Mar 2014 01:26:41 -0800 (PST)
Received: by with SMTP id b13so4587273wgh.31 for <>; Tue, 04 Mar 2014 01:26:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=vogmnVM+oPN7EjF4yUbpdAssHvrySm+4dxnWA2nyhX0=; b=pkxh6gy1KabzITT8hl9OtCa0KnH4bigdKlK6vZtkhFMh/ayHCeJKFNuPnnG/6G0JGR Z+U7I3B5BPA6zZ855bMtq9v2qzR12OOgB6Mb6AW+E7TS85fxuFTuYH3MRqShyidZ9jNC osa2TEc2rF9oxz3Ma2nod0qPdlLKSqaPLSHcsWZXyTko+6bslJrSpASoWcl9sknX2iOP wAsRYdnItXplN+Ia3BzaUFf2e4pQICQp9HcoyqYoIFj2cTHLFXlOoXpTf4M189d/Nl3h +BAoCkS06VujPb3Nw3FxE5D3HNCQGS5OsinX7O+TeKIP9C1gbWfsK9NDXzh99n4LDhHq jLQA==
X-Received: by with SMTP id ww4mr2258002wjc.58.1393925197948; Tue, 04 Mar 2014 01:26:37 -0800 (PST)
Received: from ([]) by with ESMTPSA id r3sm49005433wjw.0.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 01:26:37 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1283)
From: RJ Atkinson <>
In-Reply-To: <>
Date: Tue, 4 Mar 2014 04:26:33 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <>
To: IPsec ME WG List <>
X-Mailer: Apple Mail (2.1283)
Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Mar 2014 09:26:44 -0000

On 03  Mar 2014, at 17:53 , Paul Wouters wrote:
> On Mon, 3 Mar 2014, RJ Atkinson wrote:
>>> 	ESP-NULL offers the same protection as AH, ...
>> This sentence above is not true.  ESP-NULL and AH provide
>> different security properties to the IP-layer.
>> AH protects all IP options, whereas ESP cannot protect any
>> IP options that appear prior to the ESP header -- the location
>> in the packet where those IP options are seen *and acted upon*
>> by routers/firewalls/etc.
> What meaning has "protecting" those bits? Endpoint A and B protect
> something by cryptography, but any router in the middle can't trust
> those signatures anyway. So I don't see how AH is different from
> ESPinUDP where you set those options in the UDP header. These are
> not "protected" but the router can't verify the crypto anyway.

At least some deployed routers in the middle in some deployments
ARE able to validate and therefore trust the AH values (and trust 
that the IP options present were placed there by the sender).  This 
was ALWAYS something that was designed-in to AH (RFC-1826, Section 1.1).  
Some other kinds of middleboxes (e.g. some firewalls) also can do this.

Some AH implementations that support asymmetric keying go back 
at least 15 years, although those were not standardised back in 1995 
-- primarily due to IPR considerations on intermediate authentication
(which IPR I believe either has expired or expires very soon).  

>> Similarly, AH protects many IP header fields from in-transit
>> modification, whereas ESP encapsulation provides no protection
>> for the 1st (outer) IP header (i.e., that appears before the ESP header).
> So I don't buy that. The IP header is not protecting the packet from
> a router, which cannot confirm the crypto of that protection.

Some deployed IPv4 routers can confirm the AH authentication information
in some deployments.  This has been true for years.  

Note that RFC-1826, Section 1.1, contains explicit discussion of the 
applicability of AH with asymmetric algorithms to enable intermediate 

> What this
> is really about is exposing things like QoS bits,


IETF standards say that the IP ToS/DiffServ bits are allowed 
to be modified in-transit.  For example see Section 7.2 of 
RFC-2474 & also page 10 of RFC-2402.

> but those devices
> acting on those are not verifying any "protection". They are blindly
> using the exposed options.  So ESPinUDP works equally well here.


>> As a prior discussion has noted, AH can and is used to provide
>> cryptographic protection to some security-critical IP options
>> (e.g. sensitivity labels).  ESP-NULL is not capable of protecting
>> those options.
> I'm not sure what you are referring to here. Not labeled IPsec I
> take it? And again, how does this "protection" work? How do the
> routers verify this "protection" when only the endpoints know
> the crypto keys used to protect the header and payload?

As an example, one can have (and real deployments exist) where
an IPv4 sensitivity label (e.g. FIPS-188) in an IPv4 packet is 
protected by AH, using asymmetric cryptography, where both 
end systems and also intermediate label-policing IP routers can 
validate the digital signatures carried by AH to validate that
the sensitivity label has not been tampered with since it was
placed in the packet by the sender.  Not all deployments where
FIPS-188 is in use also use/deploy AH for protection, but some
FIPS-188 deployments definitely do.

- ESP-in-UDP can NOT do this.  
- ESP-NULL can NOT do this in any other way either.

> Can you explain how this protection works? If an AH packet flies by,
> and I change the QoS option from off to on to give my packet preference
> in the network, how will the next router notice this and ignore
> this QoS option?

As noted above, the IP ToS/DiffServ byte explicitly is excluded
from AH protection, originally because some deployed routers were 
known to change the field in-transit (RFC-2402) and later (after 
RFC-2474) because IETF standards explicitly say that modifying 
that field in-transit is allowed.

>> Some deployments definitely do care.  Other deployments do not.
> By understanding was always that people didn't like options getting
> "lost" or "hidde" within the ESP payload, and not getting set on
> the outer packet.

While some people might have that view, 
that never has been a universal view.

Broadly speaking, the primary case against using any IP option
is that *historically* the presence of an IP option in an IP 
packet caused that packet to be forwarded on the "slow path"
of many commercial IP routers.  That is not necessarily the case
today, although it reportedly still is the case for some products.  

A commercial router vendor that I worked a decade ago for shipped 
silicon that could fast-path, at wire-speed, for then high-speed
interfaces (i.e., 10 Gbps) packets containing options -- simply
because the silicon included logic to parse around the option 
to locate the start of the upper-layer header and apply any
needed transport-protocol/port-number ACLs.  As I noted during 
this past Sunday's IEPG meeting, I know of at least one other
vendor with an independent implementation in silicon (ASIC or FPGA)
that can parse packets at wire speed (e.g. can find the TCP header
and TCP port numbers and apply an ACL using an ASIC in a packet 
with IPv6 header + IPv6-Dest-Opts-Header + TCP).  So the
performance argument against IP options might be diminishing.

Despite that, some IP options have been in use in some deployments 
since the late 1980s (at least since BLACKER was deployed -- 
for example see RFC 1038).

The bottom line for AH is this:
- AH is optional to implement, so it is a business decision whether
  a particular product implements it or not.  Many many products
  do implement AH, both now and in the past.
- Implementations of AH with asymmetric cryptography also exist
  and are deployed both now and in the past.
- Real deployments exist that use AH to protect IP options in
  transit, including intermediate authentication of the 
  AH contents by some deployed IP routers.
- Real applications exist where AH is the only solution available
  (i.e. no form of ESP can provide the needed protection and no
  other IETF protocol can provide the needed protection).
- It is always possible to parse past an AH header to find an 
  upper-layer header.  Despite work on heuristics, there is no 
  100% reliable way to parse past the SPI field of an ESP header.

  So I believe that AH meets all the IETF criteria (e.g., use case,
implementation, & deployment) for being retained as is.

  No one is forced to use AH or implement AH if one doesn't
care to do so.  However, for some deployments, there is no 
technical alternative to using AH at present.