idnits 2.17.1 draft-mccann-picklepacket-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 date (December 7, 2010) is 4890 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF P. McCann 3 Internet-Draft 4 Intended status: Standards Track S. Gilbert 5 Expires: June 10, 2011 Motorola, Inc. 6 December 7, 2010 8 Authenticated Middlebox Traversal with the Pickle Packet 9 draft-mccann-picklepacket-01 11 Abstract 13 This document describes the Pickle Packet, a message that can be used 14 to coordinate the opening of a transport connection with various 15 middleboxes that may lie on the path. It contains the DNS names of 16 both the initiator and the responder of the connection and some 17 authentication data. Because the authentication data uses public key 18 cryptography, any middlebox can independently authenticate the 19 initiator and make a policy decision whether to allow or deny the 20 flow based on the DNS names. The Pickle Packet allows for 21 middleboxes to establish state such as firewall pinholes or security 22 associations that can be used to filter out unwanted traffic. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 10, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Bearer Packet Filtering . . . . . . . . . . . . . . . . . 3 60 1.1.1. Filter using Network and Transport Header . . . . . . 3 61 1.1.2. Attack Detection Through Counting Packets . . . . . . 4 62 1.1.3. Filter Using Cookie Value . . . . . . . . . . . . . . 4 63 1.1.4. Cryptographic Header MAC . . . . . . . . . . . . . . . 4 64 1.1.5. Cryptographic Header and Payload MAC . . . . . . . . . 5 65 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 66 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Pickle Packet Structure . . . . . . . . . . . . . . . . . . . 10 68 3.1. Payload Block Types . . . . . . . . . . . . . . . . . . . 14 69 3.1.1. Message Source/Destination Block . . . . . . . . . . . 14 70 3.1.2. Vouch-by-Reference Information Block . . . . . . . . . 18 71 3.1.3. Point-of-Contact Address Block . . . . . . . . . . . . 19 72 3.1.4. Binding Distribution Restriction Block . . . . . . . . 22 73 3.1.5. Authentication Results/Request . . . . . . . . . . . . 24 74 3.1.6. Application Data Block . . . . . . . . . . . . . . . . 27 75 3.1.7. Public Key Signature Block . . . . . . . . . . . . . . 27 76 3.1.8. Symmetric Key Signature Block . . . . . . . . . . . . 29 77 3.1.9. Symmetric Key Encryption Parameters Block . . . . . . 31 78 3.1.10. Pickle Fragment Block . . . . . . . . . . . . . . . . 32 79 4. Domain Name System Binding . . . . . . . . . . . . . . . . . . 32 80 4.1. Representation of Public Keys in DNS . . . . . . . . . . . 32 81 4.2. Vouch-by-Reference Records . . . . . . . . . . . . . . . . 34 82 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 85 8. Normative References . . . . . . . . . . . . . . . . . . . . . 35 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 88 1. Introduction 90 1.1. Bearer Packet Filtering 92 A middle box which processes pickle packets can be used to ensure 93 that packets which are unwanted by the destination host are either 94 filtered out or forwarded using a lower packet scheduling priority 95 than packets which are wanted. Unwanted packets could consist of 96 those from malicious or infected senders which are part of a Denial- 97 of-Service (DoS) attack, or they may be from legitimate senders but 98 sent when either a communication channel on the path or the 99 destination host are congested. Compatibility with senders not 100 capable of generating pickle packets is possible using a lenient 101 filtering policy which forwards their packets with a lower scheduling 102 priority. To prevent congestion of a particular communication 103 channel by a DoS attack, a middlebox may be located just prior to 104 that channel. This is shown in Figure 1. 106 +--------------+ 107 |sources of DoS| 108 |attack packets| 109 +--------------+ 110 | 111 | 112 +--------+ V congestible +-----------+ 113 |original| +----------+ +---------+ channel |ultimate | 114 |sender |-->|IP network|-->|middlebox|-------------->|destination| 115 +--------+ +----------+ +---------+ +-----------+ 117 Figure 1: Middlebox Mitigates Traffic Congestion DoS Attack 119 Several mechanisms are supported for packet filtering. When no 120 network congestion is detected along the path and end host, and no 121 attack is believed to be occurring, middleboxes may use lightweight 122 mechanisms to identify those packets which have been authorized for 123 forwarding. If a middlebox or the end host detects congestion or an 124 attack, it may signal the sender to indicate that a more robust 125 technique should be used to identify its packets as part of a desired 126 traffic flow. These mechanisms are described below. 128 1.1.1. Filter using Network and Transport Header 130 Once a flow is authorized, the middlebox can simply open a pinhole 131 for that flow with no additional security. This would provide a 132 basic level of assurance similar to existing firewalls that protect 133 private networks by requiring a node on the inside to initiate a 134 connection and refusing all outside-initiated connections. The IP 135 source and destination addresses, the transport protocol ID, and the 136 source and destination port numbers of UDP or TCP packets (the five- 137 tuple) can be used to identify packets which are part of a desired 138 flow. If the middlebox detects that some malicious node has learned 139 the five-tuple parameters and is exploiting a pinhole to send DoS 140 traffic, it can escalate the protection to one of the mechanisms 141 outlined below. 143 1.1.2. Attack Detection Through Counting Packets 145 An ESTABLISH pickle packet received by a middlebox contains PCOUNT, 146 the number of subsequent DATA or BARE packets of the traffic flow 147 which the middlebox may forward without having received another 148 ESTABLISH pickle packet for the flow. The middlebox should maintain 149 a count of the number of remaining packets which may be forwarded. 150 If the count reaches zero, local policy of the middlebox should be 151 used to determine whether the subsequent packets on that flow should 152 be dropped or should be forwarded using low packet scheduling 153 priority. Under normal circumstances the count of subsequent packets 154 which are authorized to be forwarded should not reach zero. The 155 original packet sender is responsible for sending enough ESTABLISH 156 packets and high enough PCOUNT values so that under the expected 157 packet loss rates the authorized packets are allowed to traverse the 158 middlebox. If the middlebox detects packets of an authorized flow 159 being deprioritized or dropped due to the count value reaching zero, 160 it should decide whether a DoS attack is suspected and if so, it can 161 escalate the protection to one of the mechanisms outlined below. The 162 packet count attack detection mechanism may be used in combination 163 with other techniques. 165 1.1.3. Filter Using Cookie Value 167 Because an off-path attacker may learn the five-tuple, a slightly 168 more robust protection mechanism is for the middlebox to demand that 169 the sender insert a chosen number (a "cookie" value) into all DATA 170 packets. This would enable the middlebox to quickly recognize which 171 packets were generated by someone with access to the data path, and 172 which came from weak off-path attackers. A packet of the flow which 173 does not contain the expected cookie value in the DATA packet header 174 would be treated as non authentic and the middlebox would update its 175 estimate regarding whether or not an attack is occurring. 177 1.1.4. Cryptographic Header MAC 179 An on-path attacker may be able to read the cookie value from packets 180 in flight. A more robust but more computationally expensive approach 181 is to distribute a shared secret between the sender and the 182 middlebox, and to construct a Message Authentication Code (MAC) that 183 covers the header fields of the DATA packets. This value would 184 change on every DATA packet and so it would be difficult for an 185 attacker to construct a new packet that would validate. The 186 inclusion of a nonce value in the header would prevent the attacker 187 from replaying valid packets, if the middlebox can keep state about 188 previously seen packets. However, an attacker with the power to 189 intercept, delay, and/or drop valid packets might be able to use the 190 header hash to attach a different payload to the message. To defend 191 against these forms of DoS attack, a MAC over the header and payload 192 is required, as described below. 194 1.1.5. Cryptographic Header and Payload MAC 196 This approach also relies on a shared secret distributed between 197 sender and middlebox, but here the MAC covers the entire packet, not 198 just the header. Combined with a nonce in the header, and if the 199 middlebox has the ability to keep state about the packets that have 200 already been seen, this technique would make it extremely difficult 201 for an attacker to spoof a valid data packet or to replay a valid 202 data packet and have it accepted by the middlebox. This technique 203 would be the most robust but also the most computationally expensive. 205 1.2. Requirements Language 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in RFC 2119 [1]. 211 2. Protocol Overview 213 The message sequence chart in Figure 2 shows an example of the 214 signaling which occurs when a pickle packet capable client begins a 215 TCP session with a pickle packet capable server. The path traversed 216 by bearer packets includes middlebox 1, which is near the client, and 217 middlebox 2, which is near the server. In this example the entities 218 are assumed to have not communicated recently and therefore 219 information which could be locally cached must instead be retrieved 220 from a remote entity. Cacheable information includes: the public key 221 of an entity which is looked up at a DNS server; the reputation of an 222 entity which is looked up at the vouching service; and a shared 223 secret created by a Diffie Hellman key exchange between a pair of 224 network entities and used to create message authentication codes sent 225 between them. In this section comments will given regarding the 226 messages of the example to help explain the operation of the 227 protocol. 229 Network Entities and their symbolic identifiers: 231 Client.net Mbox1 DNSc Vouch DNSs Mbox2 Server.net 232 C M1 Dc V Ds M2 S 234 Sequence of Messages: 235 Left Dir Right msg# content 236 ----------------------------- 237 M2 <- S 1) REGISTER (S,Ds) 238 Ds <- M2 2) Lookup Server.net 239 Ds -> M2 3) Public Key PKs 240 V <- M2 4) Lookup Server.net 241 V -> M2 5) Good reputation: Server.net 242 M2 -> S 6) REFLECT (M2,S) external IP 243 Ds <- S 7) Lookup Mbox2.net 244 Ds -> S 8) Public Key PKm2 245 V <- S 9) Lookup Mbox2.net 246 V -> S 10) Good reputation: Mbox2.net 247 M2 <- S 11) REGISTER (S,M2) external IP 248 Ds <- M2 12) REGISTER (M2,Ds) external IP 249 Ds -> M2 13) REFLECT (Ds,M2) registered 250 M2 -> S 14) REFLECT (M2,S) registered 252 Steps 1) through 14) by S, M2, and Ds 253 may also be performed by C, M1, and Dc if 254 C wants to receive inbound connection 255 attempts. 257 C -> Ds 15) lookup Server.net 258 C <- Ds 16) IP w.x.y.z Public Key PKs 259 C -> M1 17) ESTABLISH (C, S) TCP SYN 260 C <- M1 18) REFLECT (M1, C) 261 M1 -> M2 19) ESTABLISH (M1, S) TCP SYN 262 Dc <- M2 20,21) lookup mbox1.net, client.net 263 Dc -> M2 22,23) Public KeysPKm1, PKc 264 V <- M2 24,25) Lookup client.net, mbox1.net 265 V -> M2 26) Good reputation: client.net, mbox1.net 266 M1 <- M2 27) REFLECT (M2, M1) 267 M2 -> S 28) ESTABLISH (M2, S) TCP SYN 268 M2 <- S 29) REFLECT (S, M2) SYN ACK 269 M1 <- M2 30) REFLECT (M2, M1) SYN ACK 270 C <- M1 31) REFLECT (M1, C) SYN ACK 272 Figure 2: Message Sequence Chart If Parties Initially Unknown to Each 273 Other 275 1) The first REGISTER message is sent by Server.net towards the DNS 276 server which it is configured to use in order to bind its name to its 277 current IP address. Along the way, the REGISTER discovers pickle 278 packet middle boxes. Registering via Mbox2 also tells the middlebox 279 that Server.net is capable of processing pickle packets at the 280 included address and that the middlebox does not need to act as a 281 pickle packet proxy. Message 1 contains a pickle packet header as 282 shown in Section 3, in which the message type field is REGISTER, the 283 message source and destination block is included and its field values 284 (shown in Section 3.1.1) are Server.net, and DNSs. The Point-of- 285 Contact Block shown in Figure 6 is also included. The DNS server 286 which Server.net is configured to use should be on a network 287 accesible to all clients with which Server.net wants to communicate, 288 e.g., it should be on the public Internet. Middlebox M2 is on the 289 path between Server.net and the public Internet so it will intercept 290 and process the REGISTER message. 292 2) Because Mbox2 has had no previous contact with Server.net, Mbox2 293 sends message 2 to request the public key of Server.net from the DNS 294 server. Mbox2 uses the public key to validate the Address 295 Registration Block. 297 3) The public key of Server.net is returned from the DNS server. The 298 public key is protected either with DNSSEC or DNSCurve to validate 299 the binding between the name and public key. 301 4,5) Mbox2 checks the reputation vouching service regarding 302 Server.net and determines that it is not believed to be an infected 303 or malicious host. If the reputation had been bad, Mbox2 may use 304 local policy information to decide that Server.net should be 305 prevented from sending or receiving traffic via Mbox2 until 306 remediation steps have been taken and the reputation has improved. 308 6) The REFLECT message from Mbox2 to Server.net contains a Point-of- 309 Contact Address Block (whose format is shown in Figure 6) which in 310 this example has a registration Status Code (Table 4) of MIDBOX which 311 indicates that Mbox2 is performing IP address translation for packets 312 traversing it and that the registration message was not forwarded to 313 the DNS server. The IP address, protocol, and port number 314 information on the external interface of Mbox2 is returned in the PoC 315 Address Block, so that Server.net can resubmit the registration 316 request with this updated point of contact information in a new 317 request. 319 7,8) Because Server.net has had no previous contact with Mbox2, 320 Server.net sends message 7 to the DNS server to request the public 321 key of MBox2 and receives the response in message 8. 323 9,10) Because Server.net has had no prior contact with Mbox2 and does 324 not know its reputation, Server.net chooses a vouching service which 325 Mbox2 had indicated would vouch for it in its Address Registration 326 Reply Block of Message 6. The vouching service selected is one of 327 which Server.net was already aware and which it trusts. The response 328 indicates that Mbox2 has a good reputation. 330 11) Server.net sends a new registration request to the IP address of 331 the DNS server, DNSs. The pickle-layer message source and 332 destination block (Section 3.1.1) is included. This time its 333 destination field value is set to Mbox2 because Server.net knows that 334 Mbox2 will be the first middlebox to process the pickle packet 335 containing the registration request and that the field should be set 336 correctly to enable the use of Message Authentication Codes between 337 adjacent pickle packet capable entities in the hop by hop processing 338 of a pickle packet. 340 12) Mbox2 performs its role as a Network Address Translater and also 341 processes the pickle packet Registration request, updating the 342 pickle-layer message source and destination fields to Mbox2 and DNSs. 343 It forwards a REGISTER on to DNSs. 345 13) DNSs sends a REFLECT message (Table 2) to Mbox2 containing the 346 Point-of-Contact Address Block (Figure 6) which has a registration 347 Status Code (Table 4) of ACCEPTED, indicating that DNSs has accepted 348 the registration and will publish the binding for Server.net. The 349 Reply Block contains the Point of Contact IP Address, Protocol, Port 350 Number, the Public Key, and the Name of DNSs. 352 14) MBox2 propagates the REFLECT on to Server.net. 354 Note that Client.net may perform signaling (not shown explicitly in 355 Figure 2) comparable to that performed by Server.net in messages 1 356 through 14, if it wants to be reachable by incoming ESTABLISH 357 messages. 359 15) Client.net decides that it wants to open a connection to 360 Server.net. It starts by looking up Server.net's IP address and 361 public key. The public key and IP address binding is protected 362 either with DNSSEC or DNSCurve to prevent tampering. 364 16) Ds returns the public key and IP address of Server.net. 366 17) Client.net sends an ESTABLISH message toward the IP address 367 returned from DNS, including itself as source and Server.net as 368 destination in the Message Source/Destination block (shown in 369 Section 3.1.1). It includes the name of a vouching service that will 370 vouch for it in a Vouch-by-Reference Information block 371 (Section 3.1.2). It signs the message with its public key by 372 including a Public Key Signature block (Section 3.1.7). The message 373 is encapsulated inside a TCP SYN segment. 375 18) Mbox1 intercepts the ESTABLISH message and validates the public 376 key signature of Client.net. Mbox1 may need to query the DNS for 377 Client.net's public key and reputation (not shown), or it may already 378 have a relationship established with Client.net. It decides that it 379 wants to see symmetric key MACs on the subsequent DATA packets from 380 Client.net. It returns A REFLECT with an Authentication Restuls/ 381 Request block (Section 3.1.5) containing the client's Flow Nonce and 382 a forward HMAC Request payload using the format shown in Figure 13. 383 On the other hand, if Mbox1 doesn't need to check DATA packets for 384 authenticity, message 18 may be omitted. 386 19) After validating Client.net's ESTABLISH message, Mbox1 constructs 387 its own ESTABLISH message by inserting a new Message Source/ 388 Destination block at the top of the message (containing its own name 389 as the source and Server.net as the destination) and appending a 390 Vouch-by-Reference Information block, an Authentication Results/ 391 Request block, and a Public Key Signature block to the end of the 392 message (after Client.net's Public Key Signature block). It sends 393 the ESTABLISH on toward Server.net. 395 20-26) Mbox2 intercepts the ESTABLISH message on its way to 396 Server.net. At this point the ESTABLISH message contains the names 397 and signatures of both Client.net and Mbox1. Mbox2 queries the DNS 398 to retrieve the public keys of Client.net and Mbox1, and makes a 399 policy decision about whether either is allowed to establish 400 connections to Server.net. To do so, it may choose one or more of 401 the vouching services given in either Vouch-by-Reference Information 402 block and send additional reputation queries to those vouching 403 services. 405 27) Mbox2 decides that it wants to see symmetric key MACs from Mbox1 406 on all DATA packets. It sends a REFLECT back to Mbox1 containing a 407 Mac Request payload using the format shown in Figure 13. On the 408 other hand, if Mbox2 doesn't need to check DATA packets for 409 authenticity, message 27 may be omitted. 411 28) Mbox2 inserts its own Message Source/Destination block at the top 412 of the message and appends its own Vouch-by-Reference Information, 413 Authentication Results/Request, and Public Key Signature to the 414 ESTABLISH and forwards it on to Server.net. 416 29) Server.net decides to accept the connection (possibly after 417 retrieving public keys and checking reputations for Client.net, 418 Mbox1, and Mbox2) and sends a REFLECT encapsulated in a TCP SYN ACK 419 segment back to Mbox2. It inserts a Message Source/Destination block 420 at the top of the message with Source=Server.net and 421 Destination=Client.net, and copies all of the blocks from the 422 ESTABLISH message into a REFLECT which it then sends back toward 423 Mbox2. 425 30) Mbox2 passes the REFLECT on to Mbox1. 427 31) Mbox1 passes the REFLECT on to Client.net, and data traffic may 428 proceed. 430 The 31 messages depicted in Figure 2 may seem like a lot of overhead. 431 However, keep in mind that two separate activities are described: in 432 the first, Server.net makes its point-of-contact known to Mbox2 and 433 the rest of the network. In the second, Client.net is establishing a 434 connection. Note that the DNS lookups performed by Client.net at the 435 beginning of the connection are necessary today, even without the 436 pickle packet protocol; we merely include some additional information 437 (public keys). Also, the ESTABLISH message happens at the same time 438 as the TCP SYN would in the non-pickle packet case, and middleboxes 439 that don't want to validate subsequent DATA packets don't need to 440 generate the REFLECT messages numbered 18 and 27. The DNS queries 441 for public keys and reputations in messages 20-26 are likely to be 442 comparable to what a server that is logging connections does today 443 (i.e., TCPWrappers or webserver logs). Finally, the final set of 444 REFLECT messages that travel from Server.net to Client.net are 445 piggybacked on the TCP SYN ACK and do not add any additional round- 446 trips. 448 3. Pickle Packet Structure 450 Pickle Packets masquerade as ordinary transport packets belonging to 451 the flow for which they apply. Signaling information is included by 452 starting the transport payload with a magic number, 0x501c4ble. This 453 embedding into the transport payload can be thought of as a way to 454 extend the transport options field for those transports that have one 455 or to insert a transport options field for those transports that do 456 not. The extension is not backwards compatible with existing 457 transport implementations; it MUST be used only when the sender is 458 assured that it will be stripped out before the packet is presented 459 to the transport layer implementation. The pickle header appears 460 exactly once at the start of each transport segment data and does not 461 count as payload for the purpose of calculating transport header 462 sequence numbers. Ordinary bearer data that does not begin with the 463 magic number and that doesn't require any additional protection (such 464 as pickle-layer cookies, MACs, or encryption) may be sent exactly as 465 they are today, with no additional pickle-layer overhead. These are 466 called BARE packets. 468 A pickle packet that does contain signaling, cookies, MACs, encrypted 469 payload, or payload that begins with the magic number is shown in 470 Figure 3. 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 // IP Header // 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 // Transport Header // 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Pickle Packet Magic Number (0x501c4b1e) | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Cookie | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Msg Type |M|S|H| L | Rsvd| Fragment Offset | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Message Timestamp (If S=0, not present) | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Message ID/Nonce (If S=0 & M=0 & FragOffset=0, not present) | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | | 490 + + 491 | Fragment Signature | 492 + If S=0, this is not present. + 493 | If L=00, this is only 4 bytes. | 494 + If L=01, this is 12 bytes. + 495 | If L=10, this is 20 bytes (as shown). | 496 + If L=11, this is 32 bytes + 497 | | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | | 500 // // 501 // Fragment Payload Data // 502 // // 503 | | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Figure 3: Layout of a Pickle Packet 508 The first four bytes are the Pickle Packet Magic Number, which 509 indicates that the remainder of the packet should be interpreted as a 510 pickle packet. The next four bytes in the pickle packet are a Cookie 511 value that can be used to filter packets or otherwise identify a flow 512 and an associated security context. The Message Type field is one 513 byte. The next octet is a flags field with 5 bits currently assigned 514 meaning and 3 bits reserved. The 'M' (More Fragments) bit is set to 515 1 if there are more fragments to follow this one. The 'S' (Signature 516 Present) bit is set to 1 if a Fragment Signature is present. The 'H' 517 (Header Cover Only) controls whether the Fragment Signature is 518 calculated over the entire message ('H'=0, starting with the Pickle 519 Packet Magic Number and ending with the last octet of Fragment 520 Payload Data, treating the Fragment Signature as all-zeroes for the 521 purpose of calculating the HMAC) or just the header fields ('H'=1, 522 covering the Pickle Packet Magic Number though the Message ID/Nonce). 524 The two 'L' (Signature Length) bits control the length of the 525 Fragment Signature field. L0 is the left bit and L1 is the right 526 bit. The meaning of different combinations of these bits is shown in 527 Table 1. 529 +----+----+---------------------------------------------------------+ 530 | L0 | L1 | Description | 531 +----+----+---------------------------------------------------------+ 532 | 0 | 0 | Fragment Signature is the first 4 octets of an | 533 | | | HMAC-SHA-1. | 534 | 0 | 1 | Fragment Signature is the first 12 octets of an | 535 | | | HMAC-SHA-1. | 536 | 1 | 0 | Fragment Signature is all 20 octets of an HMAC-SHA-1. | 537 | 1 | 1 | Fragment Signature is all 32 octets of an HMAC-SHA-256. | 538 +----+----+---------------------------------------------------------+ 540 Table 1: Fragment Signature Size Options 542 When 'S'=0, the values of the 'L' bits are reserved for future use 543 and 'L' MUST be set to 00 and MUST be ignored upon receipt by 544 implementations that conform to this version of the specification. 546 The Fragment Offset field is a 16-bit integer describing the offset 547 of the first byte of the fragment payload within the larger pickle 548 packet message, in units of 8 octets. All fragments of the same 549 message MUST have the same Message Type, Message Timestamp (if 550 present), Message ID/Nonce, and the same setting for the 'S', 'H', 551 and 'L' bits. 553 The Fragment Signature, when present ('S'=1) is the (possibly 554 truncated) output of an HMAC. The HMAC uses a key derived from the 555 shared secret generated from ECDH on the two keypairs indexed by the 556 enclosed Message Source/Destination Block. If no Message Source/ 557 Destination Block is included, then the HMAC key is indicated by the 558 Cookie value in the header (see Section 3.1.1). The HMAC covers the 559 data fields as given by the 'H' bit. 561 The Message Timestamp is a 32-bit value representing the number of 562 seconds since midnight UTC on January 1, 1970 at the time the message 563 was generated. It is omitted if a signature is not present ('S' is 564 zero). The Message ID/Nonce is used both to identify different 565 fragments of the same message as well as to provide freshness for the 566 calculation of the Fragment Signature. It is omitted if neither 567 signatures nor fragmentation is in use ('S' is zero AND 'M' is zero 568 AND Fragment Offset is zero). 570 Allowed message types are given in Table 2. 572 +------+-----------+------------------------------------------------+ 573 | Msg | Name | Description | 574 | Type | | | 575 +------+-----------+------------------------------------------------+ 576 | n/a | BARE | A plain packet of the given transport | 577 | | | protocol, with no pickle fields. If pickle | 578 | | | packets are multiplexed on the same transport | 579 | | | connection, the transport payload of a BARE | 580 | | | packet MUST NOT begin with 0x501c4b1e. | 581 | 1 | REGISTER | Publish a DNS entry with contact information, | 582 | | | and/or create forwarding state at intervening | 583 | | | middleboxes. This message MUST have 'S'=1, | 584 | | | 'H'=0, and 'L'=10 or 11. | 585 | 2 | ESTABLISH | Create state at each middlebox along the path. | 586 | | | This message MUST have 'S'=1, 'H'=0, and | 587 | | | 'L'=10 or 11. | 588 | 3 | REFLECT | Response to ESTABLISH, gives the recipient | 589 | | | identity information for downstream | 590 | | | middleboxes. This message MUST have 'S'=1, | 591 | | | 'H'=0, and 'L'=10 or 11. | 592 | 4 | DATA | Contains a pickled fragment of a transport | 593 | | | data segment encapsulated in an Application | 594 | | | Data Block Header (and possibly other block | 595 | | | types). This message may have any setting of | 596 | | | 'S', 'H', and 'L' bits that are acceptable to | 597 | | | the recipient. | 598 | 5 | RAWDATA | Contains a pickled fragment of a transport | 599 | | | data segment with no encapsulating block | 600 | | | header (note that RAWDATA still contains the | 601 | | | pickle packet header given in Figure 3). This | 602 | | | message may have any setting of 'S', 'H', and | 603 | | | 'L' bits that are acceptable to the recipient. | 604 +------+-----------+------------------------------------------------+ 606 Table 2: Pickle Packet Message Types 608 3.1. Payload Block Types 610 Except for a BARE packet or a RAWDATA packet, a message consists of 611 one or more blocks, each of which is in Type, Length, Value format. 612 The Block Type field comes first and is 2 bytes long followed by a 2 613 byte Length field followed by Length number of value bytes. The 614 Block Type and Length fields are NOT included when calculating 615 Length. The allowed block types are shown in Table 3. 617 +------------+-----------------------------------------------------+ 618 | Block Type | Name | 619 +------------+-----------------------------------------------------+ 620 | 0x0001 | Message Source/Destination (Section 3.1.1) | 621 | 0x0002 | Vouch-by-Reference Information (Section 3.1.2) | 622 | 0x0003 | Point-of-Contact Address (Section 3.1.3) | 623 | 0x0004 | Binding Distribution Restriction (Section 3.1.4) | 624 | 0x0005 | Authentication Results/Request (Section 3.1.5) | 625 | 0x0006 | Application Data (Section 3.1.6) | 626 | 0x0007 | Public Key Signature (Section 3.1.7) | 627 | 0x0008 | Symmetric Key Signature (Section 3.1.8) | 628 | 0x0009 | Symmetric Key Encryption Parameters (Section 3.1.9) | 629 | 0x000a | Pickle Fragment (Section 3.1.10) | 630 +------------+-----------------------------------------------------+ 632 Table 3: Block Types 634 The following subsections give the format of each block type. 636 3.1.1. Message Source/Destination Block 638 The Message Source/Destination block gives the name of the message 639 sender (a previous middlebox, possibly the original sender) and the 640 message recipient (one of the following middleboxes, possibly the 641 ultimate destination). These fields index the two keypairs used to 642 derive the symmetric key used in the Fragment Signature calculation. 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Block Type = Msg Src/Dest | Length | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | | 650 + Flow Nonce + 651 | | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | | 654 // Source DNS Name // 655 // (includes key selector and "_pickle") // 656 | | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | | 659 // Destination DNS Name // 660 // (includes key selector and "_pickle") // 661 | | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 Figure 4: Message Source/Destination Block 666 The Flow Nonce is a 64-bit number chosen by the Source. Each DNS 667 Name MUST be of the form "selector._pickle.name.example.com", where 668 "selector" is a string of DNS labels pointing to a particular public 669 key, "_pickle" is the literal label "_pickle", and "name.example.com" 670 is a hostname. Each DNS name is a NULL-terminated string with ASCII 671 "." characters separating the labels. The final label of each name 672 may or may not have a terminating "." before the NULL. The NULL- 673 terminated Destination DNS Name is followed by an additional zero to 674 three NULL characters to align it on a 4-byte boundary. Each of 675 Source and Destination DNS Name can be used to lookup a TXT record 676 containing a public key. The format of the TXT record is given in 677 Section 4. Each node wishing to receive incoming connections MUST 678 publish a DNS TXT record at an empty selector (the name 679 "_pickle.name.example.com") containing its most preferred public key 680 and a Challenge value. This record MAY in turn point to a next- 681 preferred public key and Challenge value and so on. 683 The sender MUST ensure that the Source and Destination DNS Name 684 fields point at two compatible (same named curve) public keys both of 685 whose usage fields are set to "keyAgreement". The Cookie value of 686 the initial message of a flow is set to the low-order 32 bits of the 687 Challenge (c=) value from the TXT record indicated by Destination DNS 688 Name. 690 Before initiating a flow, the Source looks up a compatible 691 Destination's public key TXT record and computes a long term shared 692 secret (LTSS) by running Elliptic Curve Cofactor Diffie-Hellman (as 693 specified in Section 5.7.1.2 of NIST SP 800-56A [2]) on its own 694 private key and the Destination's public key. This is a static (non- 695 ephemeral) Diffie-Hellman computation. The Sender then chooses a 696 random 64-bit Flow Nonce of its own, and computes a 64 octet Master 697 Session Key (MSK) by computing: 699 SHA-512( 0x00000001 || LTSS || "Pickle MSK" || IDu || FNu || 700 IDv || CHv ) 702 Here 0x00000001 is 3 zero octets followed by a single octet with 703 value 1; LTSS is the Long-Term Shared Secret resulting from ECDH; 704 "Pickle MSK" is the literal ASCII string; IDu is two bytes indicating 705 the length (big-endian) of the Source DNS Name followed by the actual 706 Source DNS Name encoded in the same manner it appeared in the Message 707 Source/Destination Block; FNu is the Flow Nonce chosen by the Source 708 (which appears in the Flow Nonce field of the Message Source/ 709 Destination block); IDv is two bytes indicating the length (big- 710 endian) of the Destination DNS Name followed by the actual 711 Destination DNS Name encoded in the same manner it appeared in the 712 Message Source/Destination Block; and CHv is the Challenge value that 713 appeared in the Destination's TXT public key record. This Key 714 Derivation Function (KDF) is compliant with the form given in Section 715 5.8.1 of NIST SP 800-56A [2]. 717 To compute the fragment signature, the Source derives an HMAC key 718 from the MSK by computing 720 SHA-512( 0x00000001 || MSK || "Pickle HMAC Key" ) 722 and truncating the value so that it is the same length as the hash 723 function used to compute the fragment signature (i.e., 20 octets when 724 L=00, 01, or 10, and 32 octets when L=11). When truncating, the 725 high-order (left-most) octets are removed so that the least-order 20 726 or 32 octets remain. 728 The first message from a Source to a Destination always uses the low- 729 order 32 bits from the Destination's Challenge value in the Cookie 730 field of the pickle packet header, and always includes a Message 731 Source/Destination Block. However, upon receiving a response from 732 the Destination (or a middlebox on the path to the Destination) that 733 includes a Flow Nonce chosen by the Destination (or middlebox), 734 subsequent messages include the low-order 32 bits of the new Flow 735 Nonce in the Cookie field, and recompute the MSK using the new Flow 736 Nonce in place of the Challenge value: 738 SHA-512( 0x00000001 || LTSS || "Pickle MSK" || IDu || FNu || 739 IDv || FNv ) 741 Here FNv is the Flow Nonce chosen by Destination and returned in a 742 REFLECT message. Once this new MSK is computed, a new HMAC key is 743 also computed and used for subsequent messages referring to the same 744 flow. The new Cookie value in the header tells the Destination which 745 HMAC key should be used to validate the fragment signature. Once the 746 flow is established in this way, the Message Source/Destination Block 747 may be omitted from future messages. 749 Note that although the Source may intend to reach a particular 750 Destination, some middlebox along the path may intercept the message 751 and interpose itself in the communication. In this case, the 752 middlebox makes its presence known (e.g., by inserting new Message 753 Source/Destination, Authentication Results/Request (Section 3.1.5), 754 and Public Key Signature (Section 3.1.7) blocks) and chooses a Flow 755 Nonce whose low-order 32 bits are different from any Flow Nonce 756 chosen by upstream middleboxes. The middlebox then has the option of 757 returning a REFLECT message immediately (requesting that the Source 758 re-send the message with the middlebox as the new Destination), or of 759 passing the message through toward the Destination. In this latter 760 case, the middlebox would insert its own Source/Destination block as 761 the first block in the message, moving the existing Source/ 762 Destination block to second place. It would put its own name in the 763 Source field and either copy the original Destination or substitute 764 the name of a next-hop pickle-aware middlebox that it knows about. 765 The middlebox would compute its own HMAC key for use with the 766 Destination (or next-hop pickle-aware middlebox) and recompute the 767 Fragment Signature. 769 Upon receipt of a REFLECT message with the new middlebox's name and 770 Flow Nonce, the Source recomputes ECDH to construct a new LTSS 771 between itself and the middlebox. Subsequent signaling messages 772 pertaining to the flow then use the middlebox's Flow Nonce as a 773 Cookie and use the corresponding HMAC key to compute the fragment 774 signature. Note that a middlebox might not care to validate the HMAC 775 signatures on every DATA and RAWDATA packet. It makes its wishes 776 known by its inclusion or exclusion of a MAC Request list in its 777 newly inserted Path Record. Subsequent DATA and RAWDATA messages may 778 therefore have a Cookie value chosen by a downstream box multiple 779 pickle-aware hops removed from the Source; intervening middleboxes 780 would simply pass the packets through because they would not possess 781 the HMAC secret needed to validate them. 783 BARE packets may be sent only in the case where no middlebox nor the 784 ultimate destination has requested that cookies or MACs be added to 785 the data packets. 787 3.1.2. Vouch-by-Reference Information Block 789 The VBR-Info block gives information about a reputation service that 790 will vouch for the given domain. The body consists of four elements. 791 First is the cookie value of the entity for which vouching is 792 offered. A verifier should match the cookie to the low-order 32 bits 793 of a Flow Nonce in a Message Source/Destination block, and take the 794 Source name as the vouchee. The NSuffLabels field is an integer 795 giving the number of suffix labels from that Source to construct a 796 name for which vouching is offered. Together, the cookie and the 797 NSuffLabels fields play the role of the "md=" field of RFC5518 [3]. 798 Second is the Sitn ("Situation") field which is a 4-bit numeric code 799 giving the context of the communication; it plays the role of the 800 "mc=" field from RFC5518. The correspondence between the numeric 801 codes and the string values returned from a vouch-by-reference query 802 are given in Section 4.2. Finally, a sequence of NULL-terminated DNS 803 names are given indicating vouching services in which the indicated 804 suffix can be looked up. These play the role of the "mv=" field from 805 RFC5518. The final NULL-terminated string is followed by zero to 806 three additional NULL characters to align the next block on a 4-byte 807 boundary. 809 0 1 2 3 810 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 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Block Type = VBR-Info | Length | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Cookie of the vouchee | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | NSuffLabels | Sitn | Rsvd | | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ List of NULL-terminated + 818 // DNS names of vouching domains // 819 | | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 Figure 5: VBR-Info Block 824 Any middlebox through which the request passes can use one or more of 825 the vouching domains as given in Section 4.2. Similar to an e-mail 826 reputation system, the Source can be held responsible for the 827 Situation ("mc=") labeling of his transport connections through 828 after-action auditing adjudicated by the vouching domain. We define 829 some additional string values for situations and their corresponding 830 numeric codes in Section 4.2. 832 3.1.3. Point-of-Contact Address Block 834 The Point-of-Contact Address Block is used in REGISTER messages to 835 indicate the address at which the given node can be reached. It is 836 also returned in a REFLECT message by the DNS server or middlebox 837 accepting or rejecting the REGISTER. It may also appear in REFLECT 838 messages sent in response to an ESTABLISH, in which case it has the 839 effect of redirecting the initiator to the new point of contact. In 840 a REGISTER, this block occurs following a Message Source/Destination 841 Block giving the DNS name to be registered in the Source field and 842 the DNS server or middlebox name in the Destination field. While the 843 node is expected to already have a relationship with its nameserver, 844 it may not have a relationship with some middlebox on the path 845 between the registrant and nameserver. Therfore this block SHOULD be 846 followed by a Public Key Signature block enabling any middlebox to 847 validate the request. 849 The format of the Point-of-Contact Address Block is given in 850 Figure 6. 852 0 1 2 3 853 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 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Block Type = PoC Address | Length | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Lifetime | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 |F|G| Rsvd | Status | Address Type | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | | 862 // Variable-Length Address // 863 // (format depends on Address Type) // 864 | | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 Figure 6: Point-of-Contact Address Block 869 The Lifetime field indicates the number of seconds for which the 870 registration is desired/granted. The 'F' (Force) bit is set to 1 if 871 and only if the registrant wants to force the registration to succeed 872 even in the case where the IP Point-of-Contact address is different 873 from the eventual source of the REGISTER message as it arrives at the 874 Nameserver (some non-pickle-aware NAT on the path may have mapped the 875 address). The 'G' (LeGacy) bit is set to 1 if and only if all 876 connections need to be routed through the given Protocol and Port 877 Number (some non-pickle-aware NAT on the path may have been 878 configured with port forwarding but cannot route based on the 879 destination name in an ESTABLISH message). 881 The Status field is used in a REFLECT message to give the status of 882 the REGISTER request. It MUST be set to zero and ignored by the 883 recipient in a REGISTER message. It can be one of the values given 884 in Table 4. 886 +------+----------+-------------------------------------------------+ 887 | Code | Name | Description | 888 +------+----------+-------------------------------------------------+ 889 | 1 | ACCEPTED | The REGISTER was accepted and the binding | 890 | | | published. | 891 | 2 | ADDRDIFF | The REGISTER was not accepted because the | 892 | | | source of the REGISTER message did not match | 893 | | | the Point-of-Contact address and the 'F' bit | 894 | | | was not set to 1. | 895 | 3 | MIDBOX | The REGISTER was intercepted by a middlebox | 896 | | | that does address translation, and is offering | 897 | | | the translated address in the Point-of-Contact | 898 | | | field. | 899 | 4 | REDIRECT | The REGISTER or ESTABLISH should be re-sent to | 900 | | | the address given in the Point-of-Contact | 901 | | | field. | 902 +------+----------+-------------------------------------------------+ 904 Table 4: Registration Status Codes 906 If Status is set to ACCEPTED, then the registration was successful. 907 The Variable-Length Address field contains contact information of the 908 Destination with which the binding was registered; the Destination 909 agrees to manage the binding as indicated in the Binding Distribution 910 Restriction block included with the message. The contact information 911 may used by the node in subsequent REGISTER messages for the same 912 name in order to provide an anchor point through which ESTABLISH 913 messages will be routed. A non-zero Protocol and Port Number means 914 that the Recipient is listening for pickle packets only on the given 915 Protocol and Port. A zero Protocol and Port Number means that the 916 Recipient can see pickle packets on any port using either UDP or TCP. 918 If Stat is set to ADDRDIFF, it means that the Address field of the 919 REGISTER was different from the source address of the REGISTER and 920 the 'F' bit was clear. For the case of an IP-based REFLECT, the 921 Variable-length Address field in the REFLECT contains the actual IP 922 protocol number, source port number, and source address as received 923 by the replying node. This could mean that a legacy NAT is on the 924 path, which might preclude the registrant from receiving pickle 925 packets. The registrant should arrange to have at least one port 926 forwarded to him via the NAT, in which case he can re-send the 927 registration with the 'G' bit set. In the case of a link-layer 928 REFLECT, the Address field contains the actual source MAC address 929 seen by the replying node. 931 If Stat is set to MIDBOX, it means that a pickle-aware middlebox that 932 does address translation saw the REGISTER and is willing to forward 933 ESTABLISH messages toward the registrant. However, the registrant 934 needs to send another REGISTER with a new Point-of-Contact address 935 reflecting the externally visible IP address of the middlebox if it 936 wants to reach the Destination given in the Message Source/ 937 Destination block. The Protocol, Port Number, and Point-of-Contact 938 fields contain the external contact information of the middlebox. A 939 zero Protocol and Port Number means that the middlebox can see pickle 940 packets on any port using either UDP or TCP. 942 The Address Type field indicates the format of the Variable-Length 943 Address field. It can take one of the values given in 945 +------+---------+--------------------------------------------------+ 946 | Type | Name | Description | 947 +------+---------+--------------------------------------------------+ 948 | 1 | IPv4 | An IP Protocol number (e.g., 6 for TCP or 17 for | 949 | | | UDP) followed by a Port number followed by an | 950 | | | IPv4 address. | 951 | 2 | IPv6 | An IP Protocol number (e.g., 6 for TCP or 17 for | 952 | | | UDP) followed by a Port number followed by an | 953 | | | IPv6 address. | 954 | 3 | 48-bit | 6 octets containing a 48-bit IEEE MAC address. | 955 | | IEEE | | 956 | | MAC | | 957 | 4 | EUI-64 | A 64-bit Endpoint Unique Identifier. | 958 +------+---------+--------------------------------------------------+ 960 Table 5: Address Type Values 962 0 1 2 3 963 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 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Protocol | Reserved | Port Number | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | IPv4 Address | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 Figure 7: IP Version 4 Address 972 0 1 2 3 973 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 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Protocol | Reserved | Port Number | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | | 978 + + 979 | IPv6 Address | 980 + + 981 | | 982 + + 983 | | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 Figure 8: IP Version 6 Address 988 0 1 2 3 989 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 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | 48-bit IEEE MAC Address | 992 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | | padding (set to zero, ignored)| 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 Figure 9: IEEE MAC Address 998 0 1 2 3 999 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 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | | 1002 + 64-bit EUI-64 Identifier + 1003 | | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 Figure 10: EUI-64 Address 1008 3.1.4. Binding Distribution Restriction Block 1010 A node that registers a binding for a name may wish to restrict the 1011 parties to whom the binding is distributed, and may also want to 1012 limit the parties that may contact it with an ESTABLISH through 1013 upstream middleboxes. The Binding Distribution Restriction Block may 1014 be included in a REGISTER message. The format of a Binding 1015 Distribution Restriction Block is shown in Figure 11. 1017 0 1 2 3 1018 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 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 |Block Type = Bind Dis Restrict | Length | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | | 1023 // Zero or more whitelisted DNS suffixes // 1024 // (list terminated with an extra bare NULL) // 1025 | | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | | 1028 // Zero or more whitelisted vouching DNS Names // 1029 | | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | | 1032 // Zero or more blacklisted DNS suffixes // 1033 | | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | | 1036 // Zero or more blacklisted vouching DNS Names // 1037 | | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | | 1040 // Zero or more 2nd class whitelisted DNS suffixes // 1041 | | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | | 1044 // Zero or more 2nd class whitelisted vouching DNS Names // 1045 | | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 Figure 11: Binding Distribution Restriction Block 1050 First is a list of zero or more whitelisted DNS suffixes. Any node 1051 with a DNS name having one of the given suffixes should be given full 1052 access to the binding, i.e., the values of the Protocol, Port Number, 1053 and Point-of-Contact Address should be distributed to them if they 1054 query or send an ESTABLISH message. Next is a list of vouching 1055 services that serve whitelists indirectly, i.e., anyone listed by the 1056 vouching service should have the same privileges as if their DNS 1057 suffix was listed. 1059 Following the first set of whitelists is a set of blacklists. Any 1060 node with a name suffix on the suffix list or with a name listed in 1061 one of the given (anti-)vouching services MUST NOT be given binding 1062 information and their ESTABLISH messages MUST NOT be forwarded. 1064 Following the two blacklists is a set of "2nd-class" whitelists. A 1065 node with a name suffix on the suffix list or with a name listed in 1066 one of the vouching services SHOULD NOT be given the binding 1067 information; however, ESTABLISH messages from them SHOULD be 1068 forwarded by the nameserver to the registered contact information. 1070 3.1.5. Authentication Results/Request 1072 The Authentication Results/Request block is used to indicate that a 1073 node has validated certain signatures in the pickle message, and to 1074 request that other nodes insert an HMAC signature for it on 1075 subsequent DATA or RAWDATA packets. For example, a middlebox would 1076 insert this block when propagating an ESTABLISH or REGISTER message 1077 indicating that it had validated the signature of the original 1078 message source and that the vouching service satisfied the middlebox 1079 of the original source's good reputation. The middlebox could also 1080 request that the source and ultimate destination insert HMAC 1081 signatures for the middlebox to verify before it passes traffic. The 1082 format of the Authentication Results/Request block is shown in 1083 Figure 12. 1085 0 1 2 3 1086 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 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | Block Type = Auth Res/Req | Length | 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 | Cookie of middlebox inserting this block | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | Requested/Authorized PCOUNT | Status | NValid | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | | 1095 // List of NValid cookies of previous middleboxes whose // 1096 // signatures were validated by and whose vouching // 1097 // services satisfied this middlebox. // 1098 | | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | | 1101 // Sequence of HMAC Requests, // 1102 // each having format given below. // 1103 | | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 Figure 12: Authentication Results/Request Block 1108 First is the cookie value of the middlebox that is constructing this 1109 block. It is taken from the low-order 32 bits of the Flow Nonce 1110 appearing in the Message Source/Destination block that has the 1111 middlebox as the Source. Next is a Requested/Authorized PCOUNT, 1112 which is the number of packets for which the box is requesting/ 1113 authorizing with this particular signaling exchange. For example, a 1114 given middlebox might send a REFLECT indicating that the original 1115 source is allowed to send 1000 packets before it must generate 1116 another ESTABLISH message refreshing the connection. Next is a 1117 Status field that takes on one of the values in Table 6. 1119 +------+------------+-----------------------------------------------+ 1120 | Code | Name | Description | 1121 +------+------------+-----------------------------------------------+ 1122 | 1 | ACCEPTED | The middlebox has accepted the flow and is | 1123 | | | propagating the ESTABLISH message. | 1124 | | | Subsequent messages should be signed as | 1125 | | | indicated by the HMAC Requests. This value | 1126 | | | is also used by the original source to | 1127 | | | request that the connection be accepted. | 1128 | 2 | HMACNEEDED | The middlebox has not accepted the flow | 1129 | | | because needed HMACs were missing. | 1130 | | | Subsequent messages should be signed as | 1131 | | | indicated by the HMAC Requests. | 1132 | 3 | REFUSED | The middlebox refused the connection. | 1133 | 4 | BADTOPO | The middlebox cannot forward the ESTABLISH | 1134 | | | message because it would require downstream | 1135 | | | nodes to have visibility to topology that | 1136 | | | should be hidden. | 1137 +------+------------+-----------------------------------------------+ 1139 Table 6: Authorization Status Values 1141 Following the Status field is a one-byte integer representing the 1142 number of signatures that have been validated by the middlebox. A 1143 sequence of NValid 32-bit numbers appears next; each is a cookie 1144 value taken from the signature (symmetric HMAC or asymmetric public 1145 key signature) that was validated. Following the list of cookies is 1146 a sequence of HMAC Requests, each formatted as given in Figure 13 or 1147 Figure 14. 1149 0 1 2 3 1150 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 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 |0|S|H| L | Rsvd| Reserved | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 | Cookie of the entity from which the signature is requested. | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 Figure 13: Format of a Forward HMAC Request 1159 0 1 2 3 1160 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 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 |1|S|H| L | Rsvd| MSD Skip Cnt | Reserved | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | Cookie of the entity from which the signature is requested. | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 Figure 14: Format of a Reverse HMAC Request 1169 A forward HMAC request is a request for one of the preceding 1170 middleboxes (e.g., one of those that has seen and processed the 1171 ESTABLISH message already) to insert an HMAC-based signature on 1172 subsequent DATA and RAWDATA packets. It consists of a flag byte (the 1173 first bit of which must be zero) containing an (S, H, L) triple. 1174 These flags inform the recipient what kind of signature it should 1175 insert; they have the same meaning as the (S, H, L) flags from the 1176 pickle packet header (Figure 3). The rest of the bits in the first 1177 word are reserved and MUST be set to zero by the sender and MUST be 1178 ignored upon receipt. The second word of the forward HMAC request is 1179 the cookie value of the preceding node that should insert the 1180 requested signatures. Recall that each node must select a Flow Nonce 1181 whose low-order 32 bits differ from those of every other Flow Nonce 1182 chosen by upstream nodes. 1184 A reverse HMAC request is a request for one of the following 1185 middleboxes (e.g., one of those that has not yet seen the ESTABLISH 1186 message) to insert an HMAC signature in DATA and RAWDATA packets that 1187 flow back towards the connection initiator. It consists of a flag 1188 byte (the fist bit of which must be one) containing an (S, H, L) 1189 triple. These flags are interpreted the same way as for a forward 1190 HMAC request. However, because the downstream nodes may not have yet 1191 chosen a unique Flow Nonce, and the Challenge values in their public 1192 key records are not guaranteed to be unique, the desired signature 1193 source must sometimes be indicated by name instead of by Cookie. The 1194 MSD Skip Count field gives the number of Message Source/Destination 1195 blocks to skip (counting from the MSD block inserted by the middlebox 1196 indicated in the first field of the Authentication Results/Request 1197 block). After arriving at the proper Message Source/Destination 1198 block, the Destination DNS name is the indicated node from which 1199 signatures are requested. If the node from which a signature is 1200 desired has not yet chosen a unique Flow Nonce, then the Cookie field 1201 is then set to the low-order 32 bits of the Destination's Challenge 1202 value from his public key DNS TXT record (Section 4.1). Otherwise, 1203 the Cookie is set to the low-order 32 bits of the node's chosen Flow 1204 Nonce. If the MSD Skip Count is equal to or greater than the number 1205 of Message Source/Destination blocks including and following the one 1206 inserted by the requesting node, it means that the Cookie field is 1207 the sole determinant of the downstream node. 1209 Any middlebox that forwards an ESTABLISH or REGISTER message MAY hide 1210 the topology behind it by stripping out Authentication Results/ 1211 Request blocks and signature blocks from the end of a message along 1212 with the corresponding Message Source/Destination blocks from the 1213 beginning of the message. A middlebox MUST NOT strip out any 1214 Authentication Result/Request blocks that request reverse HMACs from 1215 nodes further downstream of it. If such blocks exist, and the policy 1216 of the middlebox is to hide that topology, then its only choice is to 1217 respond to the ESTABLISH with a REFLECT containing status code 1218 BADTOPO. 1220 REFLECT messages normally contain copies of all the Authentication 1221 Results/Request blocks that were received in the ESTABLISH or 1222 REGISTER message. Nodes MUST NOT strip out any Authentication 1223 Result/Request blocks from REFLECT messages that they are forwarding. 1224 However, the ultimate destination node (or the last pickle-packet 1225 aware node) MAY strip out blocks in accordance with the previous 1226 paragraph before generating its own Authentication Results/Request 1227 for inclusion in the REFLECT. 1229 3.1.6. Application Data Block 1231 The Application Data Block contains up to 64k of application data 1232 intended to be carried from the connection initiator to the ultimate 1233 destination. It can appear only in DATA messages and at most once. 1235 0 1 2 3 1236 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 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 | Block Type = AppData | Length | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | | 1241 // Application Data // 1242 // // 1243 // // 1244 | | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 Figure 15: Application Data Block 1249 3.1.7. Public Key Signature Block 1251 Nodes will typically append a public key signature to a pickle packet 1252 as it is generated or as it passes through a middlebox. The format 1253 of a public key signature block is given in Figure 16. 1255 0 1 2 3 1256 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 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | Block Type = Pub Key Sig | Length | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Signer Cookie | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Timestamp | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | | 1265 // Key Selector of Signer // 1266 | | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | | 1269 + + 1270 | | 1271 + + 1272 | Signature made with private key and algorithm corresponding | 1273 + to Key Selector and DNS Name + 1274 | (typically an R and S value for ECC) | 1275 + + 1276 | | 1277 + + 1278 | | 1279 + + 1280 | | 1281 + + 1282 | | 1283 + + 1284 | | 1285 + + 1286 | | 1287 + + 1288 | | 1289 + + 1290 | | 1291 + + 1292 | | 1293 + + 1294 | | 1295 + + 1296 | | 1297 + + 1298 | | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 Figure 16: Public Key Signature Block 1303 A Public Key Signature block starts with a Signer Cookie, which 1304 indicates the identity of the signer by matching against the low- 1305 order 32-bits of the Flow Nonce in the sequence of Message Source/ 1306 Destination blocks at the top of the message. Next is a Timestamp 1307 value indicating the number of seconds since midnight on Jan 1, 1970 1308 UTC. Next is a NULL-terminated string giving the key selector of the 1309 key used to compute the signature; a verifier can lookup the key by 1310 constructing "selector._pickle.hostname", where "hostname" is the 1311 host portion of the Source name in the Message Source/Destination 1312 block. The NULL-terminated key selector is followed by zero to three 1313 additional NULL characters to align the signature field on a 4-byte 1314 boundary. The Signature is constructed by computing a compression 1315 function over all previous blocks starting with the first Message 1316 Source/Destination block inserted by the signer, if any, or the first 1317 block that is not a Message Source/Destination block, otherwise, and 1318 continuing through to the last padding NULL following the key 1319 selector. 1321 3.1.8. Symmetric Key Signature Block 1323 The Symmetric Key Signature Block is constructed in the same manner 1324 as the Fragment Signature in the pickle packet header, except that it 1325 is indexed by both a Signer Cookie and a Receiver Cookie to indicate 1326 which shared secret is used, and does not contain a Msg Type or 1327 Fragment Offset field. The (S, H, L) triple is taken from the HMAC 1328 Request block that caused this signature to be generated. 1330 0 1 2 3 1331 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 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | Block Type = SymmetricSig | Length | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Signer Cookie | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | Receiver Cookie | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | Message Timestamp (if S=0, this is not present) | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Message ID/Nonce (if S=0, this is not present) | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | | 1344 + + 1345 | Symmetric Signature | 1346 + If S=0, this is not present. + 1347 | If L=00, this is only 4 bytes. | 1348 + If L=01, this is 12 bytes. + 1349 | If L=10, this is 20 bytes (as shown). | 1350 + If L=11, this is 32 bytes + 1351 | | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 Figure 17: Symmetric Key Signature Block 1356 The secret key used to compute the PDU Signature is derived in the 1357 same way as it would be for a Fragment Signature between the two 1358 nodes. The Signer Cookie is the low-order 4 bytes from the Flow 1359 Nonce generated by the sender when the flow was established. The 1360 Receiver Cookie is the low-order 4 bytes from the Flow Nonce 1361 generated by the receiver when the flow was established. If H=1, the 1362 signature covers only this block starting with the Block Type field 1363 and ending with the final byte of the Message ID/Nonce. If H=0, the 1364 signature covers all the previous message data starting with the 1365 first Message Source/Destination block inserted by the signer, if 1366 any, and the first block that is not a Message Source/Destination 1367 block otherwise, and continuing through the rest of the message 1368 payload and ending with the Message ID/Nonce field of the Symmetric 1369 Key Signature Block itself. 1371 The Symmetric Key Signature Block is needed to satisfy certain kinds 1372 of MAC Requests where the outer Fragment Signature is being used for 1373 some other purpose (i.e., to satisfy a request for an intervening 1374 middlebox). 1376 3.1.9. Symmetric Key Encryption Parameters Block 1378 The Symmetric Key Encryption Parameters Block indicates that the 1379 payload of the very next block is encrypted under a private key using 1380 AES-256-CTR mode. Only the payload of the next block is encrypted, 1381 not the Block Type and Length fields. 1383 0 1 2 3 1384 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 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 | Block Type = Encr Params | Length | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 | Sender Cookie | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | Receiver Cookie | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | | 1393 + + 1394 | CTR-mode Nonce / Initialization Vector | 1395 + + 1396 | | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 Figure 18: Symmetric Key Encryption Parameters Block 1401 The two parties to the encryption are given by the Sender Cookie and 1402 Receiver Cookie; these are the low-order 4 bytes of the Flow Nonces 1403 chosen by the encryptor and decryptor, respectively. The CTR-mode 1404 Nonce / Initialization Vector is 96-bits and is used to salt the AES- 1405 256 cipher for CTR mode. This Nonce is concatenated with a 32-bit 1406 counter and repeatedly enciphered by AES-256 to form the stream of 1407 pseudo-random bits that is then XORed with the plaintext to produce 1408 the ciphertext. The secret key used in the AES cipher will be 1409 derived from the MSK between the two parties, by computing one of the 1410 following functions: 1412 SHA-256( 0x00000001 || MSK || 0x0009 || "Downstream Pickle 1413 Encryption Key" ) 1415 SHA-256( 0x00000001 || MSK || 0x0009 || "Upstream Pickle 1416 Encryption Key" ) 1418 The first form is used for messages that flow "downstream"; i.e., the 1419 direction from the connection initiator (sender of the ESTABLISH or 1420 REGISTER message) toward the responder. The second form is used for 1421 messages that flow "upstream". 1423 Note that an encrypted block using keys derived from a shared secret 1424 generated with a pair of static keypairs does NOT provide perfect 1425 forward secrecy because no ephemeral key exchange takes place. 1427 3.1.10. Pickle Fragment Block 1429 The Pickle Fragment Block encapsulates a fragment of a pickle 1430 message. It can be used to encapsulate one pickle message inside 1431 another. 1433 0 1 2 3 1434 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 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | Block Type = Pickle Frag | Length | 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | | 1439 + + 1440 | A Pickle fragment, including a Pickle header starting | 1441 + with the Pickle magic number + 1442 | | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 Figure 19: Pickle Fragment Block 1447 4. Domain Name System Binding 1449 It is expected that endpoints and pickle packet middleboxes will 1450 obtain the public keys of peer entities through queries to the DNS. 1451 The pickle packet fields described above as containing a key selector 1452 and name will be of the form 1454 selector._pickle.name.example.com 1456 where "selector" is an arbitrary string of legal DNS labels chosen by 1457 the host "name.example.com" to point to a given public key. A node 1458 that wishes to receive incoming connections MUST publish a public key 1459 in a DNS TXT record with an empty selector, e.g., 1460 "_pickle.name.example.com". This record indicates the most preferred 1461 public key at which the host can be reached, and contains a Challenge 1462 value to be used when computing the shared secret for HMAC 1463 computations. 1465 4.1. Representation of Public Keys in DNS 1467 A public key TXT record is formatted as a sequence of attribute/value 1468 pairs separated by semicolons (";"). The list of possible attributes 1469 is as follows: 1471 c= Challenge value. A base-64 encoded 64-bit number. This 1472 attribute is MANDATORY in keys of type keyAgreement that will 1473 be used for receiving incoming connections. 1475 k= Key type. This is a string value (NOT an OID) taken from 1476 Section 2.1.1.1 of RFC 5480 [4]. Can be one of the following: 1478 secp256r1 1480 u= Intended key usage. A public key may be used either for key 1481 agreement or digital signatures, but not both. The usage of a 1482 key is indicated with the "u=" attribute. Can be one of the 1483 following: 1485 keyAgreement The key will be used in a Diffie-Hellman 1486 computation for generating shared secret 1487 material. 1489 digitalSignature The key will be used to compute the public 1490 key signatures using the ECDSA algorithm as 1491 specified for the public key signature block 1492 type (see Section 3.1.7). 1494 h= Hash algorithm. When u=keyAgreement, this indicates the type 1495 of signature that must be used in the Fragment Signature field 1496 of incoming packets. 1498 sha1/4 HMAC-SHA-1 truncated to 4 octets (equivalent to 1499 L=00). 1501 sha1/12 HMAC-SHA-1 truncated to 12 octets (equivalent 1502 to L=01). 1504 sha1/20 A full HMAC-SHA-1 (equivalent to L=10). 1506 sha256/32 A full HMAC-SHA-256 (equivalent to L=11). 1508 When u=digitalSignature it indicates the compression function 1509 to be applied to the preceding data before computing the 1510 signature. In this case it be one of the following: 1512 sha256/32 This value MUST be used when k=secp256r1. 1514 p= Public Key value. A base-64 encoded representation of the 1515 bytestring formed by concatenating the value of X with one byte 1516 indicating whether Y is irrelevant, positive, negative, or 1517 explicit followed by the value of Y in case it is given 1518 explicitly. The one byte can take on the following values: 1520 0 Y is not given explicitly, and the value of Y is 1521 irrelevant. 1523 1 Y is not given explicitly but is positive and can be 1524 calculated from X. 1526 2 Y is not given explicitly but is negative and can be 1527 calculated from X. 1529 3 Y follows explicitly. 1531 np= Next preferred public key selector. This is a string of DNS 1532 labels separated by periods (".") that indicates a selector 1533 that may be tried next in case the current TXT record is 1534 unsatisfactory. This attribute is OPTIONAL. 1536 The entity retreiving public keys from DNS MUST have assurance that 1537 the records were created by the owner of the given hostname. The use 1538 of a protection mechanism such as DNSSEC [5] is STRONGLY RECOMMENDED. 1540 4.2. Vouch-by-Reference Records 1542 The list of vouching domains present in a Vouch-by-Reference 1543 Information block (Section 3.1.2) can be used by middleboxes to check 1544 the reputation of a Message Source. To do so, a middlebox would 1545 lookup a TXT record at a name constructed by concatenating the last 1546 NSuffLabels labels of the Source DNS Name (this would normally not 1547 include the key selector or the string "_pickle") with the label 1548 "_vouch" followed by the domain of the vouching service. This is as 1549 described in Vouch-by-Reference [3], although we extend the set of 1550 strings that can be placed in the resulting TXT record to correspond 1551 with the Situation levels available in the Situation field of the 1552 Vouch-by-Refernce Information block. When a vouching service returns 1553 a given Situation level, it means that it attests that the Initiator 1554 will responsibly use that Situation level or higher. The allowed 1555 strings are given below in Table 7. 1557 +------+-----------------+---------------------------------------+ 1558 | Code | TXT String | Description | 1559 +------+-----------------+---------------------------------------+ 1560 | 0 | "all" | Unspecified situation. | 1561 | 1 | "list" | See Section 6.2 of RFC5518 [3]. | 1562 | 3 | "entertainment" | Personal entertainment. | 1563 | 5 | "educational" | Research or training. | 1564 | 7 | "transaction" | See Section 6.3 of RFC5518 [3]. | 1565 | 10 | "safety" | A situation affecting public safety. | 1566 | 13 | "emergency" | A serious life-threatening emergency. | 1567 +------+-----------------+---------------------------------------+ 1569 Table 7: Vouching Strings 1571 5. Acknowledgements 1573 6. IANA Considerations 1575 This memo includes no request to IANA. 1577 7. Security Considerations 1579 8. Normative References 1581 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1582 Levels", BCP 14, RFC 2119, March 1997. 1584 [2] Barker, E., Johnson, D., and M. Smid, "Recommendation for Pair- 1585 Wise Key Establishment Schemes Using Discrete Logarithm 1586 Cryptography (Revised)", NIST Special Publication 800-56A, 1587 March 2007, . 1590 [3] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By Reference", 1591 RFC 5518, April 2009. 1593 [4] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1594 "Elliptic Curve Cryptography Subject Public Key Information", 1595 RFC 5480, March 2009. 1597 [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1598 "DNS Security Introduction and Requirements", RFC 4033, 1599 March 2005. 1601 Authors' Addresses 1603 Peter J. McCann 1604 1074 N Stone Ct 1605 Naperville, Illinois 60563 1606 USA 1608 Phone: +1 630 369 9693 1609 Email: mccap@petoni.org 1611 Steve Gilbert 1612 Motorola, Inc. 1613 1301 E. Algonquin Rd. 1614 Schaumburg, Illinois 60196 1615 USA 1617 Phone: +1 847 576 0247 1618 Email: steve.gilbert@motorola.com