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