Hi,
Interesting discussion on the utility of Authentication Header (AH) in
IPSecME WG.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html
Post explaining that AH even though protecting the source and
destination IP addresses is really not good enough.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html
What do folks feel? Do they see themselves using AH in the future?
IMO, ESP and WESP are good enough and we dont need to support AH any
more ..
Jack
I've never seen anyone use AH vs. ESP. I've always used ESP and so has
every other IPSEC implementation I've seen anyone do.
Owen
So who uses AH and why?
Jack
Junos VRRP with md5 authentication does.....
I prefer letting the market deprecate things. If no one uses AH, someday the
IETF can mark it as "Historic," but long before that there will come a time
when no one is interested in doing any more work on it. I was at the IETF
IPsec WG meeting (in Los Angeles in the mid-90s) when AH would have died
except once Microsoft strongly endorsed it, everyone else took the anti-MSFT
viewpoint. Also, don't confuse "almost no one uses" for "no one uses" -- if
AH is useful for someone, there is no harm in having a spec that tells them
how to do it, and hopefully that spec is well written such that they can
interoperate with other implementations.
AH is less efficient than ESP because you have to buffer a whole packet
prior to calculating the Integrity Check Value that goes in the AH [header],
which goes at the front. The calculations you have to do involve parts of
the packet that are both before and after the AH [header], including the
packet's payload. Once you calculate the Integrity Check Value (ICV) you
then stuff it in the appropriate part of the AH and send the packet.
ESP's cryptographic goodness is appended at the end (and the packet is
encrypted up until that point), and you can be doing a running cryptographic
algorithm as the packet is streamed out (encrypted after the IP header and
ESP header), then append the right amount of padding and the ESP "trailer"
at the end.
This site has some nice graphical depictions of AH and ESP (including the
tunnel-mode vs. transport-mode that I didn't touch on:
http://unixwiz.net/techtips/iguide-ipsec.html)
Cheers,
~tom
I have see AH used in network segmentation. I.e. systems is group A are
configured with rules to require all communication be over AH. Systems in
group B (which have no AH and no appropriate certificates configured) can't
chat with group A. The benefit of using AH vs. ESP in this case is twofold.
First, AH is less CPU intensive, and when one considers enabling it on
all/many workstations and servers in a company, that can add up to a lot of
CPU cycles. Second, since AH only signs, not encrypts, products like
network analyzers, IDS/IPS, etc can still perform their functions.
Outside of some manual deployments, the only commercial product I know that
offers AH based network segmentation is Microsoft's NAP:
http://www.microsoft.com/nap
Regards,
Adam Stasiniewicz
I have see AH used in network segmentation. I.e. systems is group A are
configured with rules to require all communication be over AH. Systems in
group B (which have no AH and no appropriate certificates configured) can't
chat with group A. The benefit of using AH vs. ESP in this case is twofold.
First, AH is less CPU intensive, and when one considers enabling it on
all/many workstations and servers in a company, that can add up to a lot of
CPU cycles. Second, since AH only signs, not encrypts, products like
network analyzers, IDS/IPS, etc can still perform their functions.
ESP with NULL encryption only authenticates (not "signs") also. However, one can't tell in a context-free way that NULL is in use. If you're using it, though, I can't see how AH could be less expensive.
AH has been controversial for years. I've been asking folks to delete it since 1995. I've never succeeded... At least RFC 4301 deprecated it to a MAY instead of a MUST for IPsec implementors.
Outside of some manual deployments, the only commercial product I know that
offers AH based network segmentation is Microsoft's NAP:
http://www.microsoft.com/napRegards,
Adam StasiniewiczFrom: Jack Kohn [mailto:kohn.jack@gmail.com]
Sent: Friday, November 13, 2009 6:23 PM
To: nanog@nanog.org
Subject: AH is pretty useless and perhaps should be deprecatedHi,
Interesting discussion on the utility of Authentication Header (AH) in
IPSecME WG.http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html
Post explaining that AH even though protecting the source and
destination IP addresses is really not good enough.http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html
What do folks feel? Do they see themselves using AH in the future?
IMO, ESP and WESP are good enough and we dont need to support AH any
more ..Jack
--Steve Bellovin, http://www.cs.columbia.edu/~smb
I've seen AH used as a "prove that this hasn't been through a NAT" mechanism. In this context, it's pretty much perfect.
However, what I don't understand is where the dislike for it originates: if you don't like it, don't run it. It is useful in certain cases, and it's already in all of the production IPSec implementations. Why the hate?
David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com
There are two reasons. First, it's difficult to implement cleanly, since it violates layering: you have to know the contents of the surrounding IP header to calculate the AH field. Back when I was security AD, I had implementors, especially implementors of on-NIC IPsec, beg me to get rid of it. Second, it's redundant; if (as I believe), ESP with NULL encryption does everything useful that AH does, why have two mechanisms?
--Steve Bellovin, http://www.cs.columbia.edu/~smb
They are planning to make OSPFv3 IPSec authentication useless?
Best Regards,
Janos Mohacsi
I've seen AH used as a "prove that this hasn't been through a NAT" mechanism. In this context, it's pretty much perfect.
However, what I don't understand is where the dislike for it originates: if you don't like it, don't run it. It is useful in certain cases, and it's already in all of the production IPSec implementations. Why the hate?
There are two reasons. First, it's difficult to implement cleanly, since it violates layering: you have to know the contents of the surrounding IP header to calculate the AH field. Back when I was security AD, I had implementors, especially implementors of on-NIC IPsec, beg me to get rid of it. Second, it's redundant; if (as I believe), ESP with NULL encryption does everything useful that AH does, why have two mechanisms?
Maybe someone should push through a "IPSEC-lite" in the same way we are pushing through IGMPv3-lite.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Regards
Marshall
No - if you read the below pointers carefully it does specify that ESP-Null is a MUST for OSPFv3 authentication protocol while AH is a MAY. AH is mostly superfluous and complicates implementations.
Someone on the IPsec mailing list stated that at least two implementations he was aware of used ESP-Null for OSPFv3 where one did not even have any support for AH.
And I know I'm probably violating some posting etiquette here but to answer an earlier comment on same thread where someone asked why the hate for AH and what's problem if it's already in all of the production IPsec implementations.......I can firsthand state that for many IPsec interoperability tests AH is hardly if ever tested. I have been a part of some of them as an interested 3rd party (i.e. non vendor) so have seen what gets tested. AH is always last from what I've seen and rarely does anyone ever get to it. [caveat - my experience comes from multivendor consortium type tests and not what vendors may do privately amongst themselves]
And FWIW.....I've been doing skunskwork IPsec for past 10 years and right now there's yet another effort to come up with interoperable defaults which is being lead by the aviation industry and is looking at IETF defined profiles, NSA related recommendations, NIST recommendations and ICSA IPsec consortium recommendations. There was a meeting in Seattle last week and many vendors as well as NIST, DoD and other parties participated. If you are at all running IPsec in a major way and care about interoperable defaults and consistent terminology, contact me offline and I'll get you connected to the group. Vendors will only 'fix' their implementations if there's cohesion from customer base.
- merike
Owen DeLong wrote:
I've never seen anyone use AH vs. ESP.
OSPFv3?
Maybe I'm asking a dumb question, but why would one prefer AH over ESP
for OSPFv3?
RFC4552:
"In order to provide authentication to OSPFv3, implementations MUST
support ESP and MAY support AH."
-Bill
Bill Fehring wrote:
Owen DeLong wrote:
I've never seen anyone use AH vs. ESP.
OSPFv3?
Maybe I'm asking a dumb question, but why would one prefer AH over ESP
for OSPFv3?
Header protection... still doesn't provide replay protection, your
mileage may vary
http://tools.ietf.org/html/draft-ietf-opsec-routing-protocols-crypto-issues-02
I read the draft and its very interesting. There were some issues that
i had never imagined could exist and it does a wonderful job of
brining them forth.
However, i still dont understand why AH would be preferred over
ESP-NULL in case of OSPFv3. The draft speaks of issues with replaying
the OSPF packets. One could also do these things with AH.
Am i missing something?
Jack
Neither protects against replay without additional measures.
However, AH is very close... consider using AH-authenticated
packets with the timestamp option and clock synchronization between
peers.
Discard packets arriving that are more than 5 minutes old.
In transport mode for security between LAN peers, ESP NULL verifies
the integrity of only the data payload in the packet. AH secures
the header, the IP header fields and options.
Therefore changing the timestamp to replay would be detected.
This evil act would not be detected if you are using ESP NULL, the
attacker can potentially replay this packet, while the SPI is still
good, and you'll never know.
One of AH's most visible disadvantages (cannot be used with NAT) is a
side-effect of the increased security coverage it provides. Many IPv4
networks require NAT, making AH impractical.
However, matters could change for IPv6 networks with high
security requirements, that need to validate authenticity of more
than just packet contents...
Except for multicast packets -- the case of interest for OSPFv3, and even there the spec arguably got it wrong -- you can check the source IP address against the SPD. That is, you can't replay my ESP packets in a unicast connection with a different source address because packets from your source address on my SPI will be rejected.
ESP does have antireplay protection; admittedly, that's disabled if manual keying is used, but generally speaking, manual keying shouldn't be used, per RFC 4107.
The interesting case is multicast. 4552 seems to assume symmetric keys, but that's a bad idea; it lets other members of the authorized group impersonate each other. What you really want is digitally signed packets, where each source has a key. I don't think that the IETF's multicast key management protocols are quite up to the job, though; they focus on single source multicast, which isn't what OSPF needs. (That said, 5374 seems to point in the proper direction, but I haven't been following this work.) It may be that the proper answer for OSPFv3 is its own strong multicast security.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
+1.
I know of a network whose owners are far more worried about a replay attack than about data being revealed to the outside world.
They need to verify the provenance of data (i. e. Make sure that it hasn't bee Natted), and AH is a simple way to do these precise things.
-David Barak
James Hess wrote: