idnits 2.17.1 draft-herbert-udp-magic-numbers-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 15, 2015) is 3115 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 145, but not defined == Unused Reference: 'KEYWORDS' is defined on line 343, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 348, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'I-D.hildebrand-spud-prototype' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nvo3-geneve' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nvo3-gue' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tsvwg-gre-in-udp-encap' is defined on line 395, but no explicit reference was found in the text == Unused Reference: 'RFC7605' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 411, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 415, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-00 -- No information found for draft-ietf-nvo3-vxlan-gpe-00draft-quinn-vxlan-gpe - is the name correct? == Outdated reference: A later version (-05) exists of draft-ietf-nvo3-gue-01 == Outdated reference: A later version (-19) exists of draft-ietf-tsvwg-gre-in-udp-encap-07 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 17 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Informational Facebook 4 Expires: April 17, 2016 L. Yong 5 Huawei USA 6 October 15, 2015 8 UDP Magic Numbers 9 draft-herbert-udp-magic-numbers-01 11 Abstract 13 This specification defines magic numbers in UDP which allow a node to 14 determine or confirm the protocol contained in a UDP payload. This is 15 primarily applicable for encapsulation and transport protocols 16 encapsulated within UDP where intermediate devices, such as middle 17 boxes, need to parse these protocols for providing service. Magic 18 numbers can also be used to multiplex different UDP encapsulated 19 protocols over the same UDP port. 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 29 Internet-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/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright and License Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2 Magic number format . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1 Magic value . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2 Protocol types . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.3 Magic number checksum . . . . . . . . . . . . . . . . . . . 6 65 3 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1 End hosts . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1.1 Required magic numbers . . . . . . . . . . . . . . . . . 6 68 3.1.2 Optional magic numbers . . . . . . . . . . . . . . . . . 6 69 3.1.3 Use with DTLS . . . . . . . . . . . . . . . . . . . . . 7 70 3.2 Intermediate devices . . . . . . . . . . . . . . . . . . . . 7 71 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 72 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 73 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 6.1 Normative References . . . . . . . . . . . . . . . . . . . 8 75 6.2 Informative References . . . . . . . . . . . . . . . . . . 8 76 Appendix A: Example of creating a UDP magic number . . . . . . . . 10 77 Appendix B: Checking magic numbers . . . . . . . . . . . . . . . . 10 78 B.1 Matching a single magic number . . . . . . . . . . . . . . . 10 79 B.2 Matching against a set of magic numbers . . . . . . . . . . 11 80 B.3 Magic number validation . . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 83 1 Introduction 85 Several transport and encapsulation protocols have been defined to be 86 encapsulated within UDP [RFC0768]. In this model, the payload of a 87 UDP packet contains a protocol header and payload for an encapsulated 88 protocol. Transport protocols encapsulated in UDP include QUIC 89 [QUIC], SCTP-in-UDP [RFC6951], and SPUD [I-D.hildebrand-spud- 90 prototype]. Encapsulation protocols include Geneve [I-D.ietf-nvo3- 91 geneve], VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe], GUE [I-D.ietf-nvo3- 92 gue], MPLS-in-UDP [RFC7510], and GRE-in-UDP [I-D.ietf-tsvwg-gre-in- 93 udp-encap]. For various reasons, intermediate devices in a network 94 may want to parse these protocols. For instance, a middlebox would 95 need to parse an encapsulated transport protocol to implement a 96 stateful firewall. To parse the encapsulated protocol in a UDP 97 packet, a node must positively identify the encapsulated protocol. 99 The destination UDP port number is commonly used to interpret the 100 contents of a UDP payload, however this is problematic in 101 intermediate devices for several reasons: 103 - Port numbers can only be correctly interpreted by the endpoints. 104 Interpretation by intermediate devices in the network may be 105 incorrect ([RFC7605]]). 107 - Encapsulation and transport protocols will usually have assigned 108 UDP ports, but they are not restricted to use only those. 110 - UDP encapsulated protocols may use a "substrate" protocol header 111 as espoused in SPUD. Use of a substrate header may be common 112 across several port numbers. Configuring each network device for 113 each port that uses the substrate could be cumbersome. 115 This specification describes UDP magic numbers which allows network 116 nodes to identify UDP encapsulated protocols without relying solely 117 on UDP port numbers. A UDP magic number is a protocol specific, 118 constant value which is logically inserted between the UDP header and 119 the encapsulated protocol header. If a node matches the magic number 120 in a packet to a known protocol's magic number, then it can parse the 121 encapsulated payload per the matched protocol. Each UDP encapsulated 122 protocol uses a different magic number which allows multiplexing 123 multiple encapsulated protocols over the same UDP port. 125 Note that the use of magic numbers is inherently probabilistic. It is 126 possible that a UDP packet may have a payload that inadvertently 127 matches a magic number. The magic number is defined to minimize the 128 probability of this occurring (1/2^^64 assuming that UDP data has a 129 random distribution), nevertheless the probability is non-zero. The 130 consequences of incorrectly matching a UDP packet should be 131 considered for each UDP encapsulated protocol. An encapsulated 132 protocol may include its own verification to ensure correct 133 interpretation. 135 The use of magic numbers to identify UDP encapsulated protocols was 136 specified in the SPUD prototype protocol ([I-D.hildebrand-spud- 137 prototype]) and in "Session Traversal Utilities for NAT (STUN)" 138 ([RFC5389]). This proposal generalizes the concept. 140 1.1 Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 2 Magic number format 148 The UDP magic number is a sixty-four bit value that includes a fixed 149 constant, an encapsulated protocol type, and a checksum. The magic 150 number within a UDP packet is diagrammed below. 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Source port | Destination port | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Length | Checksum | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Magic value = 0xffd871a2 | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Xor'ed protocol | Xor'ed checksum | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | | 164 ~ Encapsulated protocol ~ 165 | | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 The fields of the magic number are: 170 o Magic value: A fixed constant of 0xffd871a2. This value is the 171 same for all encapsulated protocol types. 173 o Xor'ed protocol: Indicates the protocol type of the encapsulated 174 protocol. The value in the field is a protocol type number 175 exclusive or'ed with 0x36b4. 177 o Xor'ed Checksum: Indicates the standard one's complement 178 checksum over the magic number (including the Magic value and 179 Xor'ed Protocol fields). The value in this field is the 180 calculated checksum exclusive or'ed with 0x5ce9. 182 o Encapsulated protocol: This contains the header and payload of 183 the encapsulated protocol. The type for the protocol is 184 indicated in the Xor'ed protocol field. 186 2.1 Magic value 188 The first byte of the Magic value field is 0xff and the other three 189 bytes are a randomly chosen constant. 191 For UDP encapsulated protocols that allow magic number use to be 192 optional, the magic number must be clearly distinguishable from a 193 valid header. Each such protocol must declare that a header which 194 would match the associated magic number is invalid. The value of 0xff 195 as the first byte in the magic number was chosen as a likely value 196 that would indicate an invalid header. It is common that the first 197 byte of a protocol header contains a version number, and most 198 protocols have not gotten past version zero. So if a magic number is 199 received by a node that does not yet support magic numbers, the UDP 200 payload would likely be interpreted as a protocol header with a bad 201 version number; this should result in dropping the packet and not 202 misinterpreting it. In this way, the use of magic numbers can be 203 enabled for many existing protocols with forward compatibility. 205 2.2 Protocol types 207 Protocol types can generally refer to any encapsulation, transport, 208 substrate, or application specific protocol that is encapsulated in 209 UDP for which intermediate devices might need to parse. A protocol 210 type number is encoded in UDP magic numbers to allow intermediate 211 devices to distinguish different payload types while still using a 212 common magic number format. 214 Protocol types are indicated by sixteen bits numbers, and the space 215 is divided into three regions. 217 Numbers 0-49151 are reserved to mirror the assigned UDP port 218 number space. If a port number is assigned to a UDP encapsulated 219 protocol, that same number can be used as the protocol type 220 number. This is allowed for convenience, there is no required 221 correlation between protocol type numbers and UDP port numbers. 223 Numbers 49152-57343 are reserved for assigned protocol types. 225 Numbers 57344-65535 are reserved for private protocol types. 227 The Xor'ed protocol field in a magic number is a protocol type number 228 exclusive or'ed with 0x36b4. 230 2.3 Magic number checksum 232 The magic number checksum is calculated as the standards one 233 complement checksum computed over the sixty-four bit magic number 234 where the Xor'ed checksum field is set to zero for the purposes of 235 calculation. The checksum calculation covers the Magic value and the 236 Xor'ed protocol fields. The Xor'ed checksum field is set to the 237 result of the calculation exclusive or'ed with 0x5ce9. 239 Note that the magic number checksum is performed over constant fields 240 and is itself a constant value per protocol type. An implementation 241 should not need to perform this calculation when processing packets. 242 Appendix A demonstrates how the checksum is applied to create a magic 243 number constant for Generic UDP Encapsulation. 245 The magic number checksum may be used to validate the presence of a 246 well formed UDP magic number. This is demonstrated in Appendix B. 248 3 Usage 250 This section describes the processing of UDP magic numbers on end 251 hosts and intermediate devices. 253 3.1 End hosts 255 The use of UDP magic numbers is enabled on a per port basis. Magic 256 numbers may be required for every UDP packet sent on a port, or may 257 be optional. If a UDP port is assigned to a single protocol, the 258 magic number in packets sent to that port is the one assigned to the 259 protocol. If different encapsulated protocols are multiplexed on the 260 same UDP port, magic numbers for those protocols will be used. 262 3.1.1 Required magic numbers 264 If magic numbers are required for a UDP port, a sender must set the 265 magic number in any packets sent to the destination port. A receiver 266 must check for a valid magic number. If the magic number is valid, 267 that is the Magic value is correct and the protocol type is supported 268 by the receiver for the port, then the packet is accepted. Otherwise, 269 the magic number is not matched so the packet is dropped. 271 3.1.2 Optional magic numbers 273 When magic numbers are optional for a UDP port, a receiver must check 274 if a magic number is present in a received packet. If a magic number 275 is matched for a protocol type supported by the receiver, then the 276 packet must be accepted and the Encapsulated protocol in the packet 277 is processed according to the protocol type. If the magic number is 278 not matched, the packet is still accepted and the UDP payload is 279 processed as a protocol type implied by the port number. 281 If it is not feasible in a protocol to distinguish a magic number 282 from a valid header (MPLS-in-UDP for instance), UDP magic numbers 283 cannot be optional on the protocol's port number. They can be used on 284 a separate port number for which magic numbers would be required. 286 3.1.3 Use with DTLS 288 UDP magic numbers are intended to occupy the first bytes of the UDP 289 payload to facilitate interpretation at middleboxes. When they are 290 used with DTLS [RFC6347], the magic number must precede the DTLS 291 headers. The protocol type in the magic number would refer to the 292 payload type contained in DTLS. 294 3.2 Intermediate devices 296 Intermediate devices may match magic numbers in two ways: 298 - Match both the destination port and magic numbers associated 299 with the port. 301 - Match magic numbers across a range (possibly all) of ports. 303 Matching both the port and magic number is recommended. This is 304 feasible in cases where a UDP encapsulated protocol has an assigned 305 port number. Matching the port number and magic number significantly 306 reduces the possibility of misinterpreting a packet. 308 Matching just the magic number and not a port may be done when UDP 309 encapsulated protocols are used on unassigned ports, or configuring 310 port numbers on intermediate devices is prohibitive. 312 In either case, if a middlebox is able to match a magic number it may 313 parse the encapsulated payload of the packet for the associated 314 protocol. 316 If a middle box does not match a magic number for a packet it should 317 follow default processing for UDP packets. If magic numbers are known 318 to be required for a port, a middlebox may perform some alternative 319 processing when the magic number is not present. This alternative 320 processing should not be more restrictive than had the packet been 321 sent to another arbitrary UDP port. In particular, if UDP packets for 322 other ports would not be dropped, failure to match a magic number 323 should not result in the packet being dropped. 324 4 Security Considerations 326 UDP magic numbers are not a security mechanism and should not 327 increase security risk. 329 5 IANA Considerations 331 IANA will be requested to create a "UDP Magic Number Protocol Type" 332 registry to allocate protocol types. This shall be a registry of 16- 333 bit values along with descriptive strings. The allocation ranges are 334 described in section 2.2. 336 6 References 338 6.1 Normative References 340 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 341 August 1980, . 343 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, DOI 345 10.17487/RFC2119, March 1997, . 348 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, DOI 349 10.17487/RFC1776, April 1 1995, . 352 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, DOI 353 10.17487/RFC1925, April 1 1996, . 356 6.2 Informative References 358 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 359 Control Transmission Protocol (SCTP) Packets for End-Host 360 to End-Host Communication", RFC 6951, May 2013, 361 . 363 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 364 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 365 October 2008, . 367 [QUIC] Roskind, J., "QUIC: Multiplexed Stream Transport Over UDP", 368 http://www.ietf.org/proceedings/88/slides/slides-88- 369 tsvarea-10.pdf 371 [I-D.hildebrand-spud-prototype] Hildebrand, J. and Trammell, B. 372 "Substrate Protocol for User Datagrams (SPUD) Prototype", 373 draft-hildebrand-spud-prototype-03 (work in preogress), 374 March 2015. 376 [I-D.ietf-nvo3-geneve] Gross, J., Sridhar, T., Garg, P., Wright, C., 377 Ganga, I., Agarwal, P., Duda, K., Dutt, D., and J. Hudson, 378 "Geneve: Generic Network Virtualization Encapsulation", 379 draft-ietf-nvo3-geneve-00, May 2015. 381 [I-D.ietf-nvo3-vxlan-gpe] Quinn, P., Manur, R., Kreeger, L., Lewis, 382 D., Maino, F., Smith, M., Agarwal, P., Yong, L., Xu, X, 383 Elzur, U., Garg, P., and Melman, D. "Generic Protocol 384 Extension for VXLAN" draft-ietf-nvo3-vxlan-gpe-00draft- 385 quinn-vxlan-gpe-00, February 2015 387 [I-D.ietf-nvo3-gue] Herbert, T., Yong, L., and Zia, O., "Generic UDP 388 Encapsulation", draft-ietf-nvo3-gue-01 (work in progress), 389 June 2015. 391 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 392 "Encapsulating MPLS in UDP", RFC 7510, April 2015, 393 . 395 [I-D.ietf-tsvwg-gre-in-udp-encap] Crabbe, E., Yong, L., Xu, 396 X., and Herbert, T. "GRE-in-UDP Encapsulation", draft-ietf- 397 tsvwg-gre-in-udp-encap-07, July 2015 399 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 400 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 401 August 2015, . 403 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 404 Security Version 1.2", RFC 6347, January 2012, 405 . 407 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 408 RFC 3514, DOI 10.17487/RFC3514, April 1 2003, 409 . 411 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 412 Acronyms", RFC 5513, DOI 10.17487/RFC5513, April 1 2009, 413 . 415 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, DOI 416 10.17487/RFC5514, April 1 2009, . 419 Appendix A: Example of creating a UDP magic number 421 This section demonstrates how a magic can be created for a UDP 422 encapsulated protocol. For this example we consider Generic UDP 423 Encapsulation (GUE), and assume that the assigned port number is used 424 as the protocol type number. 426 The assigned port number for GUE in 6080 or 0x17c0 in hexadecimal. So 427 the value of the Xor'ed protocol field is: 429 0x17c0 ^ 0x36b4 = 0x2174 431 To compute the magic checksum we first sum the words of the Magic 432 value and the Xor'ed protocol field value computed above: 434 0xffd8 + 0x71a2 + 0x2174 = 0x192ee 436 The result is folded and then complemented: 438 (0x92ee + 1) ^ 0xffff = 0x6d10 440 So the value in the Xor'ed checksum field is: 442 0x6d10 ^ 0x5ce9 = 0x31f9 444 Thus the full 64 bit magic number value for GUE is: 446 0xffd871a2:0x217431f9 448 Appendix B: Checking magic numbers 450 This section provides some guidelines for how to check magic numbers. 452 B.1 Matching a single magic number 454 When a port supports precisely one protocol type there is only one 455 magic number to check. This will be a common case at a receiver where 456 magic numbers are enabled for encapsulated protocols that have 457 assigned ports. Receiver processing in pseudo code may be: 459 dataptr = UDP_payload_ptr 460 good_magic = false 461 PROTO_MAGIC_NUMBER = Pre computed 64 bit value for protocol type 463 if (UDP_payload_length >= 8 && 464 memcmp(UDP_payload_ptr, PROTO_MAGIC_NUMBER, 8) == 0) { 465 /* Magic number matched, skip it for further processing */ 466 dataptr += 8 467 good_magic = true 468 } 470 if (good_magic || magic_numbers_are_optional) 471 process_packet(dataptr) 472 else 473 /* Handle bad packet */ 475 B.2 Matching against a set of magic numbers 477 A host needs to check against a set of magic numbers when different 478 encapsulated protocols are multiplexed over a single port, and an 479 intermediate device checks against a set when matching magic numbers 480 across a range of ports. In either case, the typical method is to 481 check the first four bytes of the UDP payload against the constant 482 magic number value. If this is a match then the protocol type number 483 is extracted and a lookup is performed to find a context. If a 484 context is found, the checksum field in the packet is compared 485 against a precomputed value in the context. In pseudo code this is: 487 dataptr = UDP_payload_ptr; 488 good_magic = false; 490 if (UDP_payload_length >= 8 && 491 *(u32 *)UDP_payload_ptr == 0xffd871a2) { 492 proto = *(u16 *)(UDP_payload_ptr + 4) ^ 0x36b4 493 checksum = *(u16 *)(UDP_payload_ptr + 6) 494 ctx = protocol_lookup(proto) 495 if (ctx && checksum == ctx->checksum) { 496 /* Protocol found and matched */ 497 good_magic = true 498 dataptr += 8; 499 } 500 } 502 if (good_magic) 503 process_as_protocol(dataptr, proto); 504 else 505 /* Handle bad packet */ 507 B.3 Magic number validation 509 A node can validate that a magic number is well formed for any 510 protocol. This requires checking the Magic value is correct and 511 verifying the checksum. In pseudo code this would be: 513 good_magic = false 514 u16 checksum(start, len) /* Checksum function */ 515 if (UDP_payload_length >= 8 && 516 *(u32 *)UDP_payload_ptr == 0xffd871a2) { 517 csum = checksum(UDP_payload_ptr, 6) 518 if (csum ^ 0x5ce9 == *(u16 *)(UDP_payload_ptr + 6)) 519 good_magic = true 520 } 522 Authors' Addresses 524 Tom Herbert 525 Facebook 526 1 Hacker Way 527 Menlo Park, CA 528 US 530 EMail: tom@herbertland.com 532 Lucy Yong 533 Huawei USA 534 5340 Legacy Dr. 535 Plano, TX 75024 536 US 538 Email: lucy.yong@huawei.com