Re: Does anybody out there use Authentication Header (AH)?
Tom, It seems NIST recommends ESP over AH. You can look at the following 2 emails from Manav and Sriram on the IPsecME WG: http://www.ietf.org/mail-archive/web/ipsec/current/msg07403.html http://www.ietf.org/mail-archive/web/ipsec/current/msg07407.html Jack On Mon, Jan 2, 2012 at 5:57 AM, TR Shaw ts...@oitc.com wrote: On Jan 1, 2012, at 7:12 PM, John Smith wrote: Hi, I am trying to see if there are people who use AH specially since RFC 4301 has a MAY for AH and a MUST for ESP-NULL. While operators may not care about a MAY or a MUST in an RFC, but the IETF protocols and vendors do. So all protocols that require IPsec for authentication implicitly have a MAY for AH and a MUST for ESP-NULL. Given that there is hardly a difference between the two, I am trying to understand the scenarios where people might want to use AH? OR is it that people dont care and just use what their vendors provide them? Regards, John AH provides for connectionless integrity and data origin authentication and provides protection against replay attacks. Many US Gov departments that have to follow NIST and do not understand what this means require it between internal point-to-point routers between one portion of their organization and another adding more expense for no increase in operational security. If you are following NIST or DCID-63, this is required to meet certain integrity requirements ESP provides confidentiality, data origin authentication, connectionless integrity, an anti-replay service, and limited traffic flow confidentiality. EG AH portion provides for the integrity requirement and the ESP encryption provides for the confidentiality requirement of NIST. Think of AH that it is like just signing a PGPMail and ESP as signing and encrypting a PGPMail. There are reasons for both. Tom
Re: Does anybody out there use Authentication Header (AH)?
The __exact__ same discussion happening on IPsecME WG right now. http://www.ietf.org/mail-archive/web/ipsec/current/msg07346.html It seems there is yet another effort being made to retire AH so that we have less # of options to deal with. This time there is some support for it .. Jack On Mon, Jan 2, 2012 at 7:20 AM, Steven Bellovin s...@cs.columbia.edu wrote: On Jan 1, 2012, at 8:34 PM, TR Shaw wrote: John, Unlike AH, ESP in transport mode does not provide integrity and authentication for the entire IP packet. However, in Tunnel Mode, where the entire original IP packet is encapsulated with a new packet header added, ESP protection is afforded to the whole inner IP packet (including the inner header) while the outer header (including any outer IPv4 options or IPv6 extension headers) remains unprotected. Thus, you need AH to authenticate the integrity of the outer header packet information. Not quite. While the cryptographic integrity check does not cover the source and destination addresses -- the really interesting part of the outer header -- they're bound to the security association, and hence checked separately. Below is a note I sent to the IPsec mailing list in 1999. That, however, is not the question that is being asked here. The IPsecme working group has been over those issues repeatedly; your (non)-issue and (slightly) more substantive issues about IPv6 have been rehashed ad nauseum. The questions on the table now are, first, are operators using AH, and if so is ESP with NULL encryption an option? --Steve Bellovin, https://www.cs.columbia.edu/~smb One of the biggest reasons we have AH is because there _are_ some things in the middle of the IP header that need to be authenticated for them to be simultaneously safe and useful. The biggest example of this is source routing. In my opinion -- and I've posted this before -- there's nothing in the IP header that's both interesting and protected. You can't protect the source routing option, since the next-hop pointer changes en route. Appendix A of the AH draft recognizes that, and lists it as 'mutable -- zeroed'. When you look over the list of IP header fields and options that are either immutable or predictable, you find that the only things that are really of interest are the source and destination addresses and the security label. To the extent that we want to protect the addresses -- a point that's very unclear to me -- they're bound to the security association. The security label certainly should be. If you're using security labels (almost no one does) and you don't have the facilities to bind it at key management time, use tunnel mode and be done with it. I'll admit that I've never been in the operations business, but I've been told that source routing is a very useful tool for diagnosing some classes of problems. AH allows source routing to be useful again w/o opening the holes it opens. Well, yes, but not for the reason you specify. The problem with source routing is that it makes address-spoofing trivial. With AH, people will either verify certificate names -- the right way to do things -- or they'll bind a certificate to the source address, and use AH to verify the legitimacy of it. The route specified has nothing to do with it, and ESP with null encryption does the same thing. I don't like AH, either in concept or design (and in particular I don't like the way it commits layer violations). Its only real use, as I see it, is to answer Greg Minshall's objections -- it leaves the port numbers in the clear, and visible in a context-independent fashion. With null encryption, the monitoring station has to know that that was selected. But I'm very far from convinced that these issues are important enough to justify AH. All that notwithstanding, this is not a new issue. We've been over this ground before in the working group. Several of us, myself included, suggested deleting AH. We lost. Fine; so be it. Let's ship the documents and be done with it.
Re: AH is pretty useless and perhaps should be deprecated
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 On Mon, Nov 16, 2009 at 11:47 AM, Joel Jaeggli joe...@bogus.com wrote: Bill Fehring wrote: On Sun, Nov 15, 2009 at 20:48, Joel Jaeggli joe...@bogus.com 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 RFC4552: In order to provide authentication to OSPFv3, implementations MUST support ESP and MAY support AH. -Bill
AH is pretty useless and perhaps should be deprecated
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
Re: AH is pretty useless and perhaps should be deprecated
So who uses AH and why? Jack On Sat, Nov 14, 2009 at 6:19 AM, Owen DeLong o...@delong.com wrote: 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 On Nov 13, 2009, at 4:22 PM, Jack Kohn wrote: 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
Huawei cx300
Guys, Anybody any experience with VPLS on Huawei cx300? Jack
Re: AH or ESP
The delusion that network operators can successfully use unhelpful protocols and/or smoke and mirrors to force idealist network design on others needs to end. People use new protocols because they are better. If the benefit of moving to a new protocol does not outweigh the pain of moving to it, people don't use it. That's why the OSI protocols did not kill IP like they were supposed to in the 90s, it is why the largely forgotten mandated move from Windows to secure OSes (ie, Unix) for all government employees never happened, and it is why IPv6 is sputtering. If people want to use NAT, they are going to use NAT. They may stop using it if the widespread adoption of peer to peer protocols means they are missing out on things other people are doing. They are not going to stop using NAT to use a protocol maliciously designed to break it; they will just wait, patiently and nearly always successfully, for somebody to come out with a version that has no such malice. They are certainly not going to stop using NAT because somebody tells them they should use a security protocol that does not secure anything worth securing. BitTorrent is a better anti-NAT tool than AH ever will be. More carrot, less stick. I agree. Folks are going to use ESP-NULL if they really want Integrity Protection .. -Dave
Re: AH or ESP
Glen, IPSECME WG http://www.ietf.org/html.charters/ipsecme-charter.html at IETF is actually working on the exact issue that you have described (unable to deep inspect ESP-NULL packets). You can look at draft-ietf-ipsecme-traffic-visibility-02http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-02for more details. Jack On Sat, May 23, 2009 at 5:06 AM, Glen Kent glen.k...@gmail.com wrote: Yes, thats what i had meant ! On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, May 22, 2009 at 1:04 PM, Glen Kent glen.k...@gmail.com wrote: Hi, It is well known in the community that AH is NAT unfriendly while ESP cannot be filtered, and most firewalls would not let such packets pass. I am NOT 'the content of the esp packet can't be filtered in transit' I think you mean... right? interested in encrypting the data, but i do want origination authentication (Integrity Protection). Do folks in such cases use AH or ESP-NULL, given that both have some issues? Thanks, Glen
Re: AH or ESP
Not really. Currently, you cant even look at the ESP trailer to determine if its an encrypted or an integrity protected packet, because the trailer itself could be encrypted. A router, by reading the next-header field from the ESP trailer can never be sure that its an OSPFv3 packet inside since it wouldnt know whether the packet is encrypted or not. One could have an encrypted packet inside, for which the next-header field turns out to be 89, but that may not necessarily mean that its an OSPFv3 packet. It could be a VoIP packet that just happens to look like OSPFv3 once encrypted. There is no indication sent on the wire that says that the packet is encrypted. So, there is no way to identify/deep inspect/filter ESP packets unless you're the recipient, which imo is the root cause of all heart burn in the intermediate devices like firewalls, transit routers, etc. A couple of solutions were thrown at the WG and the current one (wesp) was selected as the best. I agree that we should just throw out AH and stick to one protocol which has been extensively tested. A quick scan through some of vendors data sheets quickly reveals that most of them dont even provide support for AH. Jack On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo k...@merike.com wrote: Yeah - the main issue with using ESP is that there's a trailer at end of packet that tells you more info to determine whether you can inspect the packet. So you have to look at the end of the packet to see whether ESP is using encryption or null-encryption (i.e. just integrity protection). Some vendors do have proprietary mechanisms in software for now which doesn't scale. The work below will hopefully lock into a solution where hw can be built to quickly determine if ESP is used for integrity only. AH is not really widely used (except for OSPFv3 since early implementations locked in on AH when the standard said to use IPsec for integrity protection). Note that a subsequent standard now exists which explicitly states that ESP-Null MUST be supported and AH MAY be supported. But how many folks are actually running OSPF for a v6 environment and using IPsec to protect the communicating peers? Some but not many (yet). Personally, I'd stick with ESP. AH complicates matters (configuration, nested environments when you do decide to also use ESP for encryption maybe later, NAT) and while is isn't officially deprecated vendors don't test it as much as ESP - at interoperability tests it's not stressed, at least the ones I've been to. Ask your vendor(s) what they think of the work below and see where they stand with implementing it. Be happy to answer any more questions offline. - merike On May 25, 2009, at 6:24 AM, Jack Kohn wrote: Glen, IPSECME WG http://www.ietf.org/html.charters/ipsecme-charter.html at IETF is actually working on the exact issue that you have described (unable to deep inspect ESP-NULL packets). You can look at draft-ietf-ipsecme-traffic-visibility-02http://tools.ietf.org/html/ draft-ietf-ipsecme-traffic-visibility-02for more details. Jack On Sat, May 23, 2009 at 5:06 AM, Glen Kent glen.k...@gmail.com wrote: Yes, thats what i had meant ! On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, May 22, 2009 at 1:04 PM, Glen Kent glen.k...@gmail.com wrote: Hi, It is well known in the community that AH is NAT unfriendly while ESP cannot be filtered, and most firewalls would not let such packets pass. I am NOT 'the content of the esp packet can't be filtered in transit' I think you mean... right? interested in encrypting the data, but i do want origination authentication (Integrity Protection). Do folks in such cases use AH or ESP-NULL, given that both have some issues? Thanks, Glen
Re: AH or ESP
Hmm .. besides this, AH is *never* export restricted. Also, i could be mistaken, but isnt AH compliance mandatory in IPv6? Earlier there were some issues in using ESP with TCP performance enhancement proxies used in wireless networks, which couldnt deep inspect the ESP packets to extract TCP flow IDs and seq numbers, but that should all change with the new WESP proposal. Jack On Tue, May 26, 2009 at 8:21 AM, Merike Kaeo k...@merike.com wrote: Coming from someone who is somewhat jaded.politics. Realistically there are some folks who believe that not having the IP header (and with v6 also the option headers) integrity protected is an issue. It's not. You have more risk of operation issues from adding complexity of AH.note that the fields that are modified in transit in the headers are NOT included in the integrity protection. So it really becomes an issue of is the IP address protected and basically, yes that's done via IKE and the way security associations work anyhow. [if you change IP address of header you will not have appropriate security association match] Once the technology is there to quickly differentiate ESP-Null from ESP-encrypted packets the argument of but you can inspect AH packets becomes irrelevant. - merike On May 25, 2009, at 5:23 PM, Glen Kent wrote: Just a quick question: Why do we need AH when we have ESP-NULL? Is AH now being supported only for legacy reasons? The only negative with ESP-NULL afaik was that it could not be filtered (since packets could not be inspected), however, this changes with the wesp proposal. Also, the fact that AH is NAT unfriendly should be the final nail in its coffin. Any reasons why we still see it around? Thanks, Glen On Tue, May 26, 2009 at 5:44 AM, Jack Kohn kohn.j...@gmail.com wrote: Not really. Currently, you cant even look at the ESP trailer to determine if its an encrypted or an integrity protected packet, because the trailer itself could be encrypted. A router, by reading the next-header field from the ESP trailer can never be sure that its an OSPFv3 packet inside since it wouldnt know whether the packet is encrypted or not. One could have an encrypted packet inside, for which the next-header field turns out to be 89, but that may not necessarily mean that its an OSPFv3 packet. It could be a VoIP packet that just happens to look like OSPFv3 once encrypted. There is no indication sent on the wire that says that the packet is encrypted. So, there is no way to identify/deep inspect/filter ESP packets unless you're the recipient, which imo is the root cause of all heart burn in the intermediate devices like firewalls, transit routers, etc. A couple of solutions were thrown at the WG and the current one (wesp) was selected as the best. I agree that we should just throw out AH and stick to one protocol which has been extensively tested. A quick scan through some of vendors data sheets quickly reveals that most of them dont even provide support for AH. Jack On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo k...@merike.com wrote: Yeah - the main issue with using ESP is that there's a trailer at end of packet that tells you more info to determine whether you can inspect the packet. So you have to look at the end of the packet to see whether ESP is using encryption or null-encryption (i.e. just integrity protection). Some vendors do have proprietary mechanisms in software for now which doesn't scale. The work below will hopefully lock into a solution where hw can be built to quickly determine if ESP is used for integrity only. AH is not really widely used (except for OSPFv3 since early implementations locked in on AH when the standard said to use IPsec for integrity protection). Note that a subsequent standard now exists which explicitly states that ESP-Null MUST be supported and AH MAY be supported. But how many folks are actually running OSPF for a v6 environment and using IPsec to protect the communicating peers? Some but not many (yet). Personally, I'd stick with ESP. AH complicates matters (configuration, nested environments when you do decide to also use ESP for encryption maybe later, NAT) and while is isn't officially deprecated vendors don't test it as much as ESP - at interoperability tests it's not stressed, at least the ones I've been to. Ask your vendor(s) what they think of the work below and see where they stand with implementing it. Be happy to answer any more questions offline. - merike On May 25, 2009, at 6:24 AM, Jack Kohn wrote: Glen, IPSECME WG http://www.ietf.org/html.charters/ipsecme-charter.html at IETF is actually working on the exact issue that you have described (unable to deep inspect ESP-NULL packets). You can look at draft-ietf-ipsecme-traffic-visibility-02http://tools.ietf.org/html/ draft-ietf-ipsecme-traffic-visibility-02for more details. Jack On Sat, May 23, 2009 at 5:06 AM, Glen
