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

Ron,

As I restricted the topic of this email thread to AH support by protocols in general, so, let's stick to this topic only if you do not mind.

And, if a document is about a protocol changing the Next Header field of an IPv6 header protected by AH in transport mode then it will not work obviously. So, yes, the PSP behavior of the current network-programming draft is incompatible with AH in transport mode. Like many other existing RFC and AH is no more a requirement for IPv6 nodes. As long as there is a mention in the document that it is not compatible with AH in transport mode, I see no problem at all.

Hope it clarifies my previous email

Regards

-éric
-----Original Message-----

From: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Date: Tuesday, 3 March 2020 at 14:57
To: Eric Vyncke <evyncke@cisco.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Cc: "suresh.krishnan@gmail.com" <suresh.krishnan@gmail.com>
Subject: RE: About AH (was Re: [Errata Held for Document Update] RFC8200 (5933))

    Eric,

    PSP breaks every IPv6 feature and every upper-layer protocol that relies on the immutability of the following  fields in the IPv6 header:

    	- Payload Length
    	- Next Header

    We know that PSP breaks the AH. Can you assure me that it doesn't break anything else? 

                                                                                                                 Ron

    Juniper Business Use Only

    -----Original Message-----
    From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Eric Vyncke (evyncke)
    Sent: Tuesday, March 3, 2020 4:09 AM
    To: ipv6@ietf.org
    Cc: suresh.krishnan@gmail.com
    Subject: About AH (was Re: [Errata Held for Document Update] RFC8200 (5933))

    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'.

    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.

    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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!X2VjiYp3XWEkmttsP8laiCcY8IDXlZ2c_vkPL7caKbCLg5XRwm1VMWeYjSV4doxx$ 
    --------------------------------------------------------------------