idnits 2.17.1 draft-bhatia-ipsecme-avoiding-ah-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 2, 2012) is 4497 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bhatia 3 Internet-Draft Alcatel-Lucent 4 Intended status: BCP January 2, 2012 5 Expires: July 5, 2012 7 Avoiding Authentication Header (AH) 8 draft-bhatia-ipsecme-avoiding-ah-00 10 Abstract 12 This document recommends retiring Authentication Header (AH) and 13 discusses the reasons for doing so. It recommends that AH must not 14 be used for new applications and protocols, since Encapsulating 15 Security Payload (ESP) using NULL encryption algorithm provides the 16 same level of security in most real deployments. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 5, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 1. Introduction 58 IPsec uses two protocols to provide traffic security services -- 59 Authentication Header (AH) and Encapsulating Security Payload (ESP). 60 Both protocols are described in detail in their respective RFCs 61 [RFC4302] [RFC4303] 63 [RFC4301] recommends IPsec implementations to MUST support ESP and 64 MAY support AH. Support for AH was downgraded to MAY because 65 experience has shown that there are very few contexts in which ESP 66 cannot provide the requisite security services. Note that ESP can be 67 used to provide only integrity, without confidentiality, making it 68 comparable to AH in most contexts. 70 AH offers integrity and data origin authentication, with optional (at 71 the discretion of the receiver) anti-replay features. ESP, on the 72 other hand, offers the same set of services, and also additionally 73 offers confidentiality. 75 These protocols may be applied individually or in combination with 76 each other to provide IPv4 and IPv6 security services. However, most 77 security requirements can be met through the use of ESP by itself. 78 Each protocol supports two modes of use: transport mode and tunnel 79 mode. In transport mode, AH and ESP provide protection primarily for 80 next layer protocols; in tunnel mode, AH and ESP are applied to 81 tunneled IP packets. [RFC4301] describes detailed differences 82 between these two modes. 84 There is no particular security problem with using AH. It lives up 85 to its security claims. Its just that its completely redundant with 86 ESP, since ESP will NULL encryption algorithm (ESP-NULL) [RFC2410] 87 can provide the same functionality and the world can do with one less 88 protocol. 90 Retiring AH doesn't mean that people have to stop using AH right now. 91 It only means that in the opinion of the community there are now 92 better alternatives. This will discourage new protocols to mandate 93 the use of AH. It however, does not preclude the possibility of new 94 work to IETF that will require or enhance AH. It just means that the 95 authors will have to explain why that solution is really needed and 96 the reason why ESP with NULL encryption algorithm cannot be used 97 instead. 99 2. AH and ESP 101 It is alleged that AH provides more security than ESP in the 102 transport mode as AH also authenticates the IP header fields. This 103 argument is however moot as ESP in the tunnel mode can provide the 104 same level of security since the payload now includes the original IP 105 header. It is also believed by many that securing the IP header isnt 106 really very important [Schneier]. 108 It is commonly believed that AH is quite useful in securing the IPv6 109 extension headers. AH protects most of the basic IPv6 header, the 110 non-mutable extension headers after the AH, and the IP payload. 111 Protection for the IPv6 header excludes the mutable fields: DSCP, 112 ECN, Flow Label, and Hop Limit. ESP, on the other hand, doesn't 113 protect the immutable parts of the IPv6 header nor those of any 114 extension header. This can however be fixed by putting the IPv6 115 extension headers that are required to be protected after the ESP 116 header. Hop-by-Hop options are not an issue, as the intermediate 117 hops do not have keys to verify the message authentication code so 118 they cannot really be protected anyways. 120 AH breaks Network Address Translators (NATs). This is because AH 121 relies on the sanctity of the IP header so that any tamperings, even 122 by a NAT, get detected and packets get discarded. Solving this issue 123 requires another device that fixes the NAT translation back to the 124 original one (a specific case of Double NAT). ESP, on the other 125 hand, fixes this problem by encapsulating ESP packets inside UDP 126 packets for traversing NATs [RFC3948]. 128 Firewalls in the enterprise environments often require visibility 129 into packets, ranging from simple packet header inspection to deeper 130 payload examination. Routers also often need to deep inspect control 131 traffic to prioritize certain protocol packets over the others. This 132 was initially difficult with ESP since was impossible to know whether 133 an ESP packet was integrity protected or encrypted by merely 134 inspecting the packet. This was easy with AH since the payload was 135 transmitted in clear. This problem however has been solved by 136 introducing WESP [RFC5840] which defines a mechanism to provide 137 additional information in relevant IPsec packets so intermediate 138 devices can efficiently differentiate between encrypted and 139 integrity-only ESP packets. 141 ESP with NULL encryption algorithm seems to do everything useful that 142 can be done with AH without the side effects of AH. Given this, it 143 makes sense to retire AH so that newer applications and protocols 144 dont mandate or propose extensions that rely on AH to be supported or 145 extended. 147 3. Security Considerations 149 Its argued that ESP in the tunnel mode is equivalent to the AH in the 150 transport mode. It should however be noted that ESP tunnel mode SA 151 applied to an IPv6 flow results in at least 50 bytes of additional 152 overhead per packet. This additional overhead may be undesirable for 153 many bandwidth-constrained wireless and/or satellite communications 154 networks, as these types of infrastructure are not overprovisioned. 156 Packet overhead is particularly significant for traffic profiles 157 characterized by small packet payloads (e.g., various voice codecs). 158 If these small packets are afforded the security services of an IPsec 159 tunnel mode SA, the amount of per-packet overhead is increased. 161 This issue will perhaps be alleviated by header compression schemes 162 defined in [RFC5856] [RFC5857] and [RFC5858]. 164 4. IANA Considerations 166 This document includes no request to IANA. 168 5. References 170 5.1. Normative References 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, March 1997. 175 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 176 Its Use With IPsec", RFC 2410, November 1998. 178 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 179 Internet Protocol", RFC 4301, December 2005. 181 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 182 December 2005. 184 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 185 RFC 4303, December 2005. 187 5.2. Informative References 189 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 190 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 191 RFC 3948, January 2005. 193 [RFC5840] Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped 194 Encapsulating Security Payload (ESP) for Traffic 195 Visibility", RFC 5840, April 2010. 197 [RFC5856] Ertekin, E., Jasani, R., Christou, C., and C. Bormann, 198 "Integration of Robust Header Compression over IPsec 199 Security Associations", RFC 5856, May 2010. 201 [RFC5857] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. 202 Bormann, "IKEv2 Extensions to Support Robust Header 203 Compression over IPsec", RFC 5857, May 2010. 205 [RFC5858] Ertekin, E., Christou, C., and C. Bormann, "IPsec 206 Extensions to Support Robust Header Compression over 207 IPsec", RFC 5858, May 2010. 209 [Schneier] 210 Ferguson, N. and B. Schneier, "A Cryptographic Evaluation 211 of IPsec", December 2003, 212 . 214 Author's Address 216 Manav Bhatia 217 Alcatel-Lucent 219 Email: manav.bhatia@alcatel-lucent.com