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