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