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

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 3 Mar 2020 09:08:51 +0000

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.

---

From: Ron Bonica <[email-masked]>
Date: Tue, 3 Mar 2020 13:56:21 +0000

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 <[email-masked]> On Behalf Of Eric Vyncke (evyncke)
Sent: Tuesday, March 3, 2020 4:09 AM
To: [email-masked]
Cc: [email-masked]
Subject: About AH (was Re: [Errata Held for Document Update] RFC8200 (5933))

-éric

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!X2VjiYp3XWEkmttsP8laiCcY8IDXlZ2c_vkPL7caKbCLg5XRwm1VMWeYjSV4doxx$ 
--------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Tue, 3 Mar 2020 07:24:53 -0800

On Tue, Mar 3, 2020, 1:09 AM Eric Vyncke (evyncke) <evyncke=
[email-masked]> 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.
>
> - 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. "
> 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

> [1] please note the quotes around 'break AH' as it is rather 'prevent the
> use of AH in transport mode' in most current discussions.
>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 3 Mar 2020 15:44:40 +0000

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 <[email-masked]>
Date: Tuesday, 3 March 2020 at 16:25
To: Eric Vyncke <[email-masked]>
Cc: 6man <[email-masked]>, Suresh Krishnan <[email-masked]>
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=[email-masked]<mailto:[email-masked]>> 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.

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.

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

-éric

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 3 Mar 2020 19:07:23 +0000

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=[email-masked]>
Date: Tuesday, 3 March 2020 at 14:57
To: Eric Vyncke <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: About AH (was Re: [Errata Held for Document Update] RFC8200 (5933))

    Eric,

    	- Payload Length
    	- Next Header

                                                                                                                 Ron

    
    -----Original Message-----
    From: ipv6 <[email-masked]> On Behalf Of Eric Vyncke (evyncke)
    Sent: Tuesday, March 3, 2020 4:09 AM
    To: [email-masked]
    Cc: [email-masked]
    Subject: About AH (was Re: [Errata Held for Document Update] RFC8200 (5933))

    

    
    -éric

---

From: Tom Herbert <[email-masked]>
Date: Tue, 3 Mar 2020 11:31:37 -0800

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Mar 2020 15:27:08 -0500

Eric Vyncke \(evyncke\) <evyncke=[email-masked]> wrote:
    > 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'.

    > (except OSPFv3) and until ESP was extended to have authentication.

I concur.
AH had one remaining use, which was to secure extension headers, such as for
use with SEND.  We screwed up the definition of how unknown SPI# should be
processed with AH (the header should be skipped, but the result is rejection).
So, we couldn't use AH when we did SEND.

AH is useless.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 Mar 2020 10:13:52 +1300

> So, we couldn't use AH when we did SEND.

Exactly. Why it isn't Historic is a mystery to me, but out of scope for these WGs.

    Brian

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 3 Mar 2020 21:17:34 +0000

> Exactly. Why it isn't Historic is a mystery to me, but out of scope for these WGs.

it's been suggested several times on ipsec@, but the idea lacked 
consensus to move forward - the general take was that header integrity 
is still occasionally important. As an observation, SRv6 may be one of 
those situations.

Nick

---

From: Tom Herbert <[email-masked]>
Date: Tue, 3 Mar 2020 13:25:42 -0800

> is still occasionally important. As an observation, SRv6 may be one of
Which seems to be the case given that SRH defines its own header
security in the form of the HMAC TLV in the header (which we have been
no reason to believe will be any more useful or deployed than AH).

Tom

---

From: Mark Smith <[email-masked]>
Date: Wed, 4 Mar 2020 09:10:53 +1100

> use; but, this is still acceptable for an IETF standard specification IMHO

So if a spec says AH doesn't apply, then all IPv6 fields are mutable within
that spec? Could that spec be on the IETF standard track? It seems so,
since SRNP with PSP is.

It seems that Network Prefix Translation could be changed from Experimental
to Standards Track just by adding an "AH doesn't apply" statement.

Errata updates to RFC 8200 may as well remove any and all processing
prohibitions rather than further clarify them, because it sounds like "AH
doesn't apply" is the loophole to avoid all of them while still claiming to
be "using" RFC 8200 IPv6.

> (except OSPFv3) and until ESP was extended to have authentication.

I seem to remember that 20 years ago when I did quite a bit of IPsec work,
Cisco worked around not having true IPsec virtual tunnel interfaces by
using GRE tunnels and then protecting them using IPSec in transport mode
with both AH and ESP; AH being necessary to protect the outer tunnel IP
header, and ESP protecting the GRE header and the GRE payload.

Deprecating AH is probably the equivalent of deprecating IPsec transport
mode.

Regards,
Mark.