Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson <[e-mail]>]

Folks,

I mostly entirely agree with Michael Richardson's
analysis at the URL just below, namely that AH continues
to have utility -- but that utility is not VPN deployments.

Michael Richardson's note:
	<http://www.ietf.org/mail-archive/web/ipsec/current/msg07363.html>


HISTORY

Important history is that both ESP and AH were originally
products of the IPv6 Working Group.  They moved into the
IPsec WG because the IPsec WG had not made significant
progress at that time (early 1990s).

AH was created and exists primarily to enable authentication, 
including intermediate authentication, of IPv4 and IPv6 
options, extension headers, and so forth.  



BACKGROUND & AVAILABILITY:

Many modern silicon-based routers and firewalls, from multiple 
router vendors, can parse or parse-past options and optional 
headers at wire speed, so existence of an IP-layer option or 
extension does not today automatically push the IP packet 
on to what folks historically called the "slow path" for 
packet forwarding.  This makes it much more practical to
deploy IP options and IP optional headers now than in the
past.

Virtually all IPv6 hosts, and most IPv4 hosts, support AH 
in shipping product, and have done for ~15 years now.  This 
includes both commercial products and open-source implementations.  
Most major IPv6 routers, for example multiple product lines 
from both Cisco and Juniper, also support AH in shipping 
product and have done for some while now.  So AH remains 
a very widely available protocol.



CURRENTLY DEPLOYED USES:

While AH uses are limited today, just as the use of
IP options/extensions are limited today, current active 
uses of AH in real-world deployments today include at least
these -- built using commercial off-the-shelf products:

	- AH with IPv4 to authenticate sensitivity label 
	  options (e.g. FIPS-188, RFC-1108).

	- AH with IPv4 to prevent options-based attacks,
	  primarily in certain high-threat environments.

	- AH with IPv6 to authenticate certain IPv6
	  extension headers and options, primarily in
	  certain high-threat environments.

	- AH with IPv6 to prevent extension-header-based
	  and options-based attacks, primarily in certain
	  high-threat environments.

	- Many IPv6 deployments using OSPFv3 have enabled
	  OSPFv3 protection using AH.  Most router vendors,
	  including (for example) multiple product lines 
	  from both Cisco and Juniper, shipped this capability 
	  long ago -- and this use of AH is both interoperable 
	  and widespread, largely within IPv6 enterprise
	  deployments.  OSPFv3 itself is largely deployed in
	  enterprises today, as I/IS-IS is more popular with
	  ISPs.

	  [NOTE WELL:  AH for OSPFv3 has NOT been deprecated, and
	  remains on the IETF standards track.  It is interesting,
	  however, that author of this AH draft is trying to kill 
	  off the use of AH to protect routing information -- 
	  apparently because his employer does not offer this 
	  AH for OSPFv3 capability in its released products.]

	- Some IPv6 profiles, including the US Government
	  profile for IPv6, require AH support either generally
	  or in certain situations (example: to protect OSPFv3,
	  to authenticate certain IP options or IP extension
	  headers).

This WG ought not make existing legitimate uses of AH
invalid or not recommended.  There is no available alternative
for authenticating IP-layer options, extension headers,
and so forth.  AH is the only available way to do such
authentication at present.


FIREWALLS & MIDDLEBOXES:

While this WG has produced some documents with guidance
on how to approach parsing past an ESP header when NULL
encryption is used, we still do not have a completely
reliable way to parse past an ESP header when NULL 
encryption is used.  

By contrast, it is easy and quick to parse past an AH header 
-- either in the end system or in a firewall/router/middlebox.  
Several deployed firewall products in fact can and do 
parse past AH headers, either to perform deep packet inspection 
or simply to examine the transport protocol and port information.  


IETF PROCESS RULES:

Last, on an IETF Process note, the IPsec WG Charter posted
online is quite strict and is narrowly defined, with an
enumerated list of allowed work items.  To quote from
the charter:

	"The scope of the WG is restricted to the 
	work items listed above."

Neither changes to AH status nor Applicability Statements
for AH are listed in the WG Charter.

So it is not obvious that this document is within the charter 
for the IPsec ME WG.  

If the IPsec ME WG Chairs believe this work is within charter, 
they ought to post a note to the IPsec ME WG mailing list
citing the specific charter text authorising this topic.

IPsec ME Charter:
	<http://datatracker.ietf.org/wg/ipsecme/charter/>

A draft outside the Charter of an IETF WG ought not
be developed by or within that WG.  So I don't see 
how this document properly can be considered by this WG.


Yours,

Ran