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

On Tue, Mar 3, 2020 at 11:07 AM Eric Vyncke (evyncke)
<evyncke=40cisco.com@dmarc.ietf.org> wrote:
>
> 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.
>
Eric,

AH is an end to end protocol that is very specific about what data in
the packet is covered in the computation. If an intermediate node
makes changes to the packet that are not taken into account wrt fact
then that breaks the AH protocol-- this is protocol nonconformance and
a root cause of protocol ossification. It's precisely why there is
effort to define what fields are mutable and how those are interpreted
for the purposes of AH computation in every other extension header.

So instead of just saying it breaks AH and there's nothing we can do
about that, why not specify a correct and conformant protocol? I don't
see why that's a particularly hard problem for SRH-- just specify
which fields are mutable and how to deal with them. If extension
header insertion/deletion is the requirement then define a way so that
the receiver can clearly identify extension headers not used in the
source computation and exclude them (draft-herbert-6man-eh-attrib-00
can help with that).

Tom

> 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$
>     --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------