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