idnits 2.17.1 draft-ietf-ipsecme-esp-null-heuristics-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1252 has weird spacing: '...lure if it is...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 3, 2009) is 5321 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-ipsecme-traffic-visibility-08 -- Obsolete informational reference (is this intentional?): RFC 4835 (Obsoleted by RFC 7321) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Security Maintenance and T. Kivinen 3 Extensions (ipsecme) Safenet, Inc. 4 Internet-Draft D. McDonald 5 Intended status: Informational Sun Microsystems, Inc. 6 Expires: March 7, 2010 September 3, 2009 8 Heuristics for Detecting ESP-NULL packets 9 draft-ietf-ipsecme-esp-null-heuristics-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 7, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document describes a heuristic approach for distinguishing ESP- 48 NULL (Encapsulating Security Payload without encryption) packets from 49 encrypted ESP packets. The reason for using heuristics instead of 50 modifying ESP is to provide a solution that can be used now without 51 updating all end nodes. With heuristic methods, only the 52 intermediate devices wanting to find ESP-NULL packets need to be 53 updated. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Applicability: Heuristic Traffic Inspection and 59 Wrapped ESP . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 4 61 2. Other Options . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. Mandating by Policy . . . . . . . . . . . . . . . . . . . 5 64 2.3. Modifying ESP . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Description of Heuristics . . . . . . . . . . . . . . . . . . 7 66 4. IPsec flows . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5. Deep Inspection Engine . . . . . . . . . . . . . . . . . . . . 10 68 6. Special and Error Cases . . . . . . . . . . . . . . . . . . . 11 69 7. UDP encapsulation . . . . . . . . . . . . . . . . . . . . . . 12 70 8. Heuristic Checks . . . . . . . . . . . . . . . . . . . . . . . 13 71 8.1. ESP-NULL format . . . . . . . . . . . . . . . . . . . . . 13 72 8.2. Self Describing Padding Check . . . . . . . . . . . . . . 14 73 8.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 16 74 8.3.1. TCP checks . . . . . . . . . . . . . . . . . . . . . . 17 75 8.3.2. UDP checks . . . . . . . . . . . . . . . . . . . . . . 17 76 8.3.3. ICMP checks . . . . . . . . . . . . . . . . . . . . . 18 77 8.3.4. SCTP checks . . . . . . . . . . . . . . . . . . . . . 18 78 8.3.5. IPv4 and IPv6 Tunnel checks . . . . . . . . . . . . . 18 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 83 Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 21 84 A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 88 1. Introduction 90 The ESP (Encapsulated Security Payload [RFC4303]) protocol can be 91 used with NULL encryption [RFC2410] to provide authentication and 92 integrity protection, but not confidentiality. This offers similar 93 properties to IPsec's AH (Authentication Header [RFC4302]). The 94 reason to use ESP-NULL instead of AH is that AH cannot be used if 95 there are NATs (Network Address Translation devices) on the path. 96 With AH it would be easy to detect packets which have only 97 authentication and integrity protection, as AH has its own protocol 98 number and deterministic packet length. With ESP-NULL such detection 99 is nondeterministic, in spite of the base ESP packet format being 100 fixed. 102 In some cases intermediate devices would like to detect ESP-NULL 103 packets so they could perform deep inspection or enforce access 104 control. This kind of deep inspection includes virus detection, spam 105 filtering, and intrusion detection. As end nodes might be able to 106 bypass those checks by using encrypted ESP instead of ESP-NULL, these 107 kinds of scenarios also require very specific policies to forbid such 108 circumvention. 110 These sorts of policy requirements usually mean that the whole 111 network needs to be controlled, i.e. under the same adminstrative 112 domain. Such setups are usually limited to inside the network of one 113 enterprise or organization, and encryption is not used as the network 114 is considered safe enough from eavesdroppers. 116 Because the traffic inspected is usually host to host traffic inside 117 one organization, that usually means transport mode IPsec is used. 119 It should also be noted that even if new protocol modifications for 120 ESP support easier detection of ESP-NULL in the future, this document 121 will aid in transition of older end-systems. That way, a solution 122 can be implemented immediately, and not after a 5-10 year upgrade- 123 and-deployment time frame. Even with protocol modification for end 124 nodes, the intermediate devices will need heuristics until they can 125 assume that those protocol modifications can be found from all the 126 end devices. To make sure that any solution does not break in the 127 future it would be best if such heuristics are documented, i.e. we 128 need to publish an RFC for what to do now even when there might be a 129 new protocol coming in the future that will solve the same problem 130 better. 132 1.1. Applicability: Heuristic Traffic Inspection and Wrapped ESP 134 There are two ways to enable intermediate security devices to 135 distinguish between encrypted and unencrypted ESP traffic: 137 - The heuristics approach has the intermediate node inspect the 138 unchanged ESP traffic, to determine with extremely high 139 probability whether or not the traffic stream is encrypted. 141 - The Wrapped ESP approach [I-D.ietf-ipsecme-traffic-visibility], 142 in contrast, requires the ESP endpoints to be modified to support 143 the new protocol. WESP allows the intermediate node to 144 distinguish encrypted and unencrypted traffic deterministically, 145 using a simpler implementation for the intermediate node. 147 Both approaches are being documented simultaneously by the IPsecME 148 Working Group, with WESP being put on Standards Track while the 149 heuristics approach is being published as an Informational RFC. 150 While endpoints are being modified to adopt WESP, we expect both 151 approaches to coexist for years, because the heuristic approach is 152 needed to inspect traffic where at least one of the endpoints has not 153 been modified. In other words, intermediate nodes are expected to 154 support both approaches in order to achieve good security and 155 performance during the transition period. 157 1.2. Requirements notation 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 2. Other Options 165 This document will discuss the heuristic approach of detecting ESP- 166 NULL packets. There are some other options which can be used, and 167 this section will briefly discuss those. 169 2.1. AH 171 The most logical approach would use the already defined protocol 172 which offers authentication and integrity protection, but not 173 confidentiality, namely AH. AH traffic is clearly marked as not 174 encrypted, and can always be inspected by intermediate devices. 176 Using AH has two problems. First is that, as it also protects the IP 177 headers, it will also protect against NATs on the path, thus it will 178 not work if there is NAT on the path between end nodes. In some 179 environments this might not be a problem, but some environments 180 include heavy use of NATs even inside the internal network of the 181 enterprise or organization. NAT-Traversal (NAT-T, [RFC3948]) could 182 be extended to support AH also, and the early versions of the NAT-T 183 proposals did include that, but it was left out as it was not seen as 184 necessary. 186 The another problem is that in the new IPsec Architecture [RFC4301] 187 the support for AH is now optional, meaning not all implementations 188 support it. ESP-NULL has been defined to be mandatory to implement 189 by Cryptographic Algorithm Implementation Requirements for 190 Encapsulating Security Payload (ESP) [RFC4835]. 192 AH has also quite complex processing rules compared to ESP when 193 calculating the ICV, including things like zeroing out mutable 194 fields. As AH is not as widely used than ESP, the AH support is not 195 as well tested in the interoperability events, meaning it might have 196 more bugs than ESP implementations. 198 2.2. Mandating by Policy 200 Another easy way to solve this problem is to mandate the use of ESP- 201 NULL with common parameters within an entire organization. This 202 either removes the need for heuristics (if no ESP encrypted traffic 203 is allowed at all) or simplifies them considerably (only one set of 204 parameters needs to be inspected, e.g. everybody in the organization 205 who is using ESP-NULL must use HMAC-SHA-1-96 as their integrity 206 algorithm). This does not work if the machines are not under the 207 same administrative domain. Also, such a solution might require some 208 kind of centralized policy management to make sure everybody uses the 209 same policy. 211 2.3. Modifying ESP 213 Several internet drafts discuss ways of modifying ESP to offer 214 intermediate devices information about an ESP packet's use of NULL 215 encryption. The following methods have been discussed: adding an IP- 216 option, adding a new IP-protocol number plus an extra header 217 [I-D.ietf-ipsecme-traffic-visibility], adding a new IP-protocol 218 numbers which tell the ESP-NULL parameters 219 [I-D.hoffman-esp-null-protocol], reserving an SPI range for ESP-NULL 220 [I-D.bhatia-ipsecme-esp-null], and using UDP encapsulation with a 221 different format and ports. 223 All of the aforementioned drafts require modification to ESP, which 224 requires that all end nodes needs to be modified before intermediate 225 devices can assume that this new ESP format is in use. Updating end 226 nodes will require lots of time. An example of the slowness of 227 endpoint migration vs. intermediate migration can be seen from the 228 IPv6 vs NAT case. IPv6 required updating all of the end nodes (and 229 routers too) before it could be effectively used. This has taken a 230 very long time, and IPv6 deployment is not yet widespread. NAT, on 231 the other hand, only required modifying an existing intermediate 232 device or adding a new one, and has spread out much faster. Another 233 example of slow end-node deployment is IKEv2. Considering an 234 implementation that requires both IKEv2 and a new ESP format, it 235 would take several years, possibly as long as a decade, before 236 widespread deployment. 238 3. Description of Heuristics 240 The heuristics to detect ESP-NULL packets will only require changes 241 to the those intermediate devices which do deep inspection or other 242 operations which require detecting ESP-NULL. As those nodes require 243 changes regardless of any ESP-NULL method, updating intermediate 244 nodes is unavoidable. Heuristics do not require updating or 245 modifying any other devices on the rest of the network, including 246 (and especially) end-nodes. 248 In this document it is assumed that an affected intermediate node 249 will act as a stateful interception device, meaning it will keep 250 state of the flows - where flows are defined by the ESP SPI and IP 251 addresses forming an IPsec SA - going through it. The heuristics can 252 also be used without storing any state, but performance will be worse 253 in that case, as heuristic checks will need to be done for each 254 packet, not only once per flow. This will also affect the 255 reliability of the heuristics. 257 Generally, an intermediate node runs heuristics only for the first 258 few packets of the new flow (i.e. the new IPsec SA). After those few 259 packets, the node detects parameters of the IPsec flow, it skips 260 detection heuristics, and it can perform direct packet-inspecting 261 action based on its own policy. Once detected, ESP-NULL packets will 262 never be detected as encrypted ESP packets, meaning that valid ESP- 263 NULL packets will never bypass the deep inspection. The only failure 264 mode of these heuristics is to assume encrypted ESP packets are ESP- 265 NULL packet, thus causing completely random packet data to be deeply 266 inspected. An attacker can easily send random-looking ESP-NULL 267 packets which will cause heuristics to detect packets as encrypted 268 ESP, but that is no worse than sending non-ESP fuzz through an 269 intermediate node. 271 For hardware implementations all the flow lookup based on the ESP 272 next header number (50), source address, destination address, and SPI 273 can be done by the hardware (there is usually already similar 274 functionality there, for TCP/UDP flows). The heuristics can be 275 implemented by the hardware, but using software will allow faster 276 updates when new protocol modifications come out or new protocols 277 need support. 279 4. IPsec flows 281 ESP is a stateful protocol, meaning there is state stored in the both 282 end nodes of the ESP IPsec SA, and the state is identified by the 283 pair of destination IP and SPI. End nodes also often fix the source 284 IP address in an SA unless the destination is a multicast group. As 285 most (if not all) flows of interest to an intermediate device are 286 unicast, it is safer to assume the receiving node also uses a source 287 address, and the intermediate device should do the same. In some 288 cases this might cause extraneous cached ESP IPsec SA flows, but by 289 using the source address two distinct flows will never be mixed. 291 When the intermediate device sees an new ESP IPsec flow, i.e. a flow 292 of ESP packets where the source address, destination address, and SPI 293 number forms a triplet which has not been cached, it will start the 294 heuristics to detect whether this flow is ESP-NULL or not. These 295 heuristics appear in the Section 8. 297 When the heuristics finish, they will label the flow as either 298 encrypted (which tells that packets in this flow are encrypted, and 299 cannot be ESP-NULL packets) or as ESP-NULL. This information, along 300 with the ESP-NULL parameters detected by the heuristics, is stored to 301 a flow cache, which will be used in the future when processing 302 packets of the same flow. 304 Both encrypted ESP and ESP-NULL flows are processed based on the 305 local policy. In normal operation encrypted ESP flows are passed 306 through or dropped per local policy, and ESP-NULL flows are passed to 307 the deep inspection engine. Local policy will also be used to 308 determine other packet-processing parameters. Local policy issues 309 will be clearly marked in this document to ease implementation. 311 In some cases the heuristics cannot determine the type of flow from a 312 single packet, and in that case it might need multiple packets before 313 it can finish the process. In those cases the heuristics return 314 "unsure" status. In that case the packet processed based on the 315 local policy and flow cache is updated with "unsure" status. Local 316 policy for "unsure" packets could range from dropping (which 317 encourages end-node retransmission) to queuing (which may preserve 318 delivery, at the cost of artificially inflating round-trip times if 319 they are measured). When the next packet to the flow arrives, it is 320 heuristically processed again, and the cached flow may continue to be 321 "unsure", marked as ESP, or marked as an ESP-NULL flow. 323 There are several reasons why a single packet might not be enough to 324 detect type of flow. One of them is that the next header number was 325 unknown, i.e. if heuristics do not know about the protocol for the 326 packet, it cannot verify it has properly detected ESP-NULL 327 parameters, even when the packet otherwise looks like ESP-NULL. If 328 the packet does not look like ESP-NULL at all, then encrypted ESP 329 status can be returned quickly. As ESP-NULL heuristics should know 330 the same protocols as a deep inspection device, an unknown protocol 331 should not be handled any differently than a cleartext instance of an 332 unknown protocol if possible. 334 5. Deep Inspection Engine 336 A deep inspection engine running on an intermediate node usually 337 checks deeply into the packet and performs policy decisions based on 338 the contents of the packet. The deep inspection engine should be 339 able to tell the difference between success, failure, and garbage. 340 Success means that a packet was successfully checked with the deep 341 inspection engine, and it passed the checks and is allowed to be 342 forwarded. Failure means that a packet was successfully checked but 343 the actual checks done indicated that packets should be dropped, i.e. 344 the packet contained a virus, was a known attack, or something 345 similar. 347 Garbage means that the packet's protocol headers or other portions 348 were unparseable. For the heuristics, it would be useful if the deep 349 inspection engine can differentiate the garbage and failure cases, as 350 garbage cases can be used to detect certain error cases (e.g. where 351 the ESP-NULL parameters are incorrect, or the flow is really an 352 encrypted ESP flow, not an ESP-NULL flow). 354 If the deep inspection engine will only return failure for all 355 garbage packets in addition to real failure cases, then a system 356 implementing the ESP-NULL heuristics cannot recover from error 357 situations quickly. 359 6. Special and Error Cases 361 There is a small probability that an encrypted ESP packet (which 362 looks like contain completely random bytes) will have correct bytes 363 in correct locations, such that heuristics will detect the packet as 364 an ESP-NULL packet instead of detecting that it is encrypted ESP 365 packet. The actual probabilities will be computed later in this 366 document. Such a packet will not cause problems, as the deep 367 inspection engine will most likely reject the packet and return that 368 it is garbage. If the deep inspection engine is rejecting a high 369 number of packets as garbage, it might indicate an original ESP-NULL 370 detection for the flow was wrong (i.e. an encrypted ESP flow was 371 improperly detected as ESP-NULL). In that case, the cached flow 372 should be invalidated and discovery should happen again. 374 Each ESP-NULL flow should also keep statistics about how many packets 375 have been detected as garbage by deep inspection, how many have 376 passed checks, or how many have failed checks with policy violations 377 (i.e. failed because actual inspection policy failures, not because 378 the packet looked like garbage). If the number of garbage packets 379 suddenly increases (e.g. most of the packets start to be look like 380 garbage according to the deep inspection engine), it is possible the 381 old ESP-NULL SA was replaced by an identical-SPI encrypting ESP SA. 382 If both ends use random SPI generation, this is a very unlikely 383 situation (1 in 2^32), but it is possible that some nodes reuse SPI 384 numbers (e.g. a 32-bit memory address of the SA descriptor), thus 385 this situation needs to be handled. 387 Actual limits for cache invalidation are local policy decisions. 388 Sample invalidation policies include: 50% of packets marked as 389 garbage within a second; or if a deep inspection engine cannot 390 differentiate between garbage and failure, failing more than 95% of 391 packets in last 10 seconds. For implementations that do not 392 distinguish between garbage and failure, failures should not be 393 treated too quickly as indication of SA reuse. Often, single packets 394 cause state-related errors that block otherwise normal packets from 395 passing. 397 7. UDP encapsulation 399 The flow lookup code needs to detect UDP packets to or from port 4500 400 in addition to the ESP packets, and perform similar processing to 401 them after skipping the UDP header. Each unique port pair makes 402 separate IPsec flow, i.e. UDP encapsulated IPsec flows are 403 identified by the source and destination IP, source and destination 404 port number and SPI number. As devices might be using MOBIKE, that 405 means that the flow cache should be shared between the UDP 406 encapsulated IPsec flows and non encapsulated IPsec flows. As 407 previously mentioned, differentiating between garbage and actual 408 policy failures will help in proper detection immensely. 410 Because the checks are also run for packets having source port 4500 411 in addition to those having destination port 4500, this might cause 412 the checks to be run for non-ESP traffic too. The UDP encapsulation 413 processing should also be avare of that. We cannot limit the checks 414 for only UDP packets having destination port 4500, as return packets 415 from the SGW going towards the NAT box do have source port 4500, and 416 some other port as destination port. 418 8. Heuristic Checks 420 Normally, HMAC-SHA1-96 or HMAC-MD5-96 gives 1 out of 2^96 probability 421 that a random packet will pass the HMAC test. This yields a 422 99.999999999999999999999999998% probability that an end node will 423 correctly detect a random packet as being invalid. This means that 424 it should be enough for an intermediate device to check around 96 425 bits from the input packet. By comparing them against known values 426 for the packet we get more or less same probability as an end node is 427 using. This gives an upper limit of how many bits heuristics need to 428 check - there is no point of checking much more than that many bits 429 (since that same probability is acceptable for the end node). In 430 most of the cases the intermediate device does not need that high 431 probability, perhaps something around 32-64 bits is enough. 433 IPsec's ESP has a well-understood packet layout, but its variable- 434 length fields reduce the ability of pure algorithmic matching to one 435 requiring heuristics and assigning probabilities. 437 8.1. ESP-NULL format 439 The ESP-NULL format is as follows: 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Security Parameters Index (SPI) | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Sequence Number | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | IV (optional) | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Payload Data (variable) | 451 ~ ~ 452 | | 453 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | | Padding (0-255 bytes) | 455 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | | Pad Length | Next Header | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Integrity Check Value-ICV (variable) | 459 ~ ~ 460 | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Figure 1 465 The output of the heuristics should provide us information whether 466 the packet is encrypted ESP or ESP-NULL. In case it is ESP-NULL we 467 also need to know the Integrity Check Value (ICV) field length and 468 the Initialization Vector (IV) length. 470 The currently defined ESP authentication algorithms have 5 different 471 lengths for the ICV field. Most commonly used is 96 bits for 472 AUTH_HMAC_MD5_96, AUTH_HMAC_SHA1_96, AUTH_AES_XCBC_96, and 473 AUTH_AES_CMAC_96 algorithms. After that comes 128 bit ICV lengths 474 for AUTH_HMAC_MD5_128, AUTH_HMAC_SHA2_256_128 AUTH_AES_128_GMAC, 475 AUTH_AES_192_GMAC, AUTH_AES_256_GMAC algorithms. 160, 192, and 256 476 bit field lengths are used by AUTH_HMAC_SHA1_160, 477 AUTH_HMAC_SHA2_384_192, and AUTH_HMAC_SHA2_512_256 algorithms, 478 respectively. 480 In addition to the ICV length, there are also two possible values for 481 IV lengths: zero bytes (default) and eight bytes (for 482 AUTH_AES_*_GMAC). Detecting the IV length requires understanding the 483 payload, i.e. the actual protocol data (meaning TCP, UDP, etc). This 484 is required to distinguish the optional IV from the actual protocol 485 data. How well IV can be distinguished from the actual protocol data 486 depends how the IV is generated. If IV is generated using method 487 that generates random looking data (i.e. encrypted counter etc) then 488 disginguishing protocol data from IV is quite easy. If IV is counter 489 or similar non-random value, then there are bit more possibilities 490 for error. If the protocol (also known as the, "next header") of the 491 packet is something that heuristics doesn't have protocol checking 492 support, then detecting the IV length is impossible, thus the 493 heuristics cannot finish. In that case heuristics returns "unsure" 494 and requires further packets. 496 8.2. Self Describing Padding Check 498 Before obtaining the next header field, the ICV length must be 499 measured. Five different ICV lengths leads to five possible places 500 for the pad length and padding. Implementations must be careful when 501 trying larger sizes of ICV such that the inspected bytes do not 502 belong to data that is not payload data. For example, a ten-byte 503 ICMP echo request will have zero-length padding, but any checks for 504 256-bit ICVs will inspect sequence number or SPI data if the packet 505 actually contains a 96-bit or 128-bit ICV. 507 ICV lengths should always be checked from shorted to longest. It is 508 much more likely to obtain valid-looking padding bytes in the 509 cleartext part of the payload than from the ICV field of a longer ICV 510 than what is currently inspected. For example, if a packet has a 96- 511 bit ICV and implementation starts first checking for a 256-bit ICV, 512 it is possible that the cleartext part of the payload contains valid 513 looking bytes. If done in the other order, i.e. a packet having a 514 256-bit ICV and the implementation checks for a 96-bit ICV first, the 515 inspected bytes are part of the longer ICV field, and should be 516 indistinguishable from random noise. 518 Each ESP packet always has between 0-255 bytes of padding, and 519 payload, pad length, and next header are always right aligned within 520 a 4-byte boundary. Normally implementations use minimal amount of 521 padding, but heuristics method would be even more reliable if some 522 extra padding is added. The actual padding data has bytes starting 523 from 01 and ending to the pad length, i.e. exact padding and pad 524 length bytes for 4 bytes of padding would be 01 02 03 04 04. 526 Two cases of ESP-NULL padding are matched bytes (like the 04 04 shown 527 above), or the zero-byte padding case. In cases where there is one 528 or more bytes of padding, a node can perform a very simple and fast 529 test -- a sequence of N N in any of those five locations. Given five 530 two-byte locations (assuming the packet size allows all five possible 531 ICV lengths), the upper-bound probability of finding a random 532 encrypted packet that exhibits non-zero length ESP-NULL properties is 533 1-(1-255/65536)^5 == 0.019 == 1.9%. In the cases where there is 0 534 bytes of padding, a random encrypted ESP packet has 1-(1-1/256)^5 == 535 0.019 == 1.9%. Together, both cases yields a 3.8% upper-bound chance 536 of misclassifying an encrypted packet as an ESP-NULL packet. 538 In the matched bytes case, further inspection (counting the pad bytes 539 backward and downward from the pad-length match) can reduce the 540 number of misclassified packets further. A padding length of 255 541 means a specific 256^254 sequence of bytes must occur. This 542 virtually eliminates pairs of 'FF FF' as viable ESP-NULL padding. 543 Every one of the 255 pairs for padding length N has only a 1 / 256^N 544 probability of being correct ESP-NULL padding. This shrinks the 545 aforementioned 1.9% of matched-pairs to virtually nothing. 547 At this point a maximum of 2% of packets remain, so the next header 548 number is inspected. If the next header number is known (and 549 supported) then the packet can be inspected based on the next header 550 number. If the next header number is unknown (i.e. not any of those 551 with protocol checking support) the packet is marked "unsure", 552 because there is no way to detect the IV length without inspecting 553 the inner protocol payload. 555 There are six different next header fields which are in common use 556 (TCP (6), UDP (17), ICMP (1), SCTP (132), IPv4 (4) and IPv6 (41)), 557 and if IPv6 is in heavy use, that number increases to nine (Fragment 558 (44), ICMPv6 (58), and IPv6 options (60)). To insure that no packet 559 is misinterpreted as an encrypted ESP packet even when it is ESP-NULL 560 packet, a packet cannot be marked as a failure even when the next 561 header number is one of those which is not known and supported. In 562 those cases the packet must be marked "unsure". 564 An intermediate node's policy, however, can aid in detecting an ESP- 565 NULL flow even when the protocol is not a common-case one. By 566 counting how many "unsure" returns obtained via heuristics, and after 567 the receipt of a consistent, but unknown, next-header number of those 568 with same ICV length (i.e. in same location) that means that flow is 569 ESP-NULL with more probability than what it is to fool a given hash 570 algorithm with a random packet. The flow can be classified as ESP- 571 NULL with a known ICV length, but an unknown IV length. 573 Fortunately, in unknown protocol cases the IV length does not matter, 574 as the protocol is unknown to the heuristics, it will most likely be 575 unknown by the deep inspection engine also. It is therefore 576 important that heuristics should support at least those same 577 protocols as the deep inspection engine does. Upon receipt of any 578 inner next header number that is known by the heuristics (and deep 579 inspection engine), the heuristics can detect the IV length properly. 581 8.3. Protocol Checks 583 Generic protocol checking is much easier with pre-existing state. 584 For example, when many TCP / UDP flows are established over one SA, a 585 rekey with a new SA which needs heuristics. Then it is enough to 586 just check that if the flow is already known by the deep inspection 587 engine, it will give a strong leaning that the new SA is really ESP- 588 NULL. 590 The worst case scenario is when an end node starts up communcation, 591 i.e. it does not have any previous flows through the device. 592 Heuristics will run on the first few packets received from the end 593 node. The later subsections mainly cover these bringup cases, as 594 they are the most difficult. 596 In the protocol checks there are two different types of checks. The 597 first check is for packet validity, i.e. certain locations must 598 contain specific values. For example, an inner IPv4 header of an 599 IPv4 tunnel packet must have its 4-bit version number set to 4. If 600 it does not, the packet is not valid, and can be marked as a failure. 601 Other positions depending on ICV and IV lengths must also be checked, 602 and if all of them are failures, then the packet is a failure. If 603 any of the checks are "unsure" the packet is marked as such. 605 The second type of check is for variable, but easy-to-parse values. 606 For example, the 4-bit header length field of an inner IPv4 packet. 607 It has a fixed value (5) as long as there are no inner IPv4 options. 608 If the header-length has that specific value, the number of known 609 "good" bits increases. If it has some other value, the known "good" 610 bit count stays the same. A local policy might include reaching a 611 bit count that is over a threshold (for example 96 bits), causing a 612 packet to be marked as valid. 614 8.3.1. TCP checks 616 When the first TCP packet is feed to the heuristics, it is most 617 likely going to be the SYN packet of the new connection, thus it will 618 have less useful information than what other later packets might 619 have. Best valid packet checks include: checking that header length 620 and reserved and other bits have valid values; checking source and 621 destination port numbers, which in some cases can be used for 622 heuristics (but in general they cannot be used to reliably 623 distinguished from random numbers apart from some well-known ports 624 like 25/80/110/143). 626 The most obvious field, TCP checksum, might not be usable, as it is 627 possible that the packet has already transitted a NAT box, thus the 628 IP numbers used in the checksum are wrong, thus the checksum is 629 wrong. If the checksum is correct that can again be used to increase 630 valid bit count, but verifying checksums is a costly operation, thus 631 skipping that check might be best unless there is hardware to help 632 the calculation. Window size, urgent pointer, sequence number, and 633 acknowledgement numbers can be used, but there is not one specific 634 known value for them. 636 One good method of detection is if the a packet is dropped then the 637 next packet will most likely be a retransmission of the previous 638 packet. Thus if two packets are received with the same source, and 639 destination port numbers, and where sequence numbers are either same 640 or right after each other, then it's likely a TCP packet has been 641 correctly detected. 643 The deep inspection engines usually do very good TCP flow checking 644 already, including flow tracking, verification of sequence numbers, 645 and reconstruction of the whole TCP flow. Similar methods can be 646 used here, but they are implementation-dependent and not described 647 here. 649 8.3.2. UDP checks 651 UDP header has even more problems than the TCP header, as UDP has 652 even less known data. The checksum has the same problem as the TCP 653 checksum, due to NATs. The UDP length field might not match the 654 overall packet length, as the sender is allowed to include TFC 655 (traffic flow confidentiality, see section 2.7 of IP Encapsulating 656 Security Payload document [RFC4303]) padding. 658 With UDP packets similar multiple packet methods can be used as with 659 TCP, as UDP protocols usually include several packets using same port 660 numbers going from one end node to another, thus receiving multiple 661 packets having a known pair of UDP port numbers is good indication 662 that the heuristics have passed. 664 Some UDP protocols also use identical source and destination port 665 numbers, thus that is also a good check. 667 8.3.3. ICMP checks 669 As ICMP messages are usually sent as return packets for other 670 packets, they are not very common packets to get as first packets for 671 the SA, the ICMP Echo message being a noteworthy exception. ICMP 672 ECHO has known type and code, identifier, and sequence number. The 673 checksum, however, might be incorrect again because of NATs. 675 For error ICMP messages the ICMP message contains part of the 676 original IP packet inside, and then same rules which are used to 677 detect IPv4/IPv6 tunnel checks can be used. 679 8.3.4. SCTP checks 681 SCTP [RFC4960] has a self-contained checksum, which is computed over 682 the SCTP payload and is not affected by NATs unless the NAT is SCTP- 683 aware. Even more than the TCP and UDP checksums, the SCTP checksum 684 is expensive, and may be prohibitive even for deep-packet 685 inspections. 687 SCTP chunks can be inspected to see if their lengths are consistent 688 across the total length of the IP datagram, so long as TFC padding is 689 not present. 691 8.3.5. IPv4 and IPv6 Tunnel checks 693 In cases of tunneled traffic the packet inside contains a full IPv4 694 or IPv6 packet. Many fields are useable. For IPv4 those fields 695 include version, header length, total length (again TFC padding might 696 confuse things there), protocol number, and 16-bit header checksum. 697 In those cases the intermediate device should give the decapsulated 698 IP packet to the deep inspection engine. IPv6 has less usable 699 fields, but the version number, packet length (modulo TFC confusion) 700 and next-header all can be used by deep-packet inspection. 702 9. Security Considerations 704 The whole deep inspection for ESP-NULL flows only has the problem 705 that attacker can always bypass it by using encrypted ESP (or some 706 other encryption or tunneling method) instead of ESP-NULL unless that 707 is not forbidden by policy. This means that in the end the 708 responsibility whether end node can bypass deep inspection is for the 709 policy enforcement of the both end nodes, i.e. if a server allows 710 encrypted connections also, then attacker who wants to attack the 711 server and wants to bypass deep inspection device in the middle, will 712 use encrypted traffic. This means that the protection of the whole 713 network is only as good as the policy enforcement and protection of 714 the end node. One way to enforce deep inspection for all traffic, is 715 to forbid encrypted ESP completely, but in that case ESP-NULL 716 detection is easier, as all packets must be ESP-NULL based on the 717 policy, and further restriction can eliminate ambiguities in ICV and 718 IV sizes. 720 10. References 722 10.1. Normative References 724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 725 Requirement Levels", BCP 14, RFC 2119, March 1997. 727 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 728 Its Use With IPsec", RFC 2410, November 1998. 730 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 731 Internet Protocol", RFC 4301, December 2005. 733 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 734 December 2005. 736 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 737 RFC 4303, December 2005. 739 10.2. Informative References 741 [I-D.bhatia-ipsecme-esp-null] 742 Bhatia, M., "Identifying ESP-NULL Packets", 743 draft-bhatia-ipsecme-esp-null-00 (work in progress), 744 December 2008. 746 [I-D.hoffman-esp-null-protocol] 747 Hoffman, P. and D. McGrew, "An Authentication-only Profile 748 for ESP with an IP Protocol Identifier", 749 draft-hoffman-esp-null-protocol-00 (work in progress), 750 August 2007. 752 [I-D.ietf-ipsecme-traffic-visibility] 753 Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped ESP 754 for Traffic Visibility", 755 draft-ietf-ipsecme-traffic-visibility-08 (work in 756 progress), September 2009. 758 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 759 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 760 RFC 3948, January 2005. 762 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 763 Requirements for Encapsulating Security Payload (ESP) and 764 Authentication Header (AH)", RFC 4835, April 2007. 766 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 767 RFC 4960, September 2007. 769 Appendix A. Example Pseudocode 771 This appendix is meant for the implementors. It does not include all 772 the required checks, and this is just example pseudocode, so final 773 implementation can be very different. It mostly lists things what 774 needs to be done, but implementations can optimize things depending 775 on their other parts. For example implementation might combine 776 heuristics and deep inspection tightly together. 778 A.1. Fastpath 780 The following example pseudocode show the fastpath part of the packet 781 processing engine. This part is usually implemented in hardware. 783 //////////////////////////////////////////////////////////// 784 // This pseudocode uses following variables: 785 // 786 // SPI_offset: Number of bytes between start of protocol 787 // data and SPI. This is 0 for ESP, and 788 // 8 for UDP encapsulated ESP (i.e skipping 789 // UDP header). 790 // 791 // IV_len: Length of the IV of the ESP-NULL packet. 792 // 793 // ICV_len: Length of the ICV of the ESP-NULL packet. 794 // 795 // State: State of the packet, i.e. ESP-NULL, ESP, or 796 // unsure. 797 // 798 // Also following data is taken from the packet: 799 // 800 // IP_total_len: Total IP packet length 801 // IP_hdr_len: Header length of IP packet in bytes 802 // IP_Src_IP: Source address of IP packet 803 // IP_Dst_IP: Destination address of IP packet 804 // 805 // UDP_len: Length of the UDP packet taken from UDP header. 806 // UDP_src_port: Source port of UDP packet. 807 // UDP_dst_port: Destination port of UDP packet. 808 // 809 // SPI: SPI number from ESP packet. 810 // 811 // Protocol: Actual protocol number of the protocol inside 812 // ESP-NULL packet. 813 // Protocol_off: Calculated offset to the protocol payload data 814 // inside ESP-NULL packet. 816 //////////////////////////////////////////////////////////// 817 // This is the main processing code for the packet 818 // This will check if the packet requires ESP processing, 819 // 820 Process packet: 821 * If IP protocol is ESP 822 * Set SPI_offset to 0 bytes 823 * Goto Process ESP 824 * If IP protocol is UDP 825 * Goto Process UDP 826 * Continue Non-ESP processing 828 //////////////////////////////////////////////////////////// 829 // This code is run for UDP packets, and it checks if the 830 // packet is UDP encapsulated UDP packet, or UDP 831 // encapsulated IKE packet, or keepalive packet. 832 // 833 Process UDP: 834 // Reassembly is not mandatory here, we could 835 // do reassembly also only after detecting the 836 // packet being UDP encapsulated ESP packet, but 837 // that would complicated the pseudocode here 838 // a lot, as then we would need to add code 839 // for checking if the UDP header is in this 840 // packet or not. 841 // Reassembly is to simplify things 842 * If packet is fragment 843 * Do full reassembly before processing 844 * If UDP_src_port != 4500 and UDP_dst_port != 4500 845 * Continue Non-ESP processing 846 * Set SPI_offset to 8 bytes 847 * If UDP_len > 4 and first 4 bytes of UDP packet are 0x000000 848 * Continue Non-ESP processing (pass IKE-packet) 849 * If UDP_len == 1 and first byte is 0xff 850 * Continue Non-ESP processing (pass NAT-Keepalive Packet) 851 * Goto Process ESP 853 //////////////////////////////////////////////////////////// 854 // This code is run for ESP packets (or UDP encapsulated ESP 855 // packets). This checks if IPsec flow is known, and 856 // if not calls heuristics. If IPsec flow is known 857 // then it continues processing based on the policy. 858 // 859 Process ESP: 860 * If packet is fragment 861 * Do full reassembly before processing 862 * If IP_total_len < IP_hdr_len + SPI_offset + 4 863 * Drop invalid packet 865 * Load SPI from IP_hdr_len + SPI_offset 866 * Initialize State to ESP 867 // In case this was UDP encapsulated ESP then use UDP_src_port and 868 // UDP_dst_port also when finding data from SPI cache. 869 * Find IP_Src_IP + IP_Dst_IP + SPI from SPI cache 870 * If SPI found 871 * Load State, IV_len, ICV_len from cache 872 * If SPI not found or State is unsure 873 * Call Autodetect ESP parameters (drop to slowpath) 874 * If State is ESP 875 * Continue Non-ESP-NULL processing 876 * Goto Check ESP-NULL packet 878 //////////////////////////////////////////////////////////// 879 // This code is run for ESP-NULL packets, and this 880 // finds out the data required for deep inspection 881 // engine (protocol number, and offset to data) 882 // and calls the deep inspection engine. 883 // 884 Check ESP-NULL packet: 885 * If IP_total_len < IP_hdr_len + SPI_offset + IV_len + ICV_len 886 + 4 (spi) + 4 (seq no) + 4 (protocol + padding) 887 * Drop invalid packet 888 * Load Protocol from IP_total_len - ICV_len - 1 889 * Set Protocol_off to 890 IP_hdr_len + SPI_offset + IV_len + 4 (spi) + 4 (seq no) 891 * Do normal deep inspection on packet. 893 Figure 2 895 A.2. Slowpath 897 The following example pseudocode show the actual heuristics part of 898 the packet processing engine. This part is usually implemented in 899 software. 901 //////////////////////////////////////////////////////////// 902 // This pseudocode uses following variables: 903 // 904 // SPI_offset, IV_len, ICV_len, State, SPI, 905 // IP_total_len, IP_hdr_len, IP_Src_IP, IP_Dst_IP 906 // as defined in fastpath pseudocode. 907 // 908 // Stored_Check_Bits:Number of bits we have successfully 909 // checked to contain acceptable values 910 // in the actual payload data. This value 911 // is stored / retrieved from SPI cache. 912 // 913 // Check_Bits: Number of bits we have successfully 914 // checked to contain acceptable values 915 // in the actual payload data. This value 916 // is updated during the packet 917 // verification. 918 // 919 // Last_Packet_Data: Contains selected pieces from the 920 // last packet. This is used to compare 921 // certain fields of this packet to 922 // same fields in previous packet. 923 // 924 // Packet_Data: Selected pieces of this packet, same 925 // fields as Last_Packet_Data, and this 926 // is stored as new Last_Packet_Data to 927 // SPI cache after this packet is processed. 928 // 929 // Test_ICV_len: Temporary ICV length used during tests. 930 // This is stored to ICV_len when 931 // padding checks for the packet succeed 932 // and the packet didn't yet have unsure 933 // status. 934 // 935 // Test_IV_len: Temporary IV length used during tests. 936 // 937 // Pad_len: Padding length from the ESP packet. 938 // 939 // Protocol: Protocol number of the packet inside ESP 940 // packet. 941 // 942 // TCP.*: Fields from TCP header (from inside ESP) 943 // UDP.*: Fields from UDP header (from inside ESP) 945 //////////////////////////////////////////////////////////// 946 // This code starts the actual heuristics. 947 // During this the fastpath has already loaded 948 // State, ICV_len and IV_len in case they were 949 // found from the SPI cache (i.e. in case the flow 950 // had unsure status). 951 // 952 Autodetect ESP parameters: 953 // First we check if this is unsure flow, and 954 // if so, we check next packet against the 955 // already set IV/ICV_len combination. 956 * If State is unsure 957 * Call Verify next packet 958 * If State is ESP-NULL 959 * Goto Store ESP-NULL SPI cache info 960 * If State is unsure 961 * Goto Verify unsure 962 // If we failed the test, i.e. State 963 // was changed to ESP, we check other 964 // ICV/IV_len values, i.e. fall through 965 // ICV lengths are tested in order of ICV lengths, 966 // from shortest to longest. 967 * Call Try standard algorithms 968 * If State is ESP-NULL 969 * Goto Store ESP-NULL SPI cache info 970 * Call Try 128bit algorithms 971 * If State is ESP-NULL 972 * Goto Store ESP-NULL SPI cache info 973 * Call Try 160bit algorithms 974 * If State is ESP-NULL 975 * Goto Store ESP-NULL SPI cache info 976 * Call Try 192bit algorithms 977 * If State is ESP-NULL 978 * Goto Store ESP-NULL SPI cache info 979 * Call Try 256bit algorithms 980 * If State is ESP-NULL 981 * Goto Store ESP-NULL SPI cache info 982 // No idea how to test AUTH_DES_MAC and AUTH_KPDK_MD5 as they are 983 // not defined anywhere 984 // If any of those test above set state to unsure 985 // we mark IPsec flow as unsure. 986 * If State is unsure 987 * Goto Store unsure SPI cache info 988 // All of the test failed, meaning the packet cannot 989 // be ESP-NULL packet, thus we mark IPsec flow as ESP 990 * Goto Store ESP SPI cache info 992 //////////////////////////////////////////////////////////// 993 // Store ESP-NULL status to the IPsec flow cache. 994 // 995 Store ESP-NULL SPI cache info: 996 * Store State, IV_len, ICV_len to SPI cache 997 using IP_Src_IP + IP_Dst_IP + SPI as key 998 * Continue Check ESP-NULL packet 1000 //////////////////////////////////////////////////////////// 1001 // Store encrypted ESP status to the IPsec flow cache. 1002 // 1003 Store ESP SPI cache info: 1004 * Store State, IV_len, ICV_len to SPI cache 1005 using IP_Src_IP + IP_Dst_IP + SPI as key 1006 * Continue Check non-ESP-NULL packet 1008 //////////////////////////////////////////////////////////// 1009 // Store unsure flow status to IPsec flow cache. 1010 // Here we also store the Check_Bits. 1011 // 1012 Store unsure SPI cache info: 1013 * Store State, IV_len, ICV_len, 1014 Stored_Check_Bits to SPI cache 1015 using IP_Src_IP + IP_Dst_IP + SPI as key 1016 * Contine Check unknown packet 1018 //////////////////////////////////////////////////////////// 1019 // Verify this packet against the previously selected 1020 // ICV_len and IV_len values. This will either 1021 // fail (and set state to ESP to mark we do not yet 1022 // know what type of flow this is), or it will 1023 // increment Check_Bits. 1024 // 1025 Verify next packet: 1026 // We already have IV_len, ICV_len and State loaded 1027 * Load Stored_Check_Bits, Last_Packet_Data from SPI Cache 1028 * Set Test_ICV_len to ICV_len, Test_IV_len to IV_len 1029 * Initialize Check_Bits to 0 1030 * Call Verify padding 1031 * If verify padding returned Failure 1032 // Initial guess was wrong, restart 1033 * Set State to ESP 1034 * Clear IV_len, ICV_len, State, 1035 Stored_Check_Bits, Last_Packet_Data 1036 from SPI Cache 1037 * Return 1038 // Ok, padding check succeeded again 1039 * Call Verify packet 1040 * If verify packet returned Failure 1041 // Guess was wrong, restart 1042 * Set State to ESP 1043 * Clear IV_len, ICV_len, State, 1044 Stored_Check_Bits, Last_Packet_Data 1045 from SPI Cache 1046 * Return 1047 // It succeeded and updated Check_Bits and Last_Packet_Data store 1048 // them to SPI cache 1049 * Increment Stored_Check_Bits by Check_Bits 1050 * Store Stored_Check_Bits to SPI Cache 1051 * Store Packet_Data as Last_Packet_Data to SPI cache 1052 * Return 1054 //////////////////////////////////////////////////////////// 1055 // This will check if we have already seen enough bits 1056 // acceptable from the payload data, so we can decide 1057 // that this IPsec flow is ESP-NULL flow. 1058 // 1059 Verify unsure: 1060 // Check if we have enough check bits 1061 * If Stored_Check_Bits > configured limit 1062 // We have checked enough bits, return ESP-NULL 1063 * Set State ESP-NULL 1064 * Goto Store ESP-NULL SPI cache info 1065 // Not yet enough bits, continue 1066 * Continue Check unknown packet 1068 //////////////////////////////////////////////////////////// 1069 // Check for standard 96-bit algorithms. 1070 // 1071 Try standard algorithms: 1072 // AUTH_HMAC_MD5_96, AUTH_HMAC_SHA1_96, AUTH_AES_XCBC_96, 1073 // AUTH_AES_CMAC_96 1074 * Set Test_ICV_len to 12, Test_IV_len to 0 1075 * Goto Check packet 1077 //////////////////////////////////////////////////////////// 1078 // Check for 128-bit algorithms, this is only one that 1079 // can have IV, so we need to check different IV_len values 1080 // here too. 1081 // 1082 Try 128bit algorithms: 1083 // AUTH_HMAC_MD5_128, AUTH_HMAC_SHA2_256_128 1084 // AUTH_AES_128_GMAC, AUTH_AES_192_GMAC, AUTH_AES_256_GMAC 1085 * Set Test_ICV_len to 16, Test_IV_len to 0 1086 * If IP_total_len < IP_hdr_len + SPI_offset 1087 + Test_IV_len + Test_ICV_len 1088 + 4 (spi) + 4 (seq no) + 4 (protocol + padding) 1089 * Return 1090 * Call Verify padding 1091 * If verify padding returned Failure 1092 * Return 1093 * Initialize Check_Bits to 0 1094 * Call Verify packet 1095 * If verify packet returned Failure 1096 * Goto Try GMAC 1097 // Ok, packet seemed ok, but go now and check if we have enough 1098 // data bits so we can assume it is ESP-NULL 1099 * Goto Check if done for unsure 1101 //////////////////////////////////////////////////////////// 1102 // Check for GMAC macs, i.e. macs having 8 byte IV. 1103 // 1104 Try GMAC: 1105 // AUTH_AES_128_GMAC, AUTH_AES_192_GMAC, AUTH_AES_256_GMAC 1106 * Set Test_IV_len to 8 1107 * If IP_total_len < IP_hdr_len + SPI_offset 1108 + Test_IV_len + Test_ICV_len 1109 + 4 (spi) + 4 (seq no) + 4 (protocol + padding) 1110 * Return 1111 * Initialize Check_Bits to 0 1112 * Call Verify packet 1113 * If verify packet returned Failure 1114 // Guess was wrong, continue 1115 * Return 1116 // Ok, packet seemed ok, but go now and check if we have enough 1117 // data bits so we can assume it is ESP-NULL 1118 * Goto Check if done for unsure 1120 //////////////////////////////////////////////////////////// 1121 // Check for 160-bit algorithms. 1122 // 1123 Try 160bit algorithms: 1124 // AUTH_HMAC_SHA1_160 1125 * Set Test_ICV_len to 20, Test_IV_len to 0 1126 * Goto Check packet 1128 //////////////////////////////////////////////////////////// 1129 // Check for 192-bit algorithms. 1130 // 1131 Try 192bit algorithms: 1132 // AUTH_HMAC_SHA2_384_192 1133 * Set Test_ICV_len to 24, Test_IV_len to 0 1134 * Goto Check packet 1136 //////////////////////////////////////////////////////////// 1137 // Check for 256-bit algorithms. 1138 // 1139 Try 256bit algorithms: 1140 // AUTH_HMAC_SHA2_512_256 1141 * Set Test_ICV_len to 32, Test_IV_len to 0 1142 * Goto Check packet 1144 //////////////////////////////////////////////////////////// 1145 // This actually does the checking for the packet, by 1146 // first verifying the length, and then self describing 1147 // padding, and if that succeeds, then checks the actual 1148 // payload content. 1149 // 1150 Check packet: 1151 * If IP_total_len < IP_hdr_len + SPI_offset 1152 + Test_IV_len + Test_ICV_len 1153 + 4 (spi) + 4 (seq no) + 4 (protocol + padding) 1154 * Return 1155 * Call Verify padding 1156 * If verify padding returned Failure 1157 * Return 1158 * Initialize Check_Bits to 0 1159 * Call Verify packet 1160 * If verify packet returned Failure 1161 // Guess was wrong, continue 1162 * Return 1163 // Ok, packet seemed ok, but go now and check if we have enough 1164 // data bits so we can assume it is ESP-NULL 1165 * Goto Check if done for unsure 1167 //////////////////////////////////////////////////////////// 1168 // This code checks if we have seen enough acceptable 1169 // values in the payload data, so we can decide that this 1170 // IPsec flow is ESP-NULL flow. 1171 // 1172 Check if done for unsure: 1173 * If Stored_Check_Bits > configured limit 1174 // We have checked enough bits, return ESP-NULL 1175 * Set State ESP-NULL 1176 * Set IV_len to Test_IV_len, ICV_len to Test_ICV_len 1177 * Clear Stored_Check_Bits, Last_Packet_Data from SPI Cache 1178 * Return 1179 // Not yet enough bits, check this is first unsure, if so 1180 // store information. In case there is multiple 1181 // tests succeeding, we always assume the first one 1182 // (the wone using shortest MAC) is the one we want to 1183 // check in the future. 1184 * If State is not unsure 1185 * Set State unsure 1186 // These values will be stored to SPI cache if 1187 // the final state will be unsure 1188 * Set IV_len to Test_IV_len, ICV_len to Test_ICV_len 1189 * Set Stored_Check_Bits as Check_Bits 1190 * Return 1192 //////////////////////////////////////////////////////////// 1193 // Verify self describing padding 1194 // 1195 Verify padding: 1196 * Load Pad_len from IP_total_len - Test_ICV_len - 2 1197 * Verify padding bytes at 1198 IP_total_len - Test_ICV_len - 1 - Pad_len .. 1199 IP_total_len - Test_ICV_len - 2 are 1200 1, 2, ..., Pad_len 1201 * If Verify of padding bytes succeeded 1202 * Return Success 1203 * Return Failure 1205 //////////////////////////////////////////////////////////// 1206 // This will verify the actual protocol content inside ESP 1207 // packet. 1208 // 1209 Verify packet: 1210 // We need to first check things that cannot be set, i.e if any of 1211 // those are incorrect, then we return Failure. For any 1212 / fields which might be correct, we increment the Check_Bits 1213 // for a suitable amount of bits. If all checks pass, then 1214 // we just return Success, and the upper layer will then 1215 // later check if we have enough bits checked already. 1216 * Load Protocol From IP_total_len - Test_ICV_len - 1 1217 * If Protocol TCP 1218 * Goto Verify TCP 1219 * If Protocol UDP 1220 * Goto Verify UDP 1221 // Other protocols can be added here as needed, most likely same 1222 // protocols as deep inspection does 1223 // Tunnel mode checks is also left out from here to make the 1224 // document shorter. 1225 * Return Failure 1227 //////////////////////////////////////////////////////////// 1228 // Verify TCP protocol headers 1229 // 1230 Verify TCP: 1231 // First we check things that must be set correctly. 1232 * Check TCP.reserved_bits are non-zero 1233 * Return Failure 1234 * If TCP.Data_Offset field < 5 1235 // TCP head length too small 1236 * Return Failure 1237 // After that we start to check things that does not 1238 // have one definitive value, but can have multiple possible 1239 // valid values 1240 * If TCP.ACK bit is not set, then check 1241 that TCP.Acknowledgment_number field contains 0 1242 // If ACK bit is not set then the acknowledgment 1243 // field usually contains 0, but I do not think 1244 // RFCs mandate it being zero, so we cannot make 1245 // this a failure if it is not so. 1246 * Increment Check_Bits by 32 1247 * If TCP.URG bit is not set, then check 1248 that TCP.Urgent_Pointer field contains 0 1249 // If URG bit is not set then urgent pointer 1250 // field usually contains 0, but I do not think 1251 // RFCs mandate it being zero, so we cannot make 1252 // this failure if it is not so. 1253 * Increment Check_Bits by 16 1254 * If TCP.Data_Offset field == 5 1255 * Increment Check_Bits by 4 1256 * If TCP.Data_Offset field > 5 1257 * If TCP options format is valid and it is padded correctly 1258 * Increment Check_Bits accordingly 1259 * If TCP options format was garbage 1260 * Return Failure 1261 * If TCP.checksum is correct 1262 // This might be wrong because packet passed NAT, so 1263 // we cannot make this failure case 1264 * Increment Check_Bits by 16 1265 // We can also do normal deeper TCP inspection here, i.e. 1266 // check that SYN/ACK/FIN/RST bits are correct and state 1267 // matches the state of existing flow if this is packet 1268 // to existing flow etc. 1269 // If there is anything clearly wrong in the packet (i.e. 1270 // some data is set to something that it cannot be), then 1271 // this can return Failure, otherwise it should just 1272 // increment Check_Bits matching the number of bits checked. 1273 // 1274 // We can also check things here compared to the last packet 1275 * If Last_Packet_Data.TCP.source port = 1276 Packet_Data.TCP.source_port and 1277 Last_Packet_Data.TCP.destination port = 1278 Packet_Data.TCP.destination port 1279 * Increment Check_Bits by 32 1280 * If Last_Packet_Data.TCP.acknowledgement_number = 1281 Packet_Data.TCP.acknowledgement_number 1282 * Increment Check_Bits by 32 1283 * If Last_Packet_Data.TCP.sequence_number = 1284 Packet_Data.TCP.sequence_number 1285 * Increment Check_Bits by 32 1286 // We can do other similar checks here 1287 * Return Success 1289 //////////////////////////////////////////////////////////// 1290 // Verify UDP protocol headers 1291 // 1292 Verify UDP: 1293 // First we check things that must be set correctly. 1294 * If UDP.UDP_length > IP_total_len - IP_hdr_len - SPI_offset 1295 - Test_IV_len - Test_ICV_len - 4 (spi) 1296 - 4 (seq no) - 1 (protocol) 1297 - Pad_len - 1 (Pad_len) 1298 * Return Failure 1299 * If UDP.UDP_length < 8 1300 * Return Failure 1301 // After that we start to check things that does not 1302 // have one definitive value, but can have multiple possible 1303 // valid values 1304 * If UDP.UDP_checksum is correct 1305 // This might be wrong because packet passed NAT, so 1306 // we cannot make this failure case 1307 * Increment Check_Bits by 16 1308 * If UDP.UDP_length = IP_total_len - IP_hdr_len - SPI_offset 1309 - Test_IV_len - Test_ICV_len - 4 (spi) 1310 - 4 (seq no) - 1 (protocol) 1311 - Pad_len - 1 (Pad_len) 1312 // If there is no TFC padding then UDP_length 1313 // will be matching the full packet length 1314 * Increment Check_Bits by 16 1315 // We can also do normal deeper UDP inspection here. 1316 // If there is anything clearly wrong in the packet (i.e. 1317 // some data is set to something that it cannot be), then 1318 // this can return Failure, otherwise it should just 1319 // increment Check_Bits matching the number of bits checked. 1320 // 1321 // We can also check things here compared to the last packet 1322 * If Last_Packet_Data.UDP.source_port = 1323 Packet_Data.UDP.source_port and 1324 Last_Packet_Data.destination_port = 1325 Packet_Data.UDP.destination_port 1326 * Increment Check_Bits by 32 1327 * Return Success 1329 Figure 3 1331 Authors' Addresses 1333 Tero Kivinen 1334 Safenet, Inc. 1335 Fredrikinkatu 47 1336 HELSINKI FIN-00100 1337 FI 1339 Email: kivinen@iki.fi 1341 Daniel L. McDonald 1342 Sun Microsystems, Inc. 1343 35 Network Drive 1344 MS UBUR02-212 1345 Burlington, MA 01803 1346 USA 1348 Email: danmcd@sun.com