Re: [IPsec] Avoiding Authentication Header (AH)

[Jack Kohn <[e-mail]>]

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

BTW, there is a discussion going on in NANOG on who uses AH and nobody
seems to be raising their hands.

Obviously, one cant take draw to much from that, but it just gives you
a data point.

Jack.

>
>        - 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
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec