During the IPsec Workshop last week, there was a talk about removing
old unused code from the kernel and AH came up. It reminded me that I
had an open action item for the WG to find old message threads over who
the people were who last objected to it becoming Deprecated.
One message thread was on draft-ietf-ipsecme-esp-ah-reqts discussion.
This draft became RFC 7321 and was obsoleted by RFC 8221:
https://mailarchive.ietf.org/arch/msg/ipsec/HoZYWhu_Sb_L_4RVqO_T1k8fo9w/
Another thread was during WESP discussion:
https://mailarchive.ietf.org/arch/msg/ipsec/FzNFom4GQ6bUuFmYMDGDnufDtbQ/
Note all the below quotes are in the time frame of around 2009 (WESP)
and 2014 (pre RFC 7321 discussion)
In these threads, there are the following bits related to AH:
Bhatia, Manav wrote:
I agree that it is a trifle too early to start deprecating AH,
though I wouldn't mind doing so. OTOH, don't most WGs already
suggest AH as a MAY, and ESP-NULL as a MUST?
Steve Kent responded:
Not always. For example, I believe that OSPF security makes use of
AH, outside the IPsec context.
And Merike Kao responded to that:
All of the standards I've seen that explicitly define how IPsec is to
be used for authentication (including RFC 4552 - Authentication/
Confidentiality for OSPFv3) say that for authentication ESP-Null MUST
be used and AH MAY.
Which RFCs specify AH specifically as a MUST for authentication/
integrity?
Now on the flip side, in practical implementations, most vendors I
know of started off with AH being used for OSPFv3 and I doubt in
practice people are using ESP-Null. Would love to be wrong here :)
"Bhatia, Manav" followed up:
The latest PIM-SM authentication document
(http://tools.ietf.org/html/draft-ietf-pim-sm-linklocal-08)
uses IPSec to authenticate link-local messages in PIM-SM. It
too says that ESP is a MUST while use of AH is optional.
> Which RFCs specify AH specifically as a MUST for authentication/
> integrity?
I am not aware of any that do that.
> Now on the flip side, in practical implementations, most vendors I
> know of started off with AH being used for OSPFv3 and I doubt in
> practice people are using ESP-Null. Would love to be wrong here :)
I don't think this is really true. I know of at least two major
vendors that use ESP-NULL and one of them doesn't even support AH.
RJ Atkinson wrote:
Lastly, it is ALWAYS possible for an intermediate system (e.g. router
with ACLs) to parse past the AH to see transport-layer headers,
but even the best of the heuristics for parsing past an ESP header
are not 100% reliable.
[IMPORTANT NOTE: A previous employer of mine shipped IPv4/IPv6 routers
with forwarding silicon that could parse AH and any other IPv4/IPv6
options - at wire-speed for 10 Gbps interfaces - 10 years ago. I am
aware of 2 other very widely deployed implementations with the same
ability to parse past AH to read TCP/UDP ports and apply ACLs at
wire-speed. So this is a widely deployed capability, rather than
theory. :-]
Steve Kent wrote:
I would have no problem deprecating AH in the context of the IPsec
architecture document, if others agree. It is less efficient than
ESP-NULL. However, other WGs have cited AH as the IPsec protocol of
choice for integrity/authentication in their environments, so there
will be a need to coordinate with them, and it may be unacceptable to
kill AH as a standalone protocol for them.
Bhatia, Manav (Manav)" wrote:
There are currently a lot of applications (routing/signaling for
instance) where we use ESP-NULL for integrity protection
Steve Kent wrote:
Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL
(although they never refer to it that way) as a MUST, and AH as a MAY.
Manav wrote:
In fact there was some discussion of using IPSec for OSPFv2
authentication, and that proposal too uses ESP as a MUST and AH
as a MAY. http://tools.ietf.org/html/draft-gupta-ospf-ospfv2-sec-01
Daniel Migault wrote (at the time, would be interested in hearing his update)
AH is a security feature we need to keep for header authentication.
Steven Bellovin wrote:
I believe that most such uses date from the "just use IPsec"
era of security design. I further suspect that it is very rarely
used or even implemented in practice, and that in many cases it
wouldn't in fact have been usable.
Yes, as a matter of due diligence someone needs to check if it's
still mandated for anything, and if so figure out what to do.
But I'd be very happy if AH were to go awa; I concluded in 1995
that it was pretty useless.
"Bhatia, Manav wrote:
> AH is a security feature we need to keep for header authentication
Am really not sure about the value that AH adds even in case of
header authentication.
So what fields does AH protect:
Version, Payload length, Next Header, Source IP and dest IP
The only field worth modifying is the source and the dest IP. Now
note that an IPSec SA is established between a pair of source IP
and dest IP. Upon receipt of a packet containing an AH header,
the receiver determines the appropriate (unidirectional) SA,
based on the dest IP, security protocol (AH), and the SPI (it
could also include the source IP). If the attacker modifies (or
spoofs) either of the source or the dest IP, the SA lookup will
fail and the receiver will regardless discard the packet. So
what are we gaining by AH "header authentication"?
AH can only add value over ESP-NULL if there are instances
where despite address spoofing we erroneously process the IPSec
packet. I don't see that happening, so is this really an issue?
Richard Graveman followed up with:
I think this argument implicitly assumes unicast.
and Steve Kent followed up with:
you forgot IPv4 and IPv6 options that have predictable values
at the destination
And Manav followed up again:
Lets start with the IPv6 Type 0 Route Header (aka "Source Routing"
in v4 parlance), which is a mutable but a predictable extension
header. It has been discovered and is widely known that these
functionalities can be exploited in order to perform remote
network discovery, can be used to bypass firewalls and can be
used for DoS attacks. RFC 5095 has more details on this. This
has been deprecated and nobody is really using this.
Hop-by-Hop Options and Destination Extension Headers
These options contain a bit that indicates whether the option
might change (unpredictably) during transit. For any option for
which contents may change en-route, the entire "Option Data"
field must be treated as zero-valued octets when computing or
verifying the ICV. The Option Type and Opt Data Len are included
in the ICV calculation. All options for which the bit indicates
immutability are included in the ICV calculation.
If we were to use ESP-NULL instead then there is no way to
validate whether the Option Type and Opt Data Len is valid or
not till the processing is done at the receiving end.
So, what kind of attack can be possibly done by changing these
values? What is the real risk involved here?
Fragmentation Header
Fragmentation occurs after AH processing and the reassembly,
before AH processing on the other end. So, there is really no
gain there too.
Manav also wrote:
Yup, that's correct I had not considered multicast.
SSM groups would use a 3-tuple SA identifier composed of an SPI,
a dest mcast address, and the source IP. An Any-Source Multicast
group SA would only require an SPI and a dest mcast identifier. If
either of the IPs change, wouldn't the SAD lookup fail?
Steven Bellovin also wrote:
I did go through the analysis you suggest for IPv4 and concluded
that nothing was both protectable and useful. I also noted the
following issue:
Furthermore, the AH spec says that we can't
enumerate the v4 options, and hence whether or not they should
be included or not -- but RFC1122 says that unknown IP options
MUST be silently ignored. So an implementation can receive an
option that it doesn't recognize, doesn't know if it changes
en route, must be ignored anyway -- but may or may not be included
in the AH calculation, and the receiver doesn't know.
Note, of course, that that was from 1995; I have not repeated
the analysis for newer AH or IPv6 specs.
I asked Gemini to give me a list of RFCs that mandated AH and that had
AH and MAY and it gave me:
Summary Table
RFC Title AH Status Requirement
RFC 4301 IP Security Architecture MUST support AH in IPsec
implementations
RFC 4302 IP Authentication Header MUST follow for AH header
implementations
RFC 8221 Cryptographic Algorithm Requirements for ESP & AH MUST
implement specific AH algorithms if AH is built
RFC 4552 OSPFv3 Security MAY support AH (MUST support ESP)
RFC 5796 PIM-SM Link-Local Security MAY support AH (MUST support
ESP)
RFC 8213 DHCP Relay/Server Security MAY support AH (MUST support
ESP)
When working on the IKEv1 deprecation in draft-pwouters-ikev1-ipsec-graveyard,
I tried to also deprecate AH. But that effort seems to have mostly been done
in the hallways and a single line on one presentation by me during the
IETF104, but I suspect I was told that AH deprecation should go into
an 8221bis document.
https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-ikev1-graveyard-00
I am still asking some routing people:
Do people really deploy IPsec AH protection for OSPFv3 as claimed
12 years ago? Did they switch to IPsec ESP NULL? MacSEC? TCP-OA? Or
something else ?
But from what I can find, and based on the discussion bits I found,
there was already no expectation of much AH deployment and a trend
towards wanting to deprecate it. It is now 17 and 15 years since those
discussions.
Paul
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
