Re: Failure of AH

[Michael Richardson <[e-mail]>]

Brian E Carpenter <[e-mail]> wrote:
    > On 21/03/2017 03:17, Michael Richardson wrote: ...
    >> So I'm just not worried about breaking AH.

    > That's well understood for today's AH. What bothers me is that if we
    > allowed en-route changes to headers now, without thinking this aspect
    > through, we might make any future AH-like authentication mechanism
    > impossible too. So at a minimum, we'd have to be sure that inserted,
    > modifiable and deletable headers are marked in some way that will allow
    > them to be excluded from authentication. That was thought about years
    > ago for IPv6 options, but not for extension headers.

a) AH was invented in the early 1990s, and was a response to the realization
   that we might not get a cryptographic system out of the US that included
   encryption.

b) it has never been useful for authenticating IPv6 headers.  The one time
   that we got close was SEND, and we specified the "unknown SPI" behaviour
   wrong so we couldn't do SEND as AH+ICMP unless we had a flag day.

c) I would claim that the headers that would most benefit from being
   authenticated would ones inserted mid-path :-)
   That argues actually for IPIP encapsulation of those headers so that
   the trust anchor is the IPv6 src address. (but, AH SPI# are allocated by
   destinations, not senders, so AH is also wrong for that)

   But, we have inadequately documented IPIP header decapsulation by end
   hosts, explaining that they should ignore AH (or AHng) headers that they
   do not understand.

d) does 7045 even give us enough power to create AHng?  I didn't read it
   that way.

I'm just not convinced that "breaks IPsec" is a valid concern.
(And I weep saying this)


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-