Another document from NIST - Profile for IPv6 in the US Government [1], lists AH as optional and ESP as mandatory.
It however says that if devices want to differentiate ESP NULL with ESP encrypted traffic then they must use AH till the IPSecME WG comes up with a mature standard that can easily do this. It says that if it produces a mature RFC then the profile will be updated to recommend its use. The version i have with me was published prior to WESP's publication. http://www.antd.nist.gov/usgv6/usgv6-v1.pdf Sriram [1] This document is meant to assist Federal agencies in formulating plans for the acquisition of IPv6 technologies. On Wed, Jan 4, 2012 at 7:42 PM, Bhatia, Manav (Manav) <[email protected]> wrote: > NIST has published the "Guidelines for secure deployment of IPv6" and it > unequivocally says that AH has fallen out for ESP-NULL. > > One can go through the document in detail. I have not gone through the entire > document but here are some excerpts from that document: > > (1) It says the following for OSPFv3: > > "With routing protocols, routing integrity is usually a greater concern than > confidentiality. The ESP > parameter NULL indicating no encryption is generally regarded to be an > acceptable choice for OSPF > security." > > (2) 4.2.4 Unresolved Aspects of IPv6 Multicast > > "The security recommendations for PIM call for using IPsec AH, even for > unicast messages. Where IPsec > is used with IPv4, AH has generally fallen out of use in favor of ESP, with > NULL encryption when > authentication-only is desired. Thus the IPsec standard (RFC 4301) no longer > requires AH, and many > implementations omit it. See Section 5.3.6 for additional discussion of this > topic." > > (3) 5.3.1 Specification Overview > > "Two security protocols: Authentication Header (AH) and Encapsulating Security > Payload (ESP). AH can provide integrity and replay protection for packet > headers and data, > but it cannot encrypt them. ESP can provide encryption, integrity, and > replay protection for > packets, but it cannot protect the outermost IP header, as AH can. This > protection is not > needed in most cases. Accordingly, ESP is used much more frequently than AH > because of its > encryption capabilities, as well as other operational advantages. The latest > IPsec specification > states that implementations MAY implement AH, and many choose not to. For a > VPN, which > requires confidential communications, ESP is the natural choice." > > And the below is the most interesting: > > (4) 5.3.6 Unknown Aspects > > "A debate exists over whether to use AH or ESP with NULL encryption for IPsec > packets requiring > integrity protection but not confidentiality. The standards themselves do > not answer the question: IPv6 > standards tend to recommend or require AH, whereas IPsec standards have > downgraded AH from MUST > implement to MAY implement. OSPFv3 originally specified AH, but this has > been changed to ESPNULL. > Some implementations only provide ESP. AH has not been widely deployed. > (The common > IPv4 applications of IPsec-VPNs and secure remote access-usually provide > confidentiality, so this > question does not arise.) AH may also require more processing steps to > compute or verify the integrity > check value. On the other hand, one of the main arguments in favor of AH is > that it makes it easier for > devices such as packet filtering routers, firewalls, and intrusion detection > systems to recognize plaintext > and examine packets (because ESP-NULL transmits plaintext but gives no > visible indication that the > payload is unencrypted). As far as the cryptographic protection provided by > AH versus ESP, it is difficult > to discern any tangible difference when IPsec is used as intended. In some > cases, AH may protect certain > vulnerable parts of the header or extension headers, but these cases are > rare, and in these few cases, > ESPNULL can achieve the same effect by being run in tunnel mode." > > (5) 5.4.1 Using IPsec to Secure Autoconfiguration and ND > > "AH was downgraded to MAY in RFC 4301 and is not included in many > implementations." > > Cheers, Manav > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
