idnits 2.17.1 draft-hoffman-esp-null-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 247. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 271. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 24, 2007) is 6090 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4835 (Obsoleted by RFC 7321) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Expires: February 25, 2008 D. McGrew 5 Cisco Systems 6 August 24, 2007 8 An Authentication-only Profile for ESP with an IP Protocol Identifier 9 draft-hoffman-esp-null-protocol-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 25, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 It is desirable to allow firewalls and intrusion detection systems to 43 be able to inspect the payload of an ESP packet that has been 44 encrypted with the NULL cipher. This would allow a firewall to read 45 the contents and apply the normal policies to it. However, a device 46 in the network cannot reliably determine which ESP packets are NULL 47 encrypted, and cannot easily determine other ESP format parameters 48 such as the ICV length. These issues can cause misclassification of 49 packets and wasted computational resources. 51 This document solves this problem by defining an authentication-only 52 profile of ESP and reserving IP protocol numbers for it. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Using New IP Protocol Numbers . . . . . . . . . . . . . . . . . 4 58 2.1. Marking ESP NULL Packets . . . . . . . . . . . . . . . . . 4 59 2.2. Negotiating ESP NULL in IKE . . . . . . . . . . . . . . . . 4 60 2.3. Firewalls and the New Protocol Numbers . . . . . . . . . . 5 61 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 63 5. Normative References . . . . . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 65 Intellectual Property and Copyright Statements . . . . . . . . . . 7 67 1. Introduction 69 The ESP protocol can be used with NULL encryption to provide 70 authentication and integrity protection, but not confidentiality. 71 This use of ESP is beneficial when access control and integrity are 72 needed, but confidentiality is not. A good example is the case in 73 which it is desirable to use authentication and integrity protection 74 to prevent the spread of worms, or to prevent unauthorized access to 75 network resources. In these scenarios, one of the benefits of 76 authentication-only ESP is that devices in the network can inspect 77 the ESP-protected traffic to help them meet their security goals. 79 Unfortunately, the ESP packet format cannot be unambiguously parsed 80 except by the sender and receiver(s). Heuristic methods to parse ESP 81 packets can be used, but these methods are not robust and they fail 82 when their assumptions about ESP parameters and algorithms are wrong. 84 When using IPsec [RFC4301] for integrity but not encryption, a system 85 administrator needs to decide whether to use AH [RFC4302], or to use 86 ESP [RFC4303] with NULL encryption. The ability for systems that do 87 ESP to support NULL encryption is mandated by [RFC4835]. Many IPsec 88 system vendors do not support AH, making ESP with NULL encryption the 89 natural choice for interoperable IPsec that provides only integrity. 91 Many firewalls can inspect the contents of the packets they process; 92 such firewalls are often called "content-inspecting firewalls" or 93 CIFs. CIFs often allow the firewall administrator to set policies 94 such as "do not allow packets that cannot be inspected". Packets 95 whose contents are encrypted (where the encryption is not performed 96 by the firewall itself) would fall into that category. 98 A CIF can inspect the contents of every packet, but if some of the 99 packets are known to be encrypted ESP packets, such inspection is 100 wasteful. On the other hand, because ESP with NULL encryption is 101 allowed, a CIF might need to inspect the content of every ESP packet 102 in case it is encrypted with NULL encryption. 104 Some firewalls are also used for access control. Like CIFs, these 105 ACL-enforcing firewalls sometimes also need to inspect the contents 106 of packets when enforcing some access rules. Firewalls that act as 107 intrusion detection systems and intrusion prevention systems (IDS/ 108 IPS) also often need to inspect packet contents, and thus have the 109 same problems as CIFs when handling ESP traffic with NULL encryption. 111 This document defines a way to mark ESP packets as being encrypted 112 with NULL encryption so that a firewall can know that it should 113 inspect the contents. The marking is done with new IP protocol 114 numbers. This document does not mandate such marking. Because the 115 marking is not mandated, the firewall may still want to inspect ESP 116 packets that are not marked. However, by marking the ESP packets 117 that are sure to use NULL encryption, it frees resources in the 118 firewall. Using this marking method allows full interoperability 119 with unchanged IKE v1 and IKE v2 implementations. 121 [[NOTE: the values TBD1 and TBD2 throughout this document need to be 122 changed with the values are assigned by IANA.]] 124 2. Using New IP Protocol Numbers 126 2.1. Marking ESP NULL Packets 128 There are multiple ways to use NULL encryption in ESP. The method 129 described in [RFC2410] causes the content of the ESP packet to appear 130 just as it did in the plaintext message. The method described in 131 [RFC4543] prepends an eight-octet initialization vector (IV) to the 132 beginning of the content of every ESP packet. In order to enable 133 unambiguous parsing of ESP packets, each profile fixes the length of 134 the Integrity Check Value (ICV) and Initialization Vector (IV). 136 An ESP implementation that uses NULL encryption based on RFC 2410 may 137 mark a packet with IP protocol number TBD1 instead of the normal 138 protocol number of 50 that was assigned by IANA for ESP. The length 139 of the IV is zero, and the length of the ICV is zero. [[ NOTE FOR 140 FUTURE DRAFT: determine what ICV length is commonly deployed here. ]] 142 An ESP implementation that uses NULL encryption based on RFC 4543 may 143 mark a packet with IP protocol number TBD2 instead of the normal 144 protocol number of 50 that was assigned by IANA for ESP. The length 145 of the IV is 8 octets, and the length of the ICV is 16 octets. 147 Future ESP authentication methods that do not change the plaintext 148 message before putting it in the content can also use IP protocol 149 TBD1. Similarly, future ESP ESP authentication methods that add 150 exactly eight octets to the beginning of the content but leaves the 151 rest of the plaintext alone can also use IP protocol TBD2. 153 2.2. Negotiating ESP NULL in IKE 155 When initiating IKE (either v1 or v2), the initiator can include two 156 proposed transforms: one with the new IP protocol number, and one 157 with IP protocol 50 (ESP). If the responder understands the new 158 protocol numbers, it can accept and use them in the resulting ESP 159 traffic; otherwise, the responder can still accept the older protocol 160 numbers and use 50 as the protocol number. 162 2.3. Firewalls and the New Protocol Numbers 164 A firewall that sees one of the new protocol numbers can be assured 165 that it can inspect the content of the ESP packets. In specific, a 166 firewall that sees a packet with IP protocol number TBD1 can reliably 167 determine the starting point and the length of the plaintext, and a 168 packet with IP protocol number TBD2 has eight octets of IV (that the 169 firewall can ignore) and then the plaintext. 171 A possible downside to adopting this marking method is that firewalls 172 that block unknown IP protocols will need to be updated to handle IP 173 protocol numbers TBD1 and TBD2. Fortunately, many (possibly most) 174 firewalls allow such updating as policy settings by the firewall's 175 administrator; such firewalls would not need a firmware update. 177 3. IANA Considerations 179 IANA is requested to assign the following from the "Protocol Numbers" 180 registry: 182 TBD1 ESP-AUTH-ONLY-NO-IV [This document] 183 TBD2 ESP-AUTH-ONLY-8-OCTET-IV [This document] 185 4. Security Considerations 187 An attacker who can modify packets between the originator and a 188 firewall that understands the new protocol numbers can change the 189 protocol number on encrypted ESP packets from 50 to either of the new 190 values. If the firewall is a CIF, this might cause the firewall to 191 spend more resources than it would on unaltered packets. 193 5. Normative References 195 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 196 Its Use With IPsec", RFC 2410, November 1998. 198 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 199 Internet Protocol", RFC 4301, December 2005. 201 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 202 December 2005. 204 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 205 RFC 4303, December 2005. 207 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 208 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 209 May 2006. 211 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 212 Requirements for Encapsulating Security Payload (ESP) and 213 Authentication Header (AH)", RFC 4835, April 2007. 215 Authors' Addresses 217 Paul Hoffman 218 VPN Consortium 219 127 Segre Place 220 Santa Cruz, CA 95060 221 US 223 Phone: 1-831-426-9827 224 Email: paul.hoffman@vpnc.org 226 David McGrew 227 Cisco Systems 228 San Jose, CA 95134 229 US 231 Email: mcgrew@cisco.com 233 Full Copyright Statement 235 Copyright (C) The IETF Trust (2007). 237 This document is subject to the rights, licenses and restrictions 238 contained in BCP 78, and except as set forth therein, the authors 239 retain all their rights. 241 This document and the information contained herein are provided on an 242 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 243 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 244 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 245 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 246 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 247 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 249 Intellectual Property 251 The IETF takes no position regarding the validity or scope of any 252 Intellectual Property Rights or other rights that might be claimed to 253 pertain to the implementation or use of the technology described in 254 this document or the extent to which any license under such rights 255 might or might not be available; nor does it represent that it has 256 made any independent effort to identify any such rights. Information 257 on the procedures with respect to rights in RFC documents can be 258 found in BCP 78 and BCP 79. 260 Copies of IPR disclosures made to the IETF Secretariat and any 261 assurances of licenses to be made available, or the result of an 262 attempt made to obtain a general license or permission for the use of 263 such proprietary rights by implementers or users of this 264 specification can be obtained from the IETF on-line IPR repository at 265 http://www.ietf.org/ipr. 267 The IETF invites any interested party to bring to its attention any 268 copyrights, patents or patent applications, or other proprietary 269 rights that may cover technology that may be required to implement 270 this standard. Please address the information to the IETF at 271 ietf-ipr@ietf.org. 273 Acknowledgment 275 Funding for the RFC Editor function is provided by the IETF 276 Administrative Support Activity (IASA).