idnits 2.17.1 draft-ietf-ipsecme-esp-null-heuristics-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1353 has weird spacing: '...lure if it is...' -- The document date (March 22, 2010) is 5142 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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: 1 error (**), 0 flaws (~~), 2 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) AuthenTec, Inc. 4 Internet-Draft D. McDonald 5 Intended status: Informational Oracle Corporation 6 Expires: September 23, 2010 March 22, 2010 8 Heuristics for Detecting ESP-NULL packets 9 draft-ietf-ipsecme-esp-null-heuristics-07.txt 11 Abstract 13 This document describes a set of heuristics for distinguishing IPsec 14 ESP-NULL (Encapsulating Security Payload without encryption) packets 15 from encrypted ESP packets. These heuristics can be used on 16 intermediate devices, like traffic analyzers, and deep inspection 17 engines, to quickly decide whether given packet flow is encrypted or 18 not, i.e. whether it can be inspected or not. Use of these 19 heuristics does not require any changes made on existing RFC4303 20 compliant IPsec hosts. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 23, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Applicability: Heuristic Traffic Inspection and 64 Wrapped ESP . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Other Options . . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.1. AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.2. Mandating by Policy . . . . . . . . . . . . . . . . . . . 6 69 2.3. Modifying ESP . . . . . . . . . . . . . . . . . . . . . . 7 70 3. Description of Heuristics . . . . . . . . . . . . . . . . . . 8 71 4. IPsec flows . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 5. Deep Inspection Engine . . . . . . . . . . . . . . . . . . . . 11 73 6. Special and Error Cases . . . . . . . . . . . . . . . . . . . 12 74 7. UDP encapsulation . . . . . . . . . . . . . . . . . . . . . . 13 75 8. Heuristic Checks . . . . . . . . . . . . . . . . . . . . . . . 14 76 8.1. ESP-NULL format . . . . . . . . . . . . . . . . . . . . . 14 77 8.2. Self Describing Padding Check . . . . . . . . . . . . . . 16 78 8.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 18 79 8.3.1. TCP checks . . . . . . . . . . . . . . . . . . . . . . 18 80 8.3.2. UDP checks . . . . . . . . . . . . . . . . . . . . . . 19 81 8.3.3. ICMP checks . . . . . . . . . . . . . . . . . . . . . 20 82 8.3.4. SCTP checks . . . . . . . . . . . . . . . . . . . . . 20 83 8.3.5. IPv4 and IPv6 Tunnel checks . . . . . . . . . . . . . 20 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 88 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 89 Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 25 90 A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 27 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 94 1. Introduction 96 The ESP (Encapsulating Security Payload [RFC4303]) protocol can be 97 used with NULL encryption [RFC2410] to provide authentication, 98 integrity protection, and optionally replay detection; but not 99 confidentiality. NULL encryption with ESP (referred to as ESP-NULL) 100 offers similar properties to IPsec's AH (Authentication Header 101 [RFC4302]). One reason to use ESP-NULL instead of AH is that AH 102 cannot be used if there are NATs (Network Address Translation 103 devices) on the path. With AH it would be easy to detect packets 104 which have only authentication and integrity protection, as AH has 105 its own protocol number and deterministic packet length. With ESP- 106 NULL such detection is nondeterministic, in spite of the base ESP 107 packet format being fixed. 109 In some cases intermediate devices would like to detect ESP-NULL 110 packets so they could perform deep inspection or enforce access 111 control. This kind of deep inspection includes virus detection, spam 112 filtering, and intrusion detection. As end nodes might be able to 113 bypass those checks by using encrypted ESP instead of ESP-NULL, these 114 kinds of scenarios also require very specific policies to forbid such 115 circumvention. 117 These sorts of policy requirements usually mean that the whole 118 network needs to be controlled, i.e. under the same administrative 119 domain. Such setups are usually limited to inside the network of one 120 enterprise or organization, and encryption is not used as the network 121 is considered safe enough from eavesdroppers. 123 Because the traffic inspected is usually host to host traffic inside 124 one organization, that usually means transport mode IPsec is used. 125 Note, that most of the current uses of the IPsec are not host to host 126 traffic inside one organization, but for the intended use cases for 127 the heuristics this will most likely be the case. Also tunnel mode 128 case is much easier to solve than transport mode as it is much easier 129 to detect the IP header inside the ESP-NULL packet. 131 It should also be noted that even if new protocol modifications for 132 ESP support easier detection of ESP-NULL in the future, this document 133 will aid in transition of older end-systems. That way, a solution 134 can be implemented immediately, and not after a 5-10 year upgrade- 135 and-deployment time frame. Even with protocol modification for end 136 nodes, the intermediate devices will need heuristics until they can 137 assume that those protocol modifications can be found from all the 138 end devices. To make sure that any solution does not break in the 139 future it would be best if such heuristics are documented - i.e. 140 publishing an RFC for what to do now, even when there might be a new 141 protocol coming in the future that will solve the same problem 142 better. 144 1.1. Applicability: Heuristic Traffic Inspection and Wrapped ESP 146 There are two ways to enable intermediate security devices to 147 distinguish between encrypted and unencrypted ESP traffic: 149 o The heuristics approach has the intermediate node inspect the 150 unchanged ESP traffic, to determine with extremely high 151 probability whether or not the traffic stream is encrypted. 153 o The Wrapped ESP approach [I-D.ietf-ipsecme-traffic-visibility], in 154 contrast, requires the ESP endpoints to be modified to support the 155 new protocol. WESP allows the intermediate node to distinguish 156 encrypted and unencrypted traffic deterministically, using a 157 simpler implementation for the intermediate node. 159 Both approaches are being documented simultaneously by the IPsecME 160 Working Group, with WESP being put on Standards Track while the 161 heuristics approach is being published as an Informational RFC. 162 While endpoints are being modified to adopt WESP, both approaches 163 will likely coexist for years, because the heuristic approach is 164 needed to inspect traffic where at least one of the endpoints has not 165 been modified. In other words, intermediate nodes are expected to 166 support both approaches in order to achieve good security and 167 performance during the transition period. 169 1.2. Terminology 171 This document uses following terminology: 173 Flow 175 A TCP/UDP or IPsec flow is a stream of packets part of the same 176 TCP/UDP or IPsec stream, i.e. TCP or UDP flow is a stream of 177 packets having same 5 tuple (source and destination IP and port, 178 and TCP/UDP protocol). Note, that this kind of flow is also 179 called microflow in some documents. 181 Flow Cache 183 Deep inspection engines and similar devices use a cache of flows 184 going through the device, and that cache keeps state of all flows 185 going through the device. 187 IPsec Flow 189 An IPsec flow is a stream of packets sharing the same source IP, 190 destination IP, protocol (ESP/AH) and SPI. Strictly speaking, the 191 source IP does not need to be as part of the flow identification, 192 but it can be. For this reason, it is safer to assume that the 193 source IP is always part of the flow identification. 195 2. Other Options 197 This document will discuss the heuristic approach of detecting ESP- 198 NULL packets. There are some other options which can be used, and 199 this section will briefly discuss them. 201 2.1. AH 203 The most logical approach would use the already defined protocol 204 which offers authentication and integrity protection, but not 205 confidentiality, namely AH. AH traffic is clearly marked as not 206 encrypted, and can always be inspected by intermediate devices. 208 Using AH has two problems. First is that, as it also protects the IP 209 headers, it will also protect against NATs on the path, thus it will 210 not work if there is NAT on the path between end nodes. In some 211 environments this might not be a problem, but some environments 212 include heavy use of NATs even inside the internal network of the 213 enterprise or organization. NAT-Traversal (NAT-T, [RFC3948]) could 214 be extended to support AH also, and the early versions of the NAT-T 215 proposals did include that, but it was left out as it was not seen as 216 necessary. 218 Another problem is that in the new IPsec Architecture [RFC4301] the 219 support for AH is now optional, meaning not all implementations 220 support it. ESP-NULL has been defined to be mandatory to implement 221 by the Cryptographic Algorithm Implementation Requirements for 222 Encapsulating Security Payload (ESP) document [RFC4835]. 224 AH has also quite complex processing rules compared to ESP when 225 calculating the ICV, including things like zeroing out mutable 226 fields. Also as AH is not as widely used than ESP, the AH support is 227 not as well tested in the interoperability events. 229 2.2. Mandating by Policy 231 Another easy way to solve this problem is to mandate the use of ESP- 232 NULL with common parameters within an entire organization. This 233 either removes the need for heuristics (if no ESP encrypted traffic 234 is allowed at all) or simplifies them considerably (only one set of 235 parameters needs to be inspected, e.g. everybody in the organization 236 who is using ESP-NULL must use HMAC-SHA-1-96 as their integrity 237 algorithm). This does work unless one of a pair of communicating 238 machines is not under the same administrative domain as the deep 239 inspection engine. (IPsec Security Associations must be satisfactory 240 to all communicating parties, so only one communicating peer needs to 241 have a sufficiently narrow policy.) Also, such a solution might 242 require some kind of centralized policy management to make sure 243 everybody in an administrative domain uses the same policy, and that 244 changes to that single policy can be coordinated throughout the 245 administrative domain. 247 2.3. Modifying ESP 249 Several internet drafts discuss ways of modifying ESP to offer 250 intermediate devices information about an ESP packet's use of NULL 251 encryption. The following methods have been discussed: adding an IP- 252 option, adding a new IP-protocol number plus an extra header 253 [I-D.ietf-ipsecme-traffic-visibility], adding new IP-protocol numbers 254 which tell the ESP-NULL parameters [I-D.hoffman-esp-null-protocol], 255 reserving an SPI range for ESP-NULL [I-D.bhatia-ipsecme-esp-null], 256 and using UDP encapsulation with a different format and ports. 258 All of the aforementioned drafts require modification to ESP, which 259 requires that all end nodes need to be modified before intermediate 260 devices can assume that this new ESP format is in use. Updating end 261 nodes will require lots of time. An example of slow end-node 262 deployment is IKEv2. Considering an implementation that requires 263 both IKEv2 and a new ESP format, it would take several years, 264 possibly as long as a decade, before widespread deployment. 266 3. Description of Heuristics 268 The heuristics to detect ESP-NULL packets will only require changes 269 to those intermediate devices which do deep inspection or other 270 operations which require detecting ESP-NULL. As those nodes require 271 changes regardless of any ESP-NULL method, updating intermediate 272 nodes is unavoidable. Heuristics do not require updating or 273 modifying any other devices on the rest of the network, including 274 (especially) end-nodes. 276 In this document it is assumed that an affected intermediate node 277 will act as a stateful interception device, meaning it will keep 278 state of the IPsec flows - where flows are defined by the ESP SPI and 279 IP addresses forming an IPsec SA - going through it. The heuristics 280 can also be used without storing any state, but performance will be 281 worse in that case, as heuristic checks will need to be done for each 282 packet, not only once per flow. This will also affect the 283 reliability of the heuristics. 285 Generally, an intermediate node runs heuristics only for the first 286 few packets of the new flow (i.e. the new IPsec SA). After those few 287 packets, the node detects parameters of the IPsec flow, it skips 288 detection heuristics, and it can perform direct packet-inspecting 289 action based on its own policy. Once detected, ESP-NULL packets will 290 never be detected as encrypted ESP packets, meaning that valid ESP- 291 NULL packets will never bypass the deep inspection. 293 The only failure mode of these heuristics is to assume encrypted ESP 294 packets are ESP-NULL packets, thus causing completely random packet 295 data to be deeply inspected. An attacker can easily send random- 296 looking ESP-NULL packets which will cause heuristics to detect 297 packets as encrypted ESP, but that is no worse than sending non-ESP 298 fuzz through an intermediate node. The only way an ESP-NULL flow can 299 be mistaken for an encrypted ESP flow is if the ESP-NULL flow uses an 300 authentication algorithm of which the packet inspector has no 301 knowledge. 303 For hardware implementations all the flow lookup based on the ESP 304 next header number (50), source address, destination address, and SPI 305 can be done by the hardware (there is usually already similar 306 functionality there, for TCP/UDP flows). The heuristics can be 307 implemented by the hardware, but using software will allow faster 308 updates when new protocol modifications come out or new protocols 309 need support. 311 As described in Section 7, UDP encapsulated ESP traffic may also have 312 have NAPT applied to it, and so there is already a 5-tuple state in 313 the stateful inspection gateway. 315 4. IPsec flows 317 ESP is a stateful protocol, meaning there is state stored in both end 318 nodes of the ESP IPsec SA, and the state is identified by the pair of 319 destination IP and SPI. End nodes also often fix the source IP 320 address in an SA unless the destination is a multicast group. 321 Typically most (if not all) flows of interest to an intermediate 322 device are unicast, so it is safer to assume the receiving node also 323 uses a source address, and the intermediate device should therefore 324 do the same. In some cases this might cause extraneous cached ESP 325 IPsec SA flows, but by using the source address two distinct flows 326 will never be mixed. For sites which heavily use multicast, such 327 traffic is deterministically identifiable (224.0.0.0/4 for IPv4 and 328 ff00::0/8 for IPv6), and an implementation can save the space of 329 multiple cache entries for a multicast flow by checking the 330 destination address first. 332 When the intermediate device sees a new ESP IPsec flow, i.e. a new 333 flow of ESP packets where the source address, destination address, 334 and SPI number forms a triplet which has not been cached, it will 335 start the heuristics to detect whether this flow is ESP-NULL or not. 336 These heuristics appear in Section 8. 338 When the heuristics finish, they will label the flow as either 339 encrypted (which tells that packets in this flow are encrypted, and 340 cannot be ESP-NULL packets) or as ESP-NULL. This information, along 341 with the ESP-NULL parameters detected by the heuristics, is stored to 342 a flow cache, which will be used in the future when processing 343 packets of the same flow. 345 Both encrypted ESP and ESP-NULL flows are processed based on the 346 local policy. In normal operation encrypted ESP flows are passed 347 through or dropped per local policy, and ESP-NULL flows are passed to 348 the deep inspection engine. Local policy will also be used to 349 determine other packet-processing parameters. Local policy issues 350 will be clearly marked in this document to ease implementation. 352 In some cases the heuristics cannot determine the type of flow from a 353 single packet, and in that case it might need multiple packets before 354 it can finish the process. In those cases the heuristics return 355 "unsure" status. In that case the packet processed based on the 356 local policy and flow cache is updated with "unsure" status. Local 357 policy for "unsure" packets could range from dropping (which 358 encourages end-node retransmission) to queuing (which may preserve 359 delivery, at the cost of artificially inflating round-trip times if 360 they are measured). When the next packet to the flow arrives, it is 361 heuristically processed again, and the cached flow may continue to be 362 "unsure", marked as ESP, or marked as an ESP-NULL flow. 364 There are several reasons why a single packet might not be enough to 365 detect type of flow. One of them is that the next header number was 366 unknown, i.e. if heuristics do not know about the protocol for the 367 packet, it cannot verify it has properly detected ESP-NULL 368 parameters, even when the packet otherwise looks like ESP-NULL. If 369 the packet does not look like ESP-NULL at all, then encrypted ESP 370 status can be returned quickly. As ESP-NULL heuristics need to know 371 the same protocols as a deep inspection device, an ESP-NULL instance 372 of an unknown protocol can be handled the same way as a cleartext 373 instance of the same unknown protocol. 375 5. Deep Inspection Engine 377 A deep inspection engine running on an intermediate node usually 378 checks deeply into the packet and performs policy decisions based on 379 the contents of the packet. The deep inspection engine should be 380 able to tell the difference between success, failure, and garbage. 381 Success means that a packet was successfully checked with the deep 382 inspection engine, and it passed the checks and is allowed to be 383 forwarded. Failure means that a packet was successfully checked but 384 the actual checks done indicated that packets should be dropped, i.e. 385 the packet contained a virus, was a known attack, or something 386 similar. 388 Garbage means that the packet's protocol headers or other portions 389 were unparseable. For the heuristics, it would be useful if the deep 390 inspection engine can differentiate the garbage and failure cases, as 391 garbage cases can be used to detect certain error cases (e.g. where 392 the ESP-NULL parameters are incorrect, or the flow is really an 393 encrypted ESP flow, not an ESP-NULL flow). 395 If the deep inspection engine will only return failure for all 396 garbage packets in addition to real failure cases, then a system 397 implementing the ESP-NULL heuristics cannot recover from error 398 situations quickly. 400 6. Special and Error Cases 402 There is a small probability that an encrypted ESP packet (which 403 looks like it contains completely random bytes) will have plausible 404 bytes in expected locations, such that heuristics will detect the 405 packet as an ESP-NULL packet instead of detecting that it is 406 encrypted ESP packet. The actual probabilities will be computed 407 later in this document. Such a packet will not cause problems, as 408 the deep inspection engine will most likely reject the packet and 409 return that it is garbage. If the deep inspection engine is 410 rejecting a high number of packets as garbage, it might indicate an 411 original ESP-NULL detection for the flow was wrong (i.e. an encrypted 412 ESP flow was improperly detected as ESP-NULL). In that case, the 413 cached flow should be invalidated and discovery should happen again. 415 Each ESP-NULL flow should also keep statistics about how many packets 416 have been detected as garbage by deep inspection, how many have 417 passed checks, or how many have failed checks with policy violations 418 (i.e. failed because of actual inspection policy failures, not 419 because the packet looked like garbage). If the number of garbage 420 packets suddenly increases (e.g. most of the packets start to be look 421 like garbage according to the deep inspection engine), it is possible 422 the old ESP-NULL SA was replaced by an identical-SPI encrypting ESP 423 SA. If both ends use random SPI generation, this is a very unlikely 424 situation (1 in 2^32), but it is possible that some nodes reuse SPI 425 numbers (e.g. a 32-bit memory address of the SA descriptor), thus 426 this situation needs to be handled. 428 Actual limits for cache invalidation are local policy decisions. 429 Sample invalidation policies include: 50% of packets marked as 430 garbage within a second; or if a deep inspection engine cannot 431 differentiate between garbage and failure, failing more than 95% of 432 packets in last 10 seconds. For implementations that do not 433 distinguish between garbage and failure, failures should not be 434 treated too quickly as indication of SA reuse. Often, single packets 435 cause state-related errors that block otherwise normal packets from 436 passing. 438 7. UDP encapsulation 440 The flow lookup code needs to detect UDP packets to or from port 4500 441 in addition to the ESP packets, and perform similar processing to 442 them after skipping the UDP header. Port-translation by NAT often 443 rewrites what was originally 4500 into a different value, which means 444 each unique port pair constitutes a separate IPsec flow. I.e. UDP 445 encapsulated IPsec flows are identified by the source and destination 446 IP, source and destination port number and SPI number. As devices 447 might be using MOBIKE ([RFC4555]), that also means that the flow 448 cache should be shared between the UDP encapsulated IPsec flows and 449 non encapsulated IPsec flows. As previously mentioned, 450 differentiating between garbage and actual policy failures will help 451 in proper detection immensely. 453 Because the checks are run for packets having just source port 4500 454 or packets having just destination port 4500, this might cause checks 455 to be run for non-ESP traffic too. Some traffic may randomly use 456 port 4500 for other reasons, especially if a port-translating NAT is 457 involved. The UDP encapsulation processing should also be aware of 458 that possibility. 460 8. Heuristic Checks 462 Normally, HMAC-SHA1-96 or HMAC-MD5-96 gives 1 out of 2^96 probability 463 that a random packet will pass the HMAC test. This yields a 464 99.999999999999999999999999998% probability that an end node will 465 correctly detect a random packet as being invalid. This means that 466 it should be enough for an intermediate device to check around 96 467 bits from the input packet. By comparing them against known values 468 for the packet, a deep inspection engine gains more or less the same 469 probability as an end node is using. This gives an upper limit of 470 how many bits heuristics need to check - there is no point of 471 checking much more than that many bits (since that same probability 472 is acceptable for the end node). In most of the cases the 473 intermediate device does not need that high probability, perhaps 474 something around 32-64 bits is enough. 476 IPsec's ESP has a well-understood packet layout, but its variable- 477 length fields reduce the ability of pure algorithmic matching to one 478 requiring heuristics and assigning probabilities. 480 8.1. ESP-NULL format 482 The ESP-NULL format is as follows: 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Security Parameters Index (SPI) | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Sequence Number | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | IV (optional) | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Payload Data (variable) | 494 ~ ~ 495 | | 496 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | | Padding (0-255 bytes) | 498 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | | Pad Length | Next Header | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Integrity Check Value-ICV (variable) | 502 ~ ~ 503 | | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Figure 1 508 The output of the heuristics should provide information about whether 509 the packet is encrypted ESP or ESP-NULL. In case it is ESP-NULL the 510 heuristics should also provide the Integrity Check Value (ICV) field 511 length and the Initialization Vector (IV) length. 513 The currently defined ESP authentication algorithms have 4 different 514 lengths for the ICV field. 516 Different ICV lengths for different algorithm: 518 Algorithm ICV Length 519 ------------------------------- ---------- 520 AUTH_HMAC_MD5_96 96 521 AUTH_HMAC_SHA1_96 96 522 AUTH_AES_XCBC_96 96 523 AUTH_AES_CMAC_96 96 524 AUTH_HMAC_SHA2_256_128 128 525 AUTH_HMAC_SHA2_384_192 192 526 AUTH_HMAC_SHA2_512_256 256 528 Figure 2 530 In addition to the ESP authentication algorithms listed above, there 531 is also encryption algorithm ENCR_NULL_AUTH_AES_GMAC which does not 532 provide confidentiality but provides authentication, just like ESP- 533 NULL does. This algorithm has ICV Length of 128 bits, and it also 534 requires eight bytes of IV. 536 In addition to the ICV length, there are also two possible values for 537 IV lengths: zero bytes (default) and eight bytes (for 538 ENCR_NULL_AUTH_AES_GMAC). Detecting the IV length requires 539 understanding the payload, i.e. the actual protocol data (meaning 540 TCP, UDP, etc). This is required to distinguish the optional IV from 541 the actual protocol data. How well IV can be distinguished from the 542 actual protocol data depends how the IV is generated. If IV is 543 generated using a method that generates random looking data (i.e. 544 encrypted counter etc) then distinguishing protocol data from IV is 545 quite easy. If an IV is a counter or similar non-random value, then 546 there are more possibilities for error. If the protocol (also known 547 as the, "next header") of the packet is one that is not supported by 548 the heuristics, then detecting the IV length is impossible, thus the 549 heuristics cannot finish. In that case, the heuristics return 550 "unsure" and requires further packets. 552 This document does not cover RSA authentication in ESP ([RFC4359]), 553 as it is considered being beyond the scope of this document. 555 8.2. Self Describing Padding Check 557 Before obtaining the next header field, the ICV length must be 558 measured. Four different ICV lengths lead to four possible places 559 for the pad length and padding. Implementations must be careful when 560 trying larger sizes of ICV such that the inspected bytes do not 561 belong to data that is not payload data. For example, a ten-byte 562 ICMP echo request will have zero-length padding, but any checks for 563 256-bit ICVs will inspect sequence number or SPI data if the packet 564 actually contains a 96-bit or 128-bit ICV. 566 ICV lengths should always be checked from shortest to longest. It is 567 much more likely to obtain valid-looking padding bytes in the 568 cleartext part of the payload than from the ICV field of a longer ICV 569 than what is currently inspected. For example, if a packet has a 96- 570 bit ICV and the implementation starts first checking for a 256-bit 571 ICV, it is possible that the cleartext part of the payload contains 572 valid-looking bytes. If done in the other order, i.e. a packet 573 having a 256-bit ICV and the implementation checks for a 96-bit ICV 574 first, the inspected bytes are part of the longer ICV field, and 575 should be indistinguishable from random noise. 577 Each ESP packet always has between 0-255 bytes of padding, and 578 payload, pad length, and next header are always right aligned within 579 a 4-byte boundary. Normally implementations use minimal amount of 580 padding, but the heuristics method would be even more reliable if 581 some extra padding is added. The actual padding data has bytes 582 starting from 01 and ending to the pad length, i.e. exact padding and 583 pad length bytes for 4 bytes of padding would be 01 02 03 04 04. 585 Two cases of ESP-NULL padding are matched bytes (like the 04 04 shown 586 above), or the zero-byte padding case. In cases where there is one 587 or more bytes of padding, a node can perform a very simple and fast 588 test -- a sequence of N N in any of those four locations. Given four 589 two-byte locations (assuming the packet size allows all four possible 590 ICV lengths), the upper-bound probability of finding a random 591 encrypted packet that exhibits non-zero length ESP-NULL properties 592 is: 594 1 - (1 - 255 / 65536) ^ 4 == 0.015 == 1.5% 596 In the cases where there is 0 bytes of padding, a random encrypted 597 ESP packet has: 599 1 - (1 - 1 / 256) ^ 4 == 0.016 == 1.6%. 601 Together, both cases yields a 3.1% upper-bound chance of 602 misclassifying an encrypted packet as an ESP-NULL packet. 604 In the matched bytes case, further inspection (counting the pad bytes 605 backward and downward from the pad-length match) can reduce the 606 number of misclassified packets further. A padding length of 255 607 means a specific 256^254 sequence of bytes must occur. This 608 virtually eliminates pairs of 'FF FF' as viable ESP-NULL padding. 609 Every one of the 255 pairs for padding length N has only a 1 / 256^N 610 probability of being correct ESP-NULL padding. This shrinks the 611 aforementioned 1.5% of matched-pairs to virtually nothing. 613 At this point a maximum of 1.6% of possible byte values remain, so 614 the next header number is inspected. If the next header number is 615 known (and supported) then the packet can be inspected based on the 616 next header number. If the next header number is unknown (i.e. not 617 any of those with protocol checking support) the packet is marked 618 "unsure", because there is no way to detect the IV length without 619 inspecting the inner protocol payload. 621 There are six different next header fields which are in common use 622 (TCP (6), UDP (17), ICMP (1), SCTP (132), IPv4 (4) and IPv6 (41)), 623 and if IPv6 is in heavy use, that number increases to nine (Fragment 624 (44), ICMPv6 (58), and IPv6 options (60)). To ensure that no packet 625 is misinterpreted as an encrypted ESP packet even when it is an ESP- 626 NULL packet, a packet cannot be marked as a failure even when the 627 next header number is one of those which is not known and supported. 628 In those cases the packets are marked as "unsure". 630 An intermediate node's policy, however, can aid in detecting an ESP- 631 NULL flow even when the protocol is not a common-case one. By 632 counting how many "unsure" returns obtained via heuristics, and after 633 the receipt of a consistent, but unknown, next-header number in same 634 location (i.e. likely with the same ICV length), the node can 635 conclude that the flow has high probability of being ESP-NULL (since 636 it is unlikely that so many packets would pass the integrity check at 637 the destination unless they are legitimate). The flow can be 638 classified as ESP-NULL with a known ICV length, but an unknown IV 639 length. 641 Fortunately, in unknown protocol cases the IV length does not matter. 642 If the protocol is unknown to the heuristics, it will most likely be 643 unknown by the deep inspection engine also. It is therefore 644 important that heuristics should support at least those same 645 protocols as the deep inspection engine does. Upon receipt of any 646 inner next header number that is known by the heuristics (and deep 647 inspection engine), the heuristics can detect the IV length properly. 649 8.3. Protocol Checks 651 Generic protocol checking is much easier with pre-existing state. 652 For example, when many TCP / UDP flows are established over one IPsec 653 SA, a rekey produces a new SA which needs heuristics to detect its 654 parameters, and those heuristics benefit from the existing TCP / UDP 655 flows which were present in the previous IPsec SA. In that case it 656 is just enough to check that if a new IPsec SA has packets belonging 657 to the flows of some other IPsec SA (previous IPsec SA before rekey), 658 and if those flows are already known by the deep inspection engine, 659 it will give a strong indication that the new SA is really ESP-NULL. 661 The worst case scenario is when an end node starts up communication, 662 i.e. it does not have any previous flows through the device. 663 Heuristics will run on the first few packets received from the end 664 node. The later subsections mainly cover these start-up cases, as 665 they are the most difficult. 667 In the protocol checks there are two different types of checks. The 668 first check is for packet validity, i.e. certain locations must 669 contain specific values. For example, an inner IPv4 header of an 670 IPv4 tunnel packet must have its 4-bit version number set to 4. If 671 it does not, the packet is not valid, and can be marked as a failure. 672 Other positions depending on ICV and IV lengths must also be checked, 673 and if all of them are failures, then the packet is a failure. If 674 any of the checks are "unsure" the packet is marked as such. 676 The second type of check is for variable, but easy-to-parse values. 677 For example, the 4-bit header length field of an inner IPv4 packet. 678 It has a fixed value (5) as long as there are no inner IPv4 options. 679 If the header-length has that specific value, the number of known 680 "good" bits increases. If it has some other value, the known "good" 681 bit count stays the same. A local policy might include reaching a 682 bit count that is over a threshold (for example 96 bits), causing a 683 packet to be marked as valid. 685 8.3.1. TCP checks 687 When the first TCP packet is fed to the heuristics, it is most likely 688 going to be the SYN packet of the new connection, thus it will have 689 less useful information than other later packets might have. The 690 best valid packet checks include: checking that header length and 691 flags have valid values; checking source and destination port 692 numbers, which in some cases can be used for heuristics (but in 693 general they cannot be reliably distinguished from random numbers 694 apart from some well-known ports like 25/80/110/143). 696 The most obvious field, TCP checksum, might not be usable, as it is 697 possible that the packet has already transited a NAT box which 698 changed the IP addresses but assumed any ESP payload was encrypted 699 and did not fix the transport checksums with the new IP addresses. 700 Thus the IP numbers used in the checksum are wrong, thus the checksum 701 is wrong. If the checksum is correct that can again be used to 702 increase the valid bit count, but verifying checksums is a costly 703 operation, thus skipping that check might be best unless there is 704 hardware to help the calculation. Window size, urgent pointer, 705 sequence number, and acknowledgement numbers can be used, but there 706 is not one specific known value for them. 708 One good method of detection is if a packet is dropped then the next 709 packet will most likely be a retransmission of the previous packet. 710 Thus if two packets are received with the same source, and 711 destination port numbers, and where sequence numbers are either same 712 or right after each other, then it's likely a TCP packet has been 713 correctly detected. This heuristic is most helpful when only one 714 packet is outstanding. For example, if a TCP SYN packet is lost (or 715 dropped because of policy), the next packet would always be a 716 retransmission of the same TCP SYN packet. 718 Existing deep inspection engines usually do very good TCP flow 719 checking already, including flow tracking, verification of sequence 720 numbers, and reconstruction of the whole TCP flow. Similar methods 721 can be used here, but they are implementation-dependent and not 722 described here. 724 8.3.2. UDP checks 726 UDP header has even more problems than the TCP header, as UDP has 727 even less known data. The checksum has the same problem as the TCP 728 checksum, due to NATs. The UDP length field might not match the 729 overall packet length, as the sender is allowed to include TFC 730 (traffic flow confidentiality, see section 2.7 of IP Encapsulating 731 Security Payload document [RFC4303]) padding. 733 With UDP packets similar multiple packet methods can be used as with 734 TCP, as UDP protocols usually include several packets using same port 735 numbers going from one end node to another, thus receiving multiple 736 packets having a known pair of UDP port numbers is good indication 737 that the heuristics have passed. 739 Some UDP protocols also use identical source and destination port 740 numbers, thus that is also a good check. 742 8.3.3. ICMP checks 744 As ICMP messages are usually sent as return packets for other 745 packets, they are not very common packets to get as first packets for 746 the SA, the ICMP ECHO_REQUEST message being a noteworthy exception. 747 ICMP ECHO_REQUEST has a known type and code, identifier, and sequence 748 number. The checksum, however, might be incorrect again because of 749 NATs. 751 For ICMP error messages, the ICMP message contains part of the 752 original IP packet inside. Then the same rules which are used to 753 detect IPv4/IPv6 tunnel checks can be used. 755 8.3.4. SCTP checks 757 SCTP [RFC4960] has a self-contained checksum, which is computed over 758 the SCTP payload and is not affected by NATs unless the NAT is SCTP- 759 aware. Even more than the TCP and UDP checksums, the SCTP checksum 760 is expensive, and may be prohibitive even for deep-packet 761 inspections. 763 SCTP chunks can be inspected to see if their lengths are consistent 764 across the total length of the IP datagram, so long as TFC padding is 765 not present. 767 8.3.5. IPv4 and IPv6 Tunnel checks 769 In cases of tunneled traffic the packet inside contains a full IPv4 770 or IPv6 packet. Many fields are usable. For IPv4 those fields 771 include version, header length, total length (again TFC padding might 772 confuse things there), protocol number, and 16-bit header checksum. 773 In those cases the intermediate device should give the decapsulated 774 IP packet to the deep inspection engine. IPv6 has fewer usable 775 fields, but the version number, packet length (modulo TFC confusion) 776 and next-header all can be used by deep-packet inspection. 778 If all traffic going through the intermediate device is either from 779 or to certain address block(s) (for example, either to or from the 780 company intranet prefix), this can also be checked by the heuristics. 782 9. Security Considerations 784 Attackers can always bypass ESP-NULL deep packet inspection by using 785 encrypted ESP (or some other encryption or tunneling method) instead, 786 unless the intermediate node's policy requires dropping of packets 787 that it cannot inspect. Ultimately the responsibility for performing 788 deep inspection, or allowing intermediate nodes to perform deep 789 inspection, must rest on the end nodes. I.e. if a server allows 790 encrypted connections also, then an attacker who wants to attack the 791 server and wants to bypass a deep inspection device in the middle, 792 will use encrypted traffic. This means that the protection of the 793 whole network is only as good as the policy enforcement and 794 protection of the end node. One way to enforce deep inspection for 795 all traffic, is to forbid encrypted ESP completely, in which case 796 ESP-NULL detection is easier, as all packets must be ESP-NULL based 797 on the policy (heuristics may still be needed to find out the IV and 798 ICV lengths, unless further policy restrictions eliminate the 799 ambiguities). 801 Section 3 discusses failure modes of the heuristics. An attacker can 802 poison flows, tricking inspectors into ignoring legitimate ESP-NULL 803 flows, but that is no worse than injecting fuzz. 805 Forcing use of ESP-NULL everywhere inside the enterprise, so that 806 accounting, logging, network monitoring, and intrusion detection all 807 work, increases the risk of sending confidential information where 808 eavesdroppers can see it. 810 10. IANA Considerations 812 No IANA assignments are needed. 814 11. References 816 11.1. Normative References 818 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 819 Its Use With IPsec", RFC 2410, November 1998. 821 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 822 Internet Protocol", RFC 4301, December 2005. 824 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 825 December 2005. 827 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 828 RFC 4303, December 2005. 830 11.2. Informative References 832 [I-D.bhatia-ipsecme-esp-null] 833 Bhatia, M., "Identifying ESP-NULL Packets", 834 draft-bhatia-ipsecme-esp-null-00 (work in progress), 835 December 2008. 837 [I-D.hoffman-esp-null-protocol] 838 Hoffman, P. and D. McGrew, "An Authentication-only Profile 839 for ESP with an IP Protocol Identifier", 840 draft-hoffman-esp-null-protocol-00 (work in progress), 841 August 2007. 843 [I-D.ietf-ipsecme-traffic-visibility] 844 Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped ESP 845 for Traffic Visibility", 846 draft-ietf-ipsecme-traffic-visibility-12 (work in 847 progress), January 2010. 849 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 850 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 851 RFC 3948, January 2005. 853 [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within 854 Encapsulating Security Payload (ESP) and Authentication 855 Header (AH)", RFC 4359, January 2006. 857 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 858 (MOBIKE)", RFC 4555, June 2006. 860 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 861 Requirements for Encapsulating Security Payload (ESP) and 862 Authentication Header (AH)", RFC 4835, April 2007. 864 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 865 RFC 4960, September 2007. 867 Appendix A. Example Pseudocode 869 This appendix is meant for the implementors. It does not include all 870 the required checks, and this is just example pseudocode, so final 871 implementation can be very different. It mostly lists things that 872 need to be done, but implementations can optimize steps depending on 873 their other parts. For example, implementation might combine 874 heuristics and deep inspection tightly together. 876 A.1. Fastpath 878 The following example pseudocode show the fastpath part of the packet 879 processing engine. This part is usually implemented in hardware. 881 //////////////////////////////////////////////////////////// 882 // This pseudocode uses following variables: 883 // 884 // SPI_offset: Number of bytes between start of protocol 885 // data and SPI. This is 0 for ESP, and 886 // 8 for UDP encapsulated ESP (i.e skipping 887 // UDP header). 888 // 889 // IV_len: Length of the IV of the ESP-NULL packet. 890 // 891 // ICV_len: Length of the ICV of the ESP-NULL packet. 892 // 893 // State: State of the packet, i.e. ESP-NULL, ESP, or 894 // unsure. 895 // 896 // Also following data is taken from the packet: 897 // 898 // IP_total_len: Total IP packet length 899 // IP_hdr_len: Header length of IP packet in bytes 900 // IP_Src_IP: Source address of IP packet 901 // IP_Dst_IP: Destination address of IP packet 902 // 903 // UDP_len: Length of the UDP packet taken from UDP header. 904 // UDP_src_port: Source port of UDP packet. 905 // UDP_dst_port: Destination port of UDP packet. 906 // 907 // SPI: SPI number from ESP packet. 908 // 909 // Protocol: Actual protocol number of the protocol inside 910 // ESP-NULL packet. 911 // Protocol_off: Calculated offset to the protocol payload data 912 // inside ESP-NULL packet. 914 //////////////////////////////////////////////////////////// 915 // This is the main processing code for the packet 916 // This will check if the packet requires ESP processing, 917 // 918 Process packet: 919 * If IP protocol is ESP 920 * Set SPI_offset to 0 bytes 921 * Goto Process ESP 922 * If IP protocol is UDP 923 * Goto Process UDP 924 * If IP protocol is WESP 925 // For information about WESP processing see WESP 926 // specification. 927 * Continue WESP processing 928 * Continue Non-ESP processing 930 //////////////////////////////////////////////////////////// 931 // This code is run for UDP packets, and it checks if the 932 // packet is UDP encapsulated UDP packet, or UDP 933 // encapsulated IKE packet, or keepalive packet. 934 // 935 Process UDP: 936 // Reassembly is not mandatory here, we could 937 // do reassembly also only after detecting the 938 // packet being UDP encapsulated ESP packet, but 939 // that would complicated the pseudocode here 940 // a lot, as then we would need to add code 941 // for checking if the UDP header is in this 942 // packet or not. 943 // Reassembly is to simplify things 944 * If packet is fragment 945 * Do full reassembly before processing 946 * If UDP_src_port != 4500 and UDP_dst_port != 4500 947 * Continue Non-ESP processing 948 * Set SPI_offset to 8 bytes 949 * If UDP_len > 4 and first 4 bytes of UDP packet are 0x000000 950 * Continue Non-ESP processing (pass IKE-packet) 951 * If UDP_len > 4 and first 4 bytes of UDP packet are 0x000002 952 * Continue WESP processing 953 * If UDP_len == 1 and first byte is 0xff 954 * Continue Non-ESP processing (pass NAT-Keepalive Packet) 955 * Goto Process ESP 957 //////////////////////////////////////////////////////////// 958 // This code is run for ESP packets (or UDP encapsulated ESP 959 // packets). This checks if IPsec flow is known, and 960 // if not calls heuristics. If IPsec flow is known 961 // then it continues processing based on the policy. 963 // 964 Process ESP: 965 * If packet is fragment 966 * Do full reassembly before processing 967 * If IP_total_len < IP_hdr_len + SPI_offset + 4 968 // If this packet was UDP encapsulated ESP packet then 969 // this might be valid UDP packet which might 970 // be passed or dropped depending on policy 971 * Continue normal packet processing 972 * Load SPI from IP_hdr_len + SPI_offset 973 * Initialize State to ESP 974 // In case this was UDP encapsulated ESP then use UDP_src_port and 975 // UDP_dst_port also when finding data from SPI cache. 976 * Find IP_Src_IP + IP_Dst_IP + SPI from SPI cache 977 * If SPI found 978 * Load State, IV_len, ICV_len from cache 979 * If SPI not found or State is unsure 980 * Call Autodetect ESP parameters (drop to slowpath) 981 * If State is ESP 982 * Continue Non-ESP-NULL processing 983 * Goto Check ESP-NULL packet 985 //////////////////////////////////////////////////////////// 986 // This code is run for ESP-NULL packets, and this 987 // finds out the data required for deep inspection 988 // engine (protocol number, and offset to data) 989 // and calls the deep inspection engine. 990 // 991 Check ESP-NULL packet: 992 * If IP_total_len < IP_hdr_len + SPI_offset + IV_len + ICV_len 993 + 4 (spi) + 4 (seq no) + 4 (protocol + padding) 994 // This packet was detected earlier as being part of 995 // ESP-NULL flow, so this means that either ESP-NULL 996 // was replaced with other flow or this is invalid packet. 997 // Either drop or pass the packet, or restart 998 // heuristics based on the policy 999 * Continue packet processing 1000 * Load Protocol from IP_total_len - ICV_len - 1 1001 * Set Protocol_off to 1002 IP_hdr_len + SPI_offset + IV_len + 4 (spi) + 4 (seq no) 1003 * Do normal deep inspection on packet. 1005 Figure 3 1007 A.2. Slowpath 1009 The following example pseudocode show the actual heuristics part of 1010 the packet processing engine. This part is usually implemented in 1011 software. 1013 //////////////////////////////////////////////////////////// 1014 // This pseudocode uses following variables: 1015 // 1016 // SPI_offset, IV_len, ICV_len, State, SPI, 1017 // IP_total_len, IP_hdr_len, IP_Src_IP, IP_Dst_IP 1018 // as defined in fastpath pseudocode. 1019 // 1020 // Stored_Check_Bits:Number of bits we have successfully 1021 // checked to contain acceptable values 1022 // in the actual payload data. This value 1023 // is stored / retrieved from SPI cache. 1024 // 1025 // Check_Bits: Number of bits we have successfully 1026 // checked to contain acceptable values 1027 // in the actual payload data. This value 1028 // is updated during the packet 1029 // verification. 1030 // 1031 // Last_Packet_Data: Contains selected pieces from the 1032 // last packet. This is used to compare 1033 // certain fields of this packet to 1034 // same fields in previous packet. 1035 // 1036 // Packet_Data: Selected pieces of this packet, same 1037 // fields as Last_Packet_Data, and this 1038 // is stored as new Last_Packet_Data to 1039 // SPI cache after this packet is processed. 1040 // 1041 // Test_ICV_len: Temporary ICV length used during tests. 1042 // This is stored to ICV_len when 1043 // padding checks for the packet succeed 1044 // and the packet didn't yet have unsure 1045 // status. 1046 // 1047 // Test_IV_len: Temporary IV length used during tests. 1048 // 1049 // Pad_len: Padding length from the ESP packet. 1050 // 1051 // Protocol: Protocol number of the packet inside ESP 1052 // packet. 1053 // 1054 // TCP.*: Fields from TCP header (from inside ESP) 1055 // UDP.*: Fields from UDP header (from inside ESP) 1056 //////////////////////////////////////////////////////////// 1057 // This code starts the actual heuristics. 1058 // During this the fastpath has already loaded 1059 // State, ICV_len and IV_len in case they were 1060 // found from the SPI cache (i.e. in case the flow 1061 // had unsure status). 1062 // 1063 Autodetect ESP parameters: 1064 // First we check if this is unsure flow, and 1065 // if so, we check next packet against the 1066 // already set IV/ICV_len combination. 1067 * If State is unsure 1068 * Call Verify next packet 1069 * If State is ESP-NULL 1070 * Goto Store ESP-NULL SPI cache info 1071 * If State is unsure 1072 * Goto Verify unsure 1073 // If we failed the test, i.e. State 1074 // was changed to ESP, we check other 1075 // ICV/IV_len values, i.e. fall through 1076 // ICV lengths are tested in order of ICV lengths, 1077 // from shortest to longest. 1078 * Call Try standard algorithms 1079 * If State is ESP-NULL 1080 * Goto Store ESP-NULL SPI cache info 1081 * Call Try 128bit algorithms 1082 * If State is ESP-NULL 1083 * Goto Store ESP-NULL SPI cache info 1084 * Call Try 192bit algorithms 1085 * If State is ESP-NULL 1086 * Goto Store ESP-NULL SPI cache info 1087 * Call Try 256bit algorithms 1088 * If State is ESP-NULL 1089 * Goto Store ESP-NULL SPI cache info 1090 // AUTH_DES_MAC and AUTH_KPDK_MD5 are left out from 1091 // this document. 1092 // If any of those test above set state to unsure 1093 // we mark IPsec flow as unsure. 1094 * If State is unsure 1095 * Goto Store unsure SPI cache info 1096 // All of the test failed, meaning the packet cannot 1097 // be ESP-NULL packet, thus we mark IPsec flow as ESP 1098 * Goto Store ESP SPI cache info 1100 //////////////////////////////////////////////////////////// 1101 // Store ESP-NULL status to the IPsec flow cache. 1102 // 1103 Store ESP-NULL SPI cache info: 1105 * Store State, IV_len, ICV_len to SPI cache 1106 using IP_Src_IP + IP_Dst_IP + SPI as key 1107 * Continue Check ESP-NULL packet 1109 //////////////////////////////////////////////////////////// 1110 // Store encrypted ESP status to the IPsec flow cache. 1111 // 1112 Store ESP SPI cache info: 1113 * Store State, IV_len, ICV_len to SPI cache 1114 using IP_Src_IP + IP_Dst_IP + SPI as key 1115 * Continue Check non-ESP-NULL packet 1117 //////////////////////////////////////////////////////////// 1118 // Store unsure flow status to IPsec flow cache. 1119 // Here we also store the Check_Bits. 1120 // 1121 Store unsure SPI cache info: 1122 * Store State, IV_len, ICV_len, 1123 Stored_Check_Bits to SPI cache 1124 using IP_Src_IP + IP_Dst_IP + SPI as key 1125 * Continue Check unknown packet 1127 //////////////////////////////////////////////////////////// 1128 // Verify this packet against the previously selected 1129 // ICV_len and IV_len values. This will either 1130 // fail (and set state to ESP to mark we do not yet 1131 // know what type of flow this is), or it will 1132 // increment Check_Bits. 1133 // 1134 Verify next packet: 1135 // We already have IV_len, ICV_len and State loaded 1136 * Load Stored_Check_Bits, Last_Packet_Data from SPI Cache 1137 * Set Test_ICV_len to ICV_len, Test_IV_len to IV_len 1138 * Initialize Check_Bits to 0 1139 * Call Verify padding 1140 * If verify padding returned Failure 1141 // Initial guess was wrong, restart 1142 * Set State to ESP 1143 * Clear IV_len, ICV_len, State, 1144 Stored_Check_Bits, Last_Packet_Data 1145 from SPI Cache 1146 * Return 1147 // Ok, padding check succeeded again 1148 * Call Verify packet 1149 * If verify packet returned Failure 1150 // Guess was wrong, restart 1151 * Set State to ESP 1152 * Clear IV_len, ICV_len, State, 1153 Stored_Check_Bits, Last_Packet_Data 1154 from SPI Cache 1155 * Return 1156 // It succeeded and updated Check_Bits and Last_Packet_Data store 1157 // them to SPI cache 1158 * Increment Stored_Check_Bits by Check_Bits 1159 * Store Stored_Check_Bits to SPI Cache 1160 * Store Packet_Data as Last_Packet_Data to SPI cache 1161 * Return 1163 //////////////////////////////////////////////////////////// 1164 // This will check if we have already seen enough bits 1165 // acceptable from the payload data, so we can decide 1166 // that this IPsec flow is ESP-NULL flow. 1167 // 1168 Verify unsure: 1169 // Check if we have enough check bits 1170 * If Stored_Check_Bits > configured limit 1171 // We have checked enough bits, return ESP-NULL 1172 * Set State ESP-NULL 1173 * Goto Store ESP-NULL SPI cache info 1174 // Not yet enough bits, continue 1175 * Continue Check unknown packet 1177 //////////////////////////////////////////////////////////// 1178 // Check for standard 96-bit algorithms. 1179 // 1180 Try standard algorithms: 1181 // AUTH_HMAC_MD5_96, AUTH_HMAC_SHA1_96, AUTH_AES_XCBC_96, 1182 // AUTH_AES_CMAC_96 1183 * Set Test_ICV_len to 12, Test_IV_len to 0 1184 * Goto Check packet 1186 //////////////////////////////////////////////////////////// 1187 // Check for 128-bit algorithms, this is only one that 1188 // can have IV, so we need to check different IV_len values 1189 // here too. 1190 // 1191 Try 128bit algorithms: 1192 // AUTH_HMAC_SHA2_256_128, ENCR_NULL_AUTH_AES_GMAC 1193 * Set Test_ICV_len to 16, Test_IV_len to 0 1194 * If IP_total_len < IP_hdr_len + SPI_offset 1195 + Test_IV_len + Test_ICV_len 1196 + 4 (spi) + 4 (seq no) + 4 (protocol + padding) 1197 * Return 1198 * Call Verify padding 1199 * If verify padding returned Failure 1200 * Return 1202 * Initialize Check_Bits to 0 1203 * Call Verify packet 1204 * If verify packet returned Failure 1205 * Goto Try GMAC 1206 // Ok, packet seemed ok, but go now and check if we have enough 1207 // data bits so we can assume it is ESP-NULL 1208 * Goto Check if done for unsure 1210 //////////////////////////////////////////////////////////// 1211 // Check for GMAC macs, i.e. macs having 8 byte IV. 1212 // 1213 Try GMAC: 1214 // ENCR_NULL_AUTH_AES_GMAC 1215 * Set Test_IV_len to 8 1216 * If IP_total_len < IP_hdr_len + SPI_offset 1217 + Test_IV_len + Test_ICV_len 1218 + 4 (spi) + 4 (seq no) + 4 (protocol + padding) 1219 * Return 1220 * Initialize Check_Bits to 0 1221 * Call Verify packet 1222 * If verify packet returned Failure 1223 // Guess was wrong, continue 1224 * Return 1225 // Ok, packet seemed ok, but go now and check if we have enough 1226 // data bits so we can assume it is ESP-NULL 1227 * Goto Check if done for unsure 1229 //////////////////////////////////////////////////////////// 1230 // Check for 192-bit algorithms. 1231 // 1232 Try 192bit algorithms: 1233 // AUTH_HMAC_SHA2_384_192 1234 * Set Test_ICV_len to 24, Test_IV_len to 0 1235 * Goto Check packet 1237 //////////////////////////////////////////////////////////// 1238 // Check for 256-bit algorithms. 1239 // 1240 Try 256bit algorithms: 1241 // AUTH_HMAC_SHA2_512_256 1242 * Set Test_ICV_len to 32, Test_IV_len to 0 1243 * Goto Check packet 1245 //////////////////////////////////////////////////////////// 1246 // This actually does the checking for the packet, by 1247 // first verifying the length, and then self describing 1248 // padding, and if that succeeds, then checks the actual 1249 // payload content. 1251 // 1252 Check packet: 1253 * If IP_total_len < IP_hdr_len + SPI_offset 1254 + Test_IV_len + Test_ICV_len 1255 + 4 (spi) + 4 (seq no) + 4 (protocol + padding) 1256 * Return 1257 * Call Verify padding 1258 * If verify padding returned Failure 1259 * Return 1260 * Initialize Check_Bits to 0 1261 * Call Verify packet 1262 * If verify packet returned Failure 1263 // Guess was wrong, continue 1264 * Return 1265 // Ok, packet seemed ok, but go now and check if we have enough 1266 // data bits so we can assume it is ESP-NULL 1267 * Goto Check if done for unsure 1269 //////////////////////////////////////////////////////////// 1270 // This code checks if we have seen enough acceptable 1271 // values in the payload data, so we can decide that this 1272 // IPsec flow is ESP-NULL flow. 1273 // 1274 Check if done for unsure: 1275 * If Stored_Check_Bits > configured limit 1276 // We have checked enough bits, return ESP-NULL 1277 * Set State ESP-NULL 1278 * Set IV_len to Test_IV_len, ICV_len to Test_ICV_len 1279 * Clear Stored_Check_Bits, Last_Packet_Data from SPI Cache 1280 * Return 1281 // Not yet enough bits, check this is first unsure, if so 1282 // store information. In case there is multiple 1283 // tests succeeding, we always assume the first one 1284 // (the wone using shortest MAC) is the one we want to 1285 // check in the future. 1286 * If State is not unsure 1287 * Set State unsure 1288 // These values will be stored to SPI cache if 1289 // the final state will be unsure 1290 * Set IV_len to Test_IV_len, ICV_len to Test_ICV_len 1291 * Set Stored_Check_Bits as Check_Bits 1292 * Return 1294 //////////////////////////////////////////////////////////// 1295 // Verify self describing padding 1296 // 1297 Verify padding: 1298 * Load Pad_len from IP_total_len - Test_ICV_len - 2 1299 * Verify padding bytes at 1300 IP_total_len - Test_ICV_len - 1 - Pad_len .. 1301 IP_total_len - Test_ICV_len - 2 are 1302 1, 2, ..., Pad_len 1303 * If Verify of padding bytes succeeded 1304 * Return Success 1305 * Return Failure 1307 //////////////////////////////////////////////////////////// 1308 // This will verify the actual protocol content inside ESP 1309 // packet. 1310 // 1311 Verify packet: 1312 // We need to first check things that cannot be set, i.e if any of 1313 // those are incorrect, then we return Failure. For any 1314 / fields which might be correct, we increment the Check_Bits 1315 // for a suitable amount of bits. If all checks pass, then 1316 // we just return Success, and the upper layer will then 1317 // later check if we have enough bits checked already. 1318 * Load Protocol From IP_total_len - Test_ICV_len - 1 1319 * If Protocol TCP 1320 * Goto Verify TCP 1321 * If Protocol UDP 1322 * Goto Verify UDP 1323 // Other protocols can be added here as needed, most likely same 1324 // protocols as deep inspection does 1325 // Tunnel mode checks (protocol 4 for IPv4 and protocol 41 for 1326 // IPv6) is also left out from here to make the document shorter. 1327 * Return Failure 1329 //////////////////////////////////////////////////////////// 1330 // Verify TCP protocol headers 1331 // 1332 Verify TCP: 1333 // First we check things that must be set correctly. 1334 * If TCP.Data_Offset field < 5 1335 // TCP head length too small 1336 * Return Failure 1337 // After that we start to check things that does not 1338 // have one definitive value, but can have multiple possible 1339 // valid values 1340 * If TCP.ACK bit is not set, then check 1341 that TCP.Acknowledgment_number field contains 0 1342 // If ACK bit is not set then the acknowledgment 1343 // field usually contains 0, but I do not think 1344 // RFCs mandate it being zero, so we cannot make 1345 // this a failure if it is not so. 1346 * Increment Check_Bits by 32 1348 * If TCP.URG bit is not set, then check 1349 that TCP.Urgent_Pointer field contains 0 1350 // If URG bit is not set then urgent pointer 1351 // field usually contains 0, but I do not think 1352 // RFCs mandate it being zero, so we cannot make 1353 // this failure if it is not so. 1354 * Increment Check_Bits by 16 1355 * If TCP.Data_Offset field == 5 1356 * Increment Check_Bits by 4 1357 * If TCP.Data_Offset field > 5 1358 * If TCP options format is valid and it is padded correctly 1359 * Increment Check_Bits accordingly 1360 * If TCP options format was garbage 1361 * Return Failure 1362 * If TCP.checksum is correct 1363 // This might be wrong because packet passed NAT, so 1364 // we cannot make this failure case 1365 * Increment Check_Bits by 16 1366 // We can also do normal deeper TCP inspection here, i.e. 1367 // check that SYN/ACK/FIN/RST bits are correct and state 1368 // matches the state of existing flow if this is packet 1369 // to existing flow etc. 1370 // If there is anything clearly wrong in the packet (i.e. 1371 // some data is set to something that it cannot be), then 1372 // this can return Failure, otherwise it should just 1373 // increment Check_Bits matching the number of bits checked. 1374 // 1375 // We can also check things here compared to the last packet 1376 * If Last_Packet_Data.TCP.source port = 1377 Packet_Data.TCP.source_port and 1378 Last_Packet_Data.TCP.destination port = 1379 Packet_Data.TCP.destination port 1380 * Increment Check_Bits by 32 1381 * If Last_Packet_Data.TCP.acknowledgement_number = 1382 Packet_Data.TCP.acknowledgement_number 1383 * Increment Check_Bits by 32 1384 * If Last_Packet_Data.TCP.sequence_number = 1385 Packet_Data.TCP.sequence_number 1386 * Increment Check_Bits by 32 1387 // We can do other similar checks here 1388 * Return Success 1390 //////////////////////////////////////////////////////////// 1391 // Verify UDP protocol headers 1392 // 1393 Verify UDP: 1394 // First we check things that must be set correctly. 1395 * If UDP.UDP_length > IP_total_len - IP_hdr_len - SPI_offset 1396 - Test_IV_len - Test_ICV_len - 4 (spi) 1397 - 4 (seq no) - 1 (protocol) 1398 - Pad_len - 1 (Pad_len) 1399 * Return Failure 1400 * If UDP.UDP_length < 8 1401 * Return Failure 1402 // After that we start to check things that does not 1403 // have one definitive value, but can have multiple possible 1404 // valid values 1405 * If UDP.UDP_checksum is correct 1406 // This might be wrong because packet passed NAT, so 1407 // we cannot make this failure case 1408 * Increment Check_Bits by 16 1409 * If UDP.UDP_length = IP_total_len - IP_hdr_len - SPI_offset 1410 - Test_IV_len - Test_ICV_len - 4 (spi) 1411 - 4 (seq no) - 1 (protocol) 1412 - Pad_len - 1 (Pad_len) 1413 // If there is no TFC padding then UDP_length 1414 // will be matching the full packet length 1415 * Increment Check_Bits by 16 1416 // We can also do normal deeper UDP inspection here. 1417 // If there is anything clearly wrong in the packet (i.e. 1418 // some data is set to something that it cannot be), then 1419 // this can return Failure, otherwise it should just 1420 // increment Check_Bits matching the number of bits checked. 1421 // 1422 // We can also check things here compared to the last packet 1423 * If Last_Packet_Data.UDP.source_port = 1424 Packet_Data.UDP.source_port and 1425 Last_Packet_Data.destination_port = 1426 Packet_Data.UDP.destination_port 1427 * Increment Check_Bits by 32 1428 * Return Success 1430 Figure 4 1432 Authors' Addresses 1434 Tero Kivinen 1435 AuthenTec, Inc. 1436 Fredrikinkatu 47 1437 HELSINKI FIN-00100 1438 FI 1440 Email: kivinen@iki.fi 1442 Daniel L. McDonald 1443 Oracle Corporation 1444 35 Network Drive 1445 MS UBUR02-212 1446 Burlington, MA 01803 1447 USA 1449 Email: danmcd@sun.com