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

Tom,

I do not think that I wrote the SRH "breaks AH" because it does not. The only section of the SRH document about AH is whether AH could possibly be used to secure the integrity and authentication of SRH itself.

In short, I agree with you that SRH does not "break SRH" ;-)

-éric

From: Tom Herbert <tom@herbertland.com>
Date: Tuesday, 3 March 2020 at 16:25
To: Eric Vyncke <evyncke@cisco.com>
Cc: 6man <ipv6@ietf.org>, Suresh Krishnan <suresh.krishnan@gmail.com>
Subject: 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<mailto: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<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------