idnits 2.17.1 draft-bhatia-ipsecme-esp-null-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 234. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 258. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4303]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document date (December 2008) is 5583 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 informational reference (is this intentional?): RFC 4835 (Obsoleted by RFC 7321) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Identifying ESP-NULL Packets December 2008 3 Network Working Group Manav Bhatia 4 Internet Draft Alcatel-Lucent 5 Intended Status: Proposed Standard 6 Expires: May 2009 8 Identifying ESP-NULL Packets 10 draft-bhatia-ipsecme-esp-null-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 2009. 37 Abstract 39 Encapsulating Security Payload (ESP) [RFC4303] provides data 40 integrity protection, confidentiality and data origin authentication 41 for data transported in an IP packet. 43 There are various applications and protocols that do not require 44 confidentiality but only need data integrity assurance or data origin 45 authentication. Since ESP support is mandatory for IPSec, such 46 applications end up using ESP with NULL encryption. 48 However, because of the way ESP is defined, it is impossible for 49 firewalls and intermediate routers to differentiate between encrypted 50 ESP and ESP NULL packets by simply examining them. This poses 51 problems for the firewalls since such packets cannot be filtered and 52 identified. It poses a different set of problems for routers since 53 such packets cannot be properly filtered, classified and prioritized. 55 This document proposes an extension to ESP so that firewalls and 56 routers can disambiguate between ESP encrypted and ESP NULL encrypted 57 packets. 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 1. Introduction 67 ESP-NULL is used when confidentiality is not required and only source 68 authentication and data integrity assurance is desired. 70 IPSec mandates the use of ESP while keeps support for Authentication 71 Header (AH) [RFC4302] as optional. Thus, new protocols using IPSec 72 for data integrity also mandate the use of ESP-NULL. It is also 73 mandatory [RFC4835] for all ESP implementations to provide support 74 for ESP NULL encryption. Because of these factors a lot of vendors do 75 not implement AH and only support ESP-NULL for data integrity and 76 source authentication. The traffic using ESP-NULL is thus only going 77 to increase with time. 79 Firewalls and intermediate routers in the network find it impossible 80 to parse ESP packets since they have no idea whether the packet is 81 encrypted or not. They cannot for this reason implement filters and 82 access control lists (ACLs). 84 ACLs are highly desirable and used extensively by service providers 85 to block undesired traffic coming from other domains. 87 This draft therefore proposes an extension to ESP with which 88 identifying an ESP-NULL packet from an ESP encrypted packet becomes 89 trivial. It is backward compatible, therefore devices that do not 90 understand this extension would treat packets using this extension as 91 normal ESP packets. 93 The extension described in this draft is applicable for both the 94 tunnel and the transport modes of ESP. 96 2. Explicitly Marking ESP NULL Packets 98 ESP-NULL packets, for both implementations based on [RFC2410] and 99 [RFC4543] MUST be sent with a well known, reserved SPI of 1. The 100 original SPI should be included as part of the payload. This is 101 encoded in the first 4 octets of the payload section of the ESP 102 header. An implementation MUST put the next-header and the ESP header 103 th th 104 length as the 4 and the 5 octets of the payload. 106 Since the packet is not encrypted these fields would be sent in clear 107 text and would be visible to all. 109 An extended ESP packet using NULL encryption would thus look like 110 this: 112 0 1 2 3 113 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Reserved Security Parameters Index (RSPI) = 1 | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | Sequence Number | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Original Security Parameters Index (SPI) | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | next-header | eESP HDRLen | | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 123 | Payload Data* (variable) | 124 ~ ~ 125 | | 126 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | | Padding (0-255 bytes) | 128 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | | Pad Length | Next Header | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Authentication Data (variable) | 132 ~ ~ 133 | | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Figure 1 138 Reserved Security Parameters Index (RSPI): Well known value that 139 should be given by IANA to indicate that it is an ESP-NULL packet. 141 next-header: This is a one octet field that indicates the next 142 protocol header. Explicitly mentioning this provides an easy access 143 to a HW parser to extract the upper layer protocol. 145 eESP HDRLen: This is a one octet field that gives the length of the 146 extended ESP header + IV (if mandated by the authentication 147 algorithm). It is an offset to the beginning of the payload data. 149 Intermediate nodes (routers, firewalls, etc) interested in inspecting 150 the packets en route can look at the SPI value at the start of the 151 ESP header. If there are unaware of this extension then this packet 152 would appear like a normal ESP packet. However, compliant 153 implementations will understand that this is an extended ESP packet 154 and would have enough information to be able to deep inspect the ESP- 155 NULL packet. 157 The compliant end nodes (routers) can similarly parse the packet 158 easily. If the SPI value is 1, then it can extract the original SPI 159 from the payload and process the packet accordingly. 161 3. Authenticating the Packets 163 All fields of the extended ESP header starting with the RSPI and 164 ending with the Next Header in the ESP trailer are included in the 165 ESP data integrity check. 167 The authentication data field is used to hold the result of the data 168 integrity check done on the ESP packet. The length of this field 169 depends on the authentication algorithm employed by the Security 170 Association (SA) used to process this packet. 172 4. Acknowledgements 174 The author would like to thank Jack Kohn for his useful comments. 176 5. IANA Considerations 178 IANA must assign a value that for Reserved SPI which will be used as 179 described above. The draft uses a value 1 to foster pre-standard 180 implementations. 182 6. Security Considerations 184 This proposal neither increases nor decreases the security for ESP. 185 All considerations valid for ESP also apply here. 187 7. References 189 7.1 Normative References 191 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 192 RFC 4303, December 2005. 194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 195 Requirement Levels", RFC 2119, BCP 14, February 2001. 197 [RFC2410] Glenn, R., and Kent, S., "The NULL Encryption Algorithm and 198 its Use With IPsec", RFC 2410, November 1998. 200 [RFC4543] McGrew, D. and Viega, J., "The Use of Galois Message 201 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 202 May 2006. 204 7.2 Informative References 206 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 207 December 2005. 209 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 210 Requirements for Encapsulating Security Payload (ESP) and 211 Authentication Header (AH)", RFC 4835, APRIL 2007. 213 8. Author's Addresses 215 Manav Bhatia 216 Alcatel-Lucent, 217 Bangalore, India 218 Email: manav@alcatel-lucent.com 220 Full Copyright Statement 222 Copyright (C) The IETF Trust (2008). 224 This document is subject to the rights, licenses and restrictions 225 contained in BCP 78, and except as set forth therein, the authors 226 retain all their rights. 228 This document and the information contained herein are provided on an 229 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 230 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 231 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 232 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 233 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 234 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 236 Intellectual Property 238 The IETF takes no position regarding the validity or scope of any 239 Intellectual Property Rights or other rights that might be claimed 240 to pertain to the implementation or use of the technology described 241 in this document or the extent to which any license under such rights 242 might or might not be available; nor does it represent that it has 243 made any independent effort to identify any such rights. Information 244 on the procedures with respect to rights in RFC documents can be 245 found in BCP 78 and BCP 79. 247 Copies of IPR disclosures made to the IETF Secretariat and any 248 assurances of licenses to be made available, or the result of an 249 attempt made to obtain a general license or permission for the use 250 of such proprietary rights by implementers or users of this 251 specification can be obtained from the IETF on-line IPR repository 252 at http://www.ietf.org/ipr. 254 The IETF invites any interested party to bring to its attention any 255 copyrights, patents or patent applications, or other proprietary 256 rights that may cover technology that may be required to implement 257 this standard. Please address the information to the IETF at ietf- 258 ipr@ietf.org.