Re: About AH (was Re: [Errata Held for Document Update] RFC8200 (5933))

On Tue, Mar 3, 2020, 1:09 AM Eric Vyncke (evyncke) <evyncke=
40cisco.com@dmarc.ietf.org> wrote:

> Without any hat except the hat of an individual contributor having spent
> many years in IPsec and in IPv6 within the IETF and with real life
> deployments.
>
> As there are some discussions  about 'breaking AH' [1], here are some
> further points:
> - some IETF RFC also exclude AH in transport mode: e.g., all NAT64
> (including MAP-* as they do NAT44)
> - IPsec RFC 4301 specifies a MAY for AH and a MUST for ESP, see section
> 3.2 "IPsec implementations MUST support ESP and MAY support AH. "
> - RFC 8504 (IPv6 nodes requirements) make the support of IPsec as a SHOULD
> in section 13.1
>
> IMHO, any specification breaking AH (e.g., by modifying the NextHeader in
> transport mode) should clearly note that it 'breaks AH' or constraints its
> use; but, this is still acceptable for an IETF standard specification IMHO
> to 'break AH'.
>

Eric,

AH operation is not defined in SRH, and its use may be defined in future
documents. There is nothing inherent in SRH that prevents defining correct
operation (other types of routing header support AH). Deferring work on AH
and SRH seems to have mostly been done out if expediency to move the draft
forward in the WG.

So SRH doesn't break AH, however SRH inserting/deletion would break it as
pointed out already.

> Finally, I have spent 10+ years designing and deploying IPsec VPNs and
> very few of them were using AH and when using AH it was in tunnel mode
> (except OSPFv3) and until ESP was extended to have authentication.
>

That's anecdotal. I could just as easily point out that after five years of
SR there's no deployment or even a correct implementation of SRH HMAC
option which is supposed to be substitute for AH.

Tom

> Hope this helps to clarify the discussion about any document
>
> -éric
>
> [1] please note the quotes around 'break AH' as it is rather 'prevent the
> use of AH in transport mode' in most current discussions.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>