Authenticated Middlebox Traversal with the Pickle Packet
draft-mccann-picklepacket-01

Abstract

This document describes the Pickle Packet, a message that can be used to coordinate the opening of a transport connection with various middleboxes that may lie on the path. It contains the DNS names of both the initiator and the responder of the connection and some authentication data. Because the authentication data uses public key cryptography, any middlebox can independently authenticate the initiator and make a policy decision whether to allow or deny the flow based on the DNS names. The Pickle Packet allows for middleboxes to establish state such as firewall pinholes or security associations that can be used to filter out unwanted traffic.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on June 10, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
    1.1.  Bearer Packet Filtering
        1.1.1.  Filter using Network and Transport Header
        1.1.2.  Attack Detection Through Counting Packets
        1.1.3.  Filter Using Cookie Value
        1.1.4.  Cryptographic Header MAC
        1.1.5.  Cryptographic Header and Payload MAC
    1.2.  Requirements Language
2.  Protocol Overview
3.  Pickle Packet Structure
    3.1.  Payload Block Types
        3.1.1.  Message Source/Destination Block
        3.1.2.  Vouch-by-Reference Information Block
        3.1.3.  Point-of-Contact Address Block
        3.1.4.  Binding Distribution Restriction Block
        3.1.5.  Authentication Results/Request
        3.1.6.  Application Data Block
        3.1.7.  Public Key Signature Block
        3.1.8.  Symmetric Key Signature Block
        3.1.9.  Symmetric Key Encryption Parameters Block
        3.1.10.  Pickle Fragment Block
4.  Domain Name System Binding
    4.1.  Representation of Public Keys in DNS
    4.2.  Vouch-by-Reference Records
5.  Acknowledgements
6.  IANA Considerations
7.  Security Considerations
8.  Normative References
§  Authors' Addresses

1.  Introduction

1.1.  Bearer Packet Filtering

A middle box which processes pickle packets can be used to ensure that packets which are unwanted by the destination host are either filtered out or forwarded using a lower packet scheduling priority than packets which are wanted. Unwanted packets could consist of those from malicious or infected senders which are part of a Denial-of-Service (DoS) attack, or they may be from legitimate senders but sent when either a communication channel on the path or the destination host are congested. Compatibility with senders not capable of generating pickle packets is possible using a lenient filtering policy which forwards their packets with a lower scheduling priority. To prevent congestion of a particular communication channel by a DoS attack, a middlebox may be located just prior to that channel. This is shown in Figure 1 (Middlebox Mitigates Traffic Congestion DoS Attack).

             +--------------+
             |sources of DoS|
             |attack packets|
             +--------------+
                    |
                    |
+--------+          V                    congestible  +-----------+
|original|   +----------+   +---------+   channel     |ultimate   |
|sender  |-->|IP network|-->|middlebox|-------------->|destination|
+--------+   +----------+   +---------+               +-----------+

Several mechanisms are supported for packet filtering. When no network congestion is detected along the path and end host, and no attack is believed to be occurring, middleboxes may use lightweight mechanisms to identify those packets which have been authorized for forwarding. If a middlebox or the end host detects congestion or an attack, it may signal the sender to indicate that a more robust technique should be used to identify its packets as part of a desired traffic flow. These mechanisms are described below.

1.1.1.  Filter using Network and Transport Header

Once a flow is authorized, the middlebox can simply open a pinhole for that flow with no additional security. This would provide a basic level of assurance similar to existing firewalls that protect private networks by requiring a node on the inside to initiate a connection and refusing all outside-initiated connections. The IP source and destination addresses, the transport protocol ID, and the source and destination port numbers of UDP or TCP packets (the five-tuple) can be used to identify packets which are part of a desired flow. If the middlebox detects that some malicious node has learned the five-tuple parameters and is exploiting a pinhole to send DoS traffic, it can escalate the protection to one of the mechanisms outlined below.

1.1.2.  Attack Detection Through Counting Packets

An ESTABLISH pickle packet received by a middlebox contains PCOUNT, the number of subsequent DATA or BARE packets of the traffic flow which the middlebox may forward without having received another ESTABLISH pickle packet for the flow. The middlebox should maintain a count of the number of remaining packets which may be forwarded. If the count reaches zero, local policy of the middlebox should be used to determine whether the subsequent packets on that flow should be dropped or should be forwarded using low packet scheduling priority. Under normal circumstances the count of subsequent packets which are authorized to be forwarded should not reach zero. The original packet sender is responsible for sending enough ESTABLISH packets and high enough PCOUNT values so that under the expected packet loss rates the authorized packets are allowed to traverse the middlebox. If the middlebox detects packets of an authorized flow being deprioritized or dropped due to the count value reaching zero, it should decide whether a DoS attack is suspected and if so, it can escalate the protection to one of the mechanisms outlined below. The packet count attack detection mechanism may be used in combination with other techniques.

1.1.3.  Filter Using Cookie Value

Because an off-path attacker may learn the five-tuple, a slightly more robust protection mechanism is for the middlebox to demand that the sender insert a chosen number (a "cookie" value) into all DATA packets. This would enable the middlebox to quickly recognize which packets were generated by someone with access to the data path, and which came from weak off-path attackers. A packet of the flow which does not contain the expected cookie value in the DATA packet header would be treated as non authentic and the middlebox would update its estimate regarding whether or not an attack is occurring.

1.1.4.  Cryptographic Header MAC

An on-path attacker may be able to read the cookie value from packets in flight. A more robust but more computationally expensive approach is to distribute a shared secret between the sender and the middlebox, and to construct a Message Authentication Code (MAC) that covers the header fields of the DATA packets. This value would change on every DATA packet and so it would be difficult for an attacker to construct a new packet that would validate. The inclusion of a nonce value in the header would prevent the attacker from replaying valid packets, if the middlebox can keep state about previously seen packets. However, an attacker with the power to intercept, delay, and/or drop valid packets might be able to use the header hash to attach a different payload to the message. To defend against these forms of DoS attack, a MAC over the header and payload is required, as described below.

1.1.5.  Cryptographic Header and Payload MAC

This approach also relies on a shared secret distributed between sender and middlebox, but here the MAC covers the entire packet, not just the header. Combined with a nonce in the header, and if the middlebox has the ability to keep state about the packets that have already been seen, this technique would make it extremely difficult for an attacker to spoof a valid data packet or to replay a valid data packet and have it accepted by the middlebox. This technique would be the most robust but also the most computationally expensive.

1.2.  Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [1].

2.  Protocol Overview

The message sequence chart in Figure 2 (Message Sequence Chart If Parties Initially Unknown to Each Other) shows an example of the signaling which occurs when a pickle packet capable client begins a TCP session with a pickle packet capable server. The path traversed by bearer packets includes middlebox 1, which is near the client, and middlebox 2, which is near the server. In this example the entities are assumed to have not communicated recently and therefore information which could be locally cached must instead be retrieved from a remote entity. Cacheable information includes: the public key of an entity which is looked up at a DNS server; the reputation of an entity which is looked up at the vouching service; and a shared secret created by a Diffie Hellman key exchange between a pair of network entities and used to create message authentication codes sent between them. In this section comments will given regarding the messages of the example to help explain the operation of the protocol.

Network Entities and their symbolic identifiers:

Client.net    Mbox1   DNSc   Vouch   DNSs   Mbox2   Server.net
    C           M1     Dc      V      Ds      M2        S

Sequence of Messages:
Left Dir Right msg#  content
-----------------------------
M2 <- S   1) REGISTER (S,Ds)
Ds <- M2  2) Lookup Server.net
Ds -> M2  3) Public Key PKs
V  <- M2  4) Lookup Server.net
V  -> M2  5) Good reputation: Server.net
M2 -> S   6) REFLECT (M2,S) external IP
Ds <- S   7) Lookup Mbox2.net
Ds -> S   8) Public Key PKm2
V  <- S   9) Lookup Mbox2.net
V  -> S   10) Good reputation: Mbox2.net
M2 <- S   11) REGISTER (S,M2) external IP
Ds <- M2  12) REGISTER (M2,Ds) external IP
Ds -> M2  13) REFLECT (Ds,M2) registered
M2 -> S   14) REFLECT (M2,S) registered

            Steps 1) through 14) by S, M2, and Ds
            may also be performed by C, M1, and Dc if
            C wants to receive inbound connection
            attempts.

C  -> Ds  15) lookup Server.net
C  <- Ds  16) IP w.x.y.z Public Key PKs
C  -> M1  17) ESTABLISH (C, S) TCP SYN
C  <- M1  18) REFLECT (M1, C)
M1 -> M2  19) ESTABLISH (M1, S) TCP SYN
Dc <- M2  20,21) lookup mbox1.net, client.net
Dc -> M2  22,23) Public KeysPKm1, PKc
V  <- M2  24,25) Lookup client.net, mbox1.net
V  -> M2  26) Good reputation: client.net, mbox1.net
M1 <- M2  27) REFLECT (M2, M1)
M2 -> S   28) ESTABLISH (M2, S) TCP SYN
M2 <- S   29) REFLECT (S, M2) SYN ACK
M1 <- M2  30) REFLECT (M2, M1) SYN ACK
C  <- M1  31) REFLECT (M1, C) SYN ACK

1) The first REGISTER message is sent by Server.net towards the DNS server which it is configured to use in order to bind its name to its current IP address. Along the way, the REGISTER discovers pickle packet middle boxes. Registering via Mbox2 also tells the middlebox that Server.net is capable of processing pickle packets at the included address and that the middlebox does not need to act as a pickle packet proxy. Message 1 contains a pickle packet header as shown in Section 3 (Pickle Packet Structure), in which the message type field is REGISTER, the message source and destination block is included and its field values (shown in Section 3.1.1 (Message Source/Destination Block)) are Server.net, and DNSs. The Point-of-Contact Block shown in Figure 6 (Point-of-Contact Address Block) is also included. The DNS server which Server.net is configured to use should be on a network accesible to all clients with which Server.net wants to communicate, e.g., it should be on the public Internet. Middlebox M2 is on the path between Server.net and the public Internet so it will intercept and process the REGISTER message.

2) Because Mbox2 has had no previous contact with Server.net, Mbox2 sends message 2 to request the public key of Server.net from the DNS server. Mbox2 uses the public key to validate the Address Registration Block.

3) The public key of Server.net is returned from the DNS server. The public key is protected either with DNSSEC or DNSCurve to validate the binding between the name and public key.

4,5) Mbox2 checks the reputation vouching service regarding Server.net and determines that it is not believed to be an infected or malicious host. If the reputation had been bad, Mbox2 may use local policy information to decide that Server.net should be prevented from sending or receiving traffic via Mbox2 until remediation steps have been taken and the reputation has improved.

6) The REFLECT message from Mbox2 to Server.net contains a Point-of-Contact Address Block (whose format is shown in Figure 6 (Point-of-Contact Address Block)) which in this example has a registration Status Code (Table 4 (Registration Status Codes)) of MIDBOX which indicates that Mbox2 is performing IP address translation for packets traversing it and that the registration message was not forwarded to the DNS server. The IP address, protocol, and port number information on the external interface of Mbox2 is returned in the PoC Address Block, so that Server.net can resubmit the registration request with this updated point of contact information in a new request.

7,8) Because Server.net has had no previous contact with Mbox2, Server.net sends message 7 to the DNS server to request the public key of MBox2 and receives the response in message 8.

9,10) Because Server.net has had no prior contact with Mbox2 and does not know its reputation, Server.net chooses a vouching service which Mbox2 had indicated would vouch for it in its Address Registration Reply Block of Message 6. The vouching service selected is one of which Server.net was already aware and which it trusts. The response indicates that Mbox2 has a good reputation.

11) Server.net sends a new registration request to the IP address of the DNS server, DNSs. The pickle-layer message source and destination block (Section 3.1.1 (Message Source/Destination Block)) is included. This time its destination field value is set to Mbox2 because Server.net knows that Mbox2 will be the first middlebox to process the pickle packet containing the registration request and that the field should be set correctly to enable the use of Message Authentication Codes between adjacent pickle packet capable entities in the hop by hop processing of a pickle packet.

12) Mbox2 performs its role as a Network Address Translater and also processes the pickle packet Registration request, updating the pickle-layer message source and destination fields to Mbox2 and DNSs. It forwards a REGISTER on to DNSs.

13) DNSs sends a REFLECT message (Table 2 (Pickle Packet Message Types)) to Mbox2 containing the Point-of-Contact Address Block (Figure 6 (Point-of-Contact Address Block)) which has a registration Status Code (Table 4 (Registration Status Codes)) of ACCEPTED, indicating that DNSs has accepted the registration and will publish the binding for Server.net. The Reply Block contains the Point of Contact IP Address, Protocol, Port Number, the Public Key, and the Name of DNSs.

14) MBox2 propagates the REFLECT on to Server.net.

Note that Client.net may perform signaling (not shown explicitly in Figure 2 (Message Sequence Chart If Parties Initially Unknown to Each Other)) comparable to that performed by Server.net in messages 1 through 14, if it wants to be reachable by incoming ESTABLISH messages.

15) Client.net decides that it wants to open a connection to Server.net. It starts by looking up Server.net's IP address and public key. The public key and IP address binding is protected either with DNSSEC or DNSCurve to prevent tampering.

16) Ds returns the public key and IP address of Server.net.

17) Client.net sends an ESTABLISH message toward the IP address returned from DNS, including itself as source and Server.net as destination in the Message Source/Destination block (shown in Section 3.1.1 (Message Source/Destination Block)). It includes the name of a vouching service that will vouch for it in a Vouch-by-Reference Information block (Section 3.1.2 (Vouch-by-Reference Information Block)). It signs the message with its public key by including a Public Key Signature block (Section 3.1.7 (Public Key Signature Block)). The message is encapsulated inside a TCP SYN segment.

18) Mbox1 intercepts the ESTABLISH message and validates the public key signature of Client.net. Mbox1 may need to query the DNS for Client.net's public key and reputation (not shown), or it may already have a relationship established with Client.net. It decides that it wants to see symmetric key MACs on the subsequent DATA packets from Client.net. It returns A REFLECT with an Authentication Restuls/Request block (Section 3.1.5 (Authentication Results/Request)) containing the client's Flow Nonce and a forward HMAC Request payload using the format shown in Figure 13 (Format of a Forward HMAC Request). On the other hand, if Mbox1 doesn't need to check DATA packets for authenticity, message 18 may be omitted.

19) After validating Client.net's ESTABLISH message, Mbox1 constructs its own ESTABLISH message by inserting a new Message Source/Destination block at the top of the message (containing its own name as the source and Server.net as the destination) and appending a Vouch-by-Reference Information block, an Authentication Results/Request block, and a Public Key Signature block to the end of the message (after Client.net's Public Key Signature block). It sends the ESTABLISH on toward Server.net.

20-26) Mbox2 intercepts the ESTABLISH message on its way to Server.net. At this point the ESTABLISH message contains the names and signatures of both Client.net and Mbox1. Mbox2 queries the DNS to retrieve the public keys of Client.net and Mbox1, and makes a policy decision about whether either is allowed to establish connections to Server.net. To do so, it may choose one or more of the vouching services given in either Vouch-by-Reference Information block and send additional reputation queries to those vouching services.

27) Mbox2 decides that it wants to see symmetric key MACs from Mbox1 on all DATA packets. It sends a REFLECT back to Mbox1 containing a Mac Request payload using the format shown in Figure 13 (Format of a Forward HMAC Request). On the other hand, if Mbox2 doesn't need to check DATA packets for authenticity, message 27 may be omitted.

28) Mbox2 inserts its own Message Source/Destination block at the top of the message and appends its own Vouch-by-Reference Information, Authentication Results/Request, and Public Key Signature to the ESTABLISH and forwards it on to Server.net.

29) Server.net decides to accept the connection (possibly after retrieving public keys and checking reputations for Client.net, Mbox1, and Mbox2) and sends a REFLECT encapsulated in a TCP SYN ACK segment back to Mbox2. It inserts a Message Source/Destination block at the top of the message with Source=Server.net and Destination=Client.net, and copies all of the blocks from the ESTABLISH message into a REFLECT which it then sends back toward Mbox2.

30) Mbox2 passes the REFLECT on to Mbox1.

31) Mbox1 passes the REFLECT on to Client.net, and data traffic may proceed.

The 31 messages depicted in Figure 2 (Message Sequence Chart If Parties Initially Unknown to Each Other) may seem like a lot of overhead. However, keep in mind that two separate activities are described: in the first, Server.net makes its point-of-contact known to Mbox2 and the rest of the network. In the second, Client.net is establishing a connection. Note that the DNS lookups performed by Client.net at the beginning of the connection are necessary today, even without the pickle packet protocol; we merely include some additional information (public keys). Also, the ESTABLISH message happens at the same time as the TCP SYN would in the non-pickle packet case, and middleboxes that don't want to validate subsequent DATA packets don't need to generate the REFLECT messages numbered 18 and 27. The DNS queries for public keys and reputations in messages 20-26 are likely to be comparable to what a server that is logging connections does today (i.e., TCPWrappers or webserver logs). Finally, the final set of REFLECT messages that travel from Server.net to Client.net are piggybacked on the TCP SYN ACK and do not add any additional round-trips.

3.  Pickle Packet Structure

Pickle Packets masquerade as ordinary transport packets belonging to the flow for which they apply. Signaling information is included by starting the transport payload with a magic number, 0x501c4ble. This embedding into the transport payload can be thought of as a way to extend the transport options field for those transports that have one or to insert a transport options field for those transports that do not. The extension is not backwards compatible with existing transport implementations; it MUST be used only when the sender is assured that it will be stripped out before the packet is presented to the transport layer implementation. The pickle header appears exactly once at the start of each transport segment data and does not count as payload for the purpose of calculating transport header sequence numbers. Ordinary bearer data that does not begin with the magic number and that doesn't require any additional protection (such as pickle-layer cookies, MACs, or encryption) may be sent exactly as they are today, with no additional pickle-layer overhead. These are called BARE packets.

A pickle packet that does contain signaling, cookies, MACs, encrypted payload, or payload that begins with the magic number is shown in Figure 3 (Layout of a Pickle Packet).

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                          IP Header                          //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                       Transport Header                      //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Pickle Packet Magic Number (0x501c4b1e)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Cookie                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Msg Type   |M|S|H| L | Rsvd|       Fragment Offset         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Message Timestamp (If S=0, not present)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Message ID/Nonce (If S=0 & M=0 & FragOffset=0, not present)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                      Fragment Signature                       |
+                  If S=0, this is not present.                 +
|                 If L=00, this is only 4 bytes.                |
+                 If L=01, this is 12 bytes.                    +
|                 If L=10, this is 20 bytes (as shown).         |
+                 If L=11, this is 32 bytes                     +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                                                             //
//                   Fragment Payload Data                     //
//                                                             //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The first four bytes are the Pickle Packet Magic Number, which indicates that the remainder of the packet should be interpreted as a pickle packet. The next four bytes in the pickle packet are a Cookie value that can be used to filter packets or otherwise identify a flow and an associated security context. The Message Type field is one byte. The next octet is a flags field with 5 bits currently assigned meaning and 3 bits reserved. The 'M' (More Fragments) bit is set to 1 if there are more fragments to follow this one. The 'S' (Signature Present) bit is set to 1 if a Fragment Signature is present. The 'H' (Header Cover Only) controls whether the Fragment Signature is calculated over the entire message ('H'=0, starting with the Pickle Packet Magic Number and ending with the last octet of Fragment Payload Data, treating the Fragment Signature as all-zeroes for the purpose of calculating the HMAC) or just the header fields ('H'=1, covering the Pickle Packet Magic Number though the Message ID/Nonce).

The two 'L' (Signature Length) bits control the length of the Fragment Signature field. L0 is the left bit and L1 is the right bit. The meaning of different combinations of these bits is shown in Table 1 (Fragment Signature Size Options).

When 'S'=0, the values of the 'L' bits are reserved for future use and 'L' MUST be set to 00 and MUST be ignored upon receipt by implementations that conform to this version of the specification.

The Fragment Offset field is a 16-bit integer describing the offset of the first byte of the fragment payload within the larger pickle packet message, in units of 8 octets. All fragments of the same message MUST have the same Message Type, Message Timestamp (if present), Message ID/Nonce, and the same setting for the 'S', 'H', and 'L' bits.

The Fragment Signature, when present ('S'=1) is the (possibly truncated) output of an HMAC. The HMAC uses a key derived from the shared secret generated from ECDH on the two keypairs indexed by the enclosed Message Source/Destination Block. If no Message Source/Destination Block is included, then the HMAC key is indicated by the Cookie value in the header (see Section 3.1.1 (Message Source/Destination Block)). The HMAC covers the data fields as given by the 'H' bit.

The Message Timestamp is a 32-bit value representing the number of seconds since midnight UTC on January 1, 1970 at the time the message was generated. It is omitted if a signature is not present ('S' is zero). The Message ID/Nonce is used both to identify different fragments of the same message as well as to provide freshness for the calculation of the Fragment Signature. It is omitted if neither signatures nor fragmentation is in use ('S' is zero AND 'M' is zero AND Fragment Offset is zero).

Allowed message types are given in Table 2 (Pickle Packet Message Types).

3.1.  Payload Block Types

Except for a BARE packet or a RAWDATA packet, a message consists of one or more blocks, each of which is in Type, Length, Value format. The Block Type field comes first and is 2 bytes long followed by a 2 byte Length field followed by Length number of value bytes. The Block Type and Length fields are NOT included when calculating Length. The allowed block types are shown in Table 3 (Block Types).

The following subsections give the format of each block type.

3.1.1.  Message Source/Destination Block

The Message Source/Destination block gives the name of the message sender (a previous middlebox, possibly the original sender) and the message recipient (one of the following middleboxes, possibly the ultimate destination). These fields index the two keypairs used to derive the symmetric key used in the Fragment Signature calculation.

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Block Type = Msg Src/Dest    |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                           Flow Nonce                          +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                       Source DNS Name                       //
//             (includes key selector and "_pickle")           //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                     Destination DNS Name                    //
//             (includes key selector and "_pickle")           //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Flow Nonce is a 64-bit number chosen by the Source. Each DNS Name MUST be of the form "selector._pickle.name.example.com", where "selector" is a string of DNS labels pointing to a particular public key, "_pickle" is the literal label "_pickle", and "name.example.com" is a hostname. Each DNS name is a NULL-terminated string with ASCII "." characters separating the labels. The final label of each name may or may not have a terminating "." before the NULL. The NULL-terminated Destination DNS Name is followed by an additional zero to three NULL characters to align it on a 4-byte boundary. Each of Source and Destination DNS Name can be used to lookup a TXT record containing a public key. The format of the TXT record is given in Section 4 (Domain Name System Binding). Each node wishing to receive incoming connections MUST publish a DNS TXT record at an empty selector (the name "_pickle.name.example.com") containing its most preferred public key and a Challenge value. This record MAY in turn point to a next-preferred public key and Challenge value and so on.

The sender MUST ensure that the Source and Destination DNS Name fields point at two compatible (same named curve) public keys both of whose usage fields are set to "keyAgreement". The Cookie value of the initial message of a flow is set to the low-order 32 bits of the Challenge (c=) value from the TXT record indicated by Destination DNS Name.

Before initiating a flow, the Source looks up a compatible Destination's public key TXT record and computes a long term shared secret (LTSS) by running Elliptic Curve Cofactor Diffie-Hellman (as specified in Section 5.7.1.2 of NIST SP 800-56A (Barker, E., Johnson, D., and M. Smid, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised),” March 2007.) [2]) on its own private key and the Destination's public key. This is a static (non-ephemeral) Diffie-Hellman computation. The Sender then chooses a random 64-bit Flow Nonce of its own, and computes a 64 octet Master Session Key (MSK) by computing:

SHA-512( 0x00000001 || LTSS || "Pickle MSK" || IDu || FNu || IDv || CHv )

Here 0x00000001 is 3 zero octets followed by a single octet with value 1; LTSS is the Long-Term Shared Secret resulting from ECDH; "Pickle MSK" is the literal ASCII string; IDu is two bytes indicating the length (big-endian) of the Source DNS Name followed by the actual Source DNS Name encoded in the same manner it appeared in the Message Source/Destination Block; FNu is the Flow Nonce chosen by the Source (which appears in the Flow Nonce field of the Message Source/Destination block); IDv is two bytes indicating the length (big-endian) of the Destination DNS Name followed by the actual Destination DNS Name encoded in the same manner it appeared in the Message Source/Destination Block; and CHv is the Challenge value that appeared in the Destination's TXT public key record. This Key Derivation Function (KDF) is compliant with the form given in Section 5.8.1 of NIST SP 800-56A (Barker, E., Johnson, D., and M. Smid, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised),” March 2007.) [2].

To compute the fragment signature, the Source derives an HMAC key from the MSK by computing

SHA-512( 0x00000001 || MSK || "Pickle HMAC Key" )

and truncating the value so that it is the same length as the hash function used to compute the fragment signature (i.e., 20 octets when L=00, 01, or 10, and 32 octets when L=11). When truncating, the high-order (left-most) octets are removed so that the least-order 20 or 32 octets remain.

The first message from a Source to a Destination always uses the low-order 32 bits from the Destination's Challenge value in the Cookie field of the pickle packet header, and always includes a Message Source/Destination Block. However, upon receiving a response from the Destination (or a middlebox on the path to the Destination) that includes a Flow Nonce chosen by the Destination (or middlebox), subsequent messages include the low-order 32 bits of the new Flow Nonce in the Cookie field, and recompute the MSK using the new Flow Nonce in place of the Challenge value:

SHA-512( 0x00000001 || LTSS || "Pickle MSK" || IDu || FNu || IDv || FNv )

Here FNv is the Flow Nonce chosen by Destination and returned in a REFLECT message. Once this new MSK is computed, a new HMAC key is also computed and used for subsequent messages referring to the same flow. The new Cookie value in the header tells the Destination which HMAC key should be used to validate the fragment signature. Once the flow is established in this way, the Message Source/Destination Block may be omitted from future messages.

Note that although the Source may intend to reach a particular Destination, some middlebox along the path may intercept the message and interpose itself in the communication. In this case, the middlebox makes its presence known (e.g., by inserting new Message Source/Destination, Authentication Results/Request (Section 3.1.5 (Authentication Results/Request)), and Public Key Signature (Section 3.1.7 (Public Key Signature Block)) blocks) and chooses a Flow Nonce whose low-order 32 bits are different from any Flow Nonce chosen by upstream middleboxes. The middlebox then has the option of returning a REFLECT message immediately (requesting that the Source re-send the message with the middlebox as the new Destination), or of passing the message through toward the Destination. In this latter case, the middlebox would insert its own Source/Destination block as the first block in the message, moving the existing Source/Destination block to second place. It would put its own name in the Source field and either copy the original Destination or substitute the name of a next-hop pickle-aware middlebox that it knows about. The middlebox would compute its own HMAC key for use with the Destination (or next-hop pickle-aware middlebox) and recompute the Fragment Signature.

Upon receipt of a REFLECT message with the new middlebox's name and Flow Nonce, the Source recomputes ECDH to construct a new LTSS between itself and the middlebox. Subsequent signaling messages pertaining to the flow then use the middlebox's Flow Nonce as a Cookie and use the corresponding HMAC key to compute the fragment signature. Note that a middlebox might not care to validate the HMAC signatures on every DATA and RAWDATA packet. It makes its wishes known by its inclusion or exclusion of a MAC Request list in its newly inserted Path Record. Subsequent DATA and RAWDATA messages may therefore have a Cookie value chosen by a downstream box multiple pickle-aware hops removed from the Source; intervening middleboxes would simply pass the packets through because they would not possess the HMAC secret needed to validate them.

BARE packets may be sent only in the case where no middlebox nor the ultimate destination has requested that cookies or MACs be added to the data packets.

3.1.2.  Vouch-by-Reference Information Block

The VBR-Info block gives information about a reputation service that will vouch for the given domain. The body consists of four elements. First is the cookie value of the entity for which vouching is offered. A verifier should match the cookie to the low-order 32 bits of a Flow Nonce in a Message Source/Destination block, and take the Source name as the vouchee. The NSuffLabels field is an integer giving the number of suffix labels from that Source to construct a name for which vouching is offered. Together, the cookie and the NSuffLabels fields play the role of the "md=" field of RFC5518 (Hoffman, P., Levine, J., and A. Hathcock, “Vouch By Reference,” April 2009.) [3]. Second is the Sitn ("Situation") field which is a 4-bit numeric code giving the context of the communication; it plays the role of the "mc=" field from RFC5518. The correspondence between the numeric codes and the string values returned from a vouch-by-reference query are given in Section 4.2 (Vouch-by-Reference Records). Finally, a sequence of NULL-terminated DNS names are given indicating vouching services in which the indicated suffix can be looked up. These play the role of the "mv=" field from RFC5518. The final NULL-terminated string is followed by zero to three additional NULL characters to align the next block on a 4-byte boundary.

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Block Type = VBR-Info     |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Cookie of the vouchee                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  NSuffLabels  | Sitn  | Rsvd  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    List of NULL-terminated    +
//                            DNS names of vouching domains    //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Any middlebox through which the request passes can use one or more of the vouching domains as given in Section 4.2 (Vouch-by-Reference Records). Similar to an e-mail reputation system, the Source can be held responsible for the Situation ("mc=") labeling of his transport connections through after-action auditing adjudicated by the vouching domain. We define some additional string values for situations and their corresponding numeric codes in Section 4.2 (Vouch-by-Reference Records).

3.1.3.  Point-of-Contact Address Block

The Point-of-Contact Address Block is used in REGISTER messages to indicate the address at which the given node can be reached. It is also returned in a REFLECT message by the DNS server or middlebox accepting or rejecting the REGISTER. It may also appear in REFLECT messages sent in response to an ESTABLISH, in which case it has the effect of redirecting the initiator to the new point of contact. In a REGISTER, this block occurs following a Message Source/Destination Block giving the DNS name to be registered in the Source field and the DNS server or middlebox name in the Destination field. While the node is expected to already have a relationship with its nameserver, it may not have a relationship with some middlebox on the path between the registrant and nameserver. Therfore this block SHOULD be followed by a Public Key Signature block enabling any middlebox to validate the request.

The format of the Point-of-Contact Address Block is given in Figure 6 (Point-of-Contact Address Block).

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Block Type = PoC Address     |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Lifetime                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|G|    Rsvd   |     Status    |        Address Type           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                   Variable-Length Address                   //
//              (format depends on Address Type)               //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Lifetime field indicates the number of seconds for which the registration is desired/granted. The 'F' (Force) bit is set to 1 if and only if the registrant wants to force the registration to succeed even in the case where the IP Point-of-Contact address is different from the eventual source of the REGISTER message as it arrives at the Nameserver (some non-pickle-aware NAT on the path may have mapped the address). The 'G' (LeGacy) bit is set to 1 if and only if all connections need to be routed through the given Protocol and Port Number (some non-pickle-aware NAT on the path may have been configured with port forwarding but cannot route based on the destination name in an ESTABLISH message).

The Status field is used in a REFLECT message to give the status of the REGISTER request. It MUST be set to zero and ignored by the recipient in a REGISTER message. It can be one of the values given in Table 4 (Registration Status Codes).

If Status is set to ACCEPTED, then the registration was successful. The Variable-Length Address field contains contact information of the Destination with which the binding was registered; the Destination agrees to manage the binding as indicated in the Binding Distribution Restriction block included with the message. The contact information may used by the node in subsequent REGISTER messages for the same name in order to provide an anchor point through which ESTABLISH messages will be routed. A non-zero Protocol and Port Number means that the Recipient is listening for pickle packets only on the given Protocol and Port. A zero Protocol and Port Number means that the Recipient can see pickle packets on any port using either UDP or TCP.

If Stat is set to ADDRDIFF, it means that the Address field of the REGISTER was different from the source address of the REGISTER and the 'F' bit was clear. For the case of an IP-based REFLECT, the Variable-length Address field in the REFLECT contains the actual IP protocol number, source port number, and source address as received by the replying node. This could mean that a legacy NAT is on the path, which might preclude the registrant from receiving pickle packets. The registrant should arrange to have at least one port forwarded to him via the NAT, in which case he can re-send the registration with the 'G' bit set. In the case of a link-layer REFLECT, the Address field contains the actual source MAC address seen by the replying node.

If Stat is set to MIDBOX, it means that a pickle-aware middlebox that does address translation saw the REGISTER and is willing to forward ESTABLISH messages toward the registrant. However, the registrant needs to send another REGISTER with a new Point-of-Contact address reflecting the externally visible IP address of the middlebox if it wants to reach the Destination given in the Message Source/Destination block. The Protocol, Port Number, and Point-of-Contact fields contain the external contact information of the middlebox. A zero Protocol and Port Number means that the middlebox can see pickle packets on any port using either UDP or TCP.

The Address Type field indicates the format of the Variable-Length Address field. It can take one of the values given in

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Protocol    |    Reserved   |          Port Number          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         IPv4  Address                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Protocol    |    Reserved   |          Port Number          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                         IPv6  Address                         |
+                                                               +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      48-bit IEEE MAC Address                  |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               | padding (set to zero, ignored)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                      64-bit EUI-64 Identifier                 +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1.4.  Binding Distribution Restriction Block

A node that registers a binding for a name may wish to restrict the parties to whom the binding is distributed, and may also want to limit the parties that may contact it with an ESTABLISH through upstream middleboxes. The Binding Distribution Restriction Block may be included in a REGISTER message. The format of a Binding Distribution Restriction Block is shown in Figure 11 (Binding Distribution Restriction Block).

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Block Type = Bind Dis Restrict |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//           Zero or more whitelisted DNS suffixes             //
//         (list terminated with an extra bare NULL)           //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//          Zero or more whitelisted vouching DNS Names        //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//            Zero or more blacklisted DNS suffixes            //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//          Zero or more blacklisted vouching DNS Names        //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//        Zero or more 2nd class whitelisted DNS suffixes      //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//     Zero or more 2nd class whitelisted vouching DNS Names   //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

First is a list of zero or more whitelisted DNS suffixes. Any node with a DNS name having one of the given suffixes should be given full access to the binding, i.e., the values of the Protocol, Port Number, and Point-of-Contact Address should be distributed to them if they query or send an ESTABLISH message. Next is a list of vouching services that serve whitelists indirectly, i.e., anyone listed by the vouching service should have the same privileges as if their DNS suffix was listed.

Following the first set of whitelists is a set of blacklists. Any node with a name suffix on the suffix list or with a name listed in one of the given (anti-)vouching services MUST NOT be given binding information and their ESTABLISH messages MUST NOT be forwarded.

Following the two blacklists is a set of "2nd-class" whitelists. A node with a name suffix on the suffix list or with a name listed in one of the vouching services SHOULD NOT be given the binding information; however, ESTABLISH messages from them SHOULD be forwarded by the nameserver to the registered contact information.

3.1.5.  Authentication Results/Request

The Authentication Results/Request block is used to indicate that a node has validated certain signatures in the pickle message, and to request that other nodes insert an HMAC signature for it on subsequent DATA or RAWDATA packets. For example, a middlebox would insert this block when propagating an ESTABLISH or REGISTER message indicating that it had validated the signature of the original message source and that the vouching service satisfied the middlebox of the original source's good reputation. The middlebox could also request that the source and ultimate destination insert HMAC signatures for the middlebox to verify before it passes traffic. The format of the Authentication Results/Request block is shown in Figure 12 (Authentication Results/Request Block).

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Block Type = Auth Res/Req    |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Cookie of middlebox inserting this block            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Requested/Authorized PCOUNT  |    Status     |     NValid    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//    List of NValid cookies of previous middleboxes whose     //
//    signatures were validated by and whose vouching          //
//            services satisfied this middlebox.               //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                  Sequence of HMAC Requests,                 //
//                each having format given below.              //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

First is the cookie value of the middlebox that is constructing this block. It is taken from the low-order 32 bits of the Flow Nonce appearing in the Message Source/Destination block that has the middlebox as the Source. Next is a Requested/Authorized PCOUNT, which is the number of packets for which the box is requesting/authorizing with this particular signaling exchange. For example, a given middlebox might send a REFLECT indicating that the original source is allowed to send 1000 packets before it must generate another ESTABLISH message refreshing the connection. Next is a Status field that takes on one of the values in Table 6 (Authorization Status Values).

Following the Status field is a one-byte integer representing the number of signatures that have been validated by the middlebox. A sequence of NValid 32-bit numbers appears next; each is a cookie value taken from the signature (symmetric HMAC or asymmetric public key signature) that was validated. Following the list of cookies is a sequence of HMAC Requests, each formatted as given in Figure 13 (Format of a Forward HMAC Request) or Figure 14 (Format of a Reverse HMAC Request).

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|S|H| L | Rsvd|                  Reserved                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Cookie of the entity from which the signature is requested.  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|S|H| L | Rsvd| MSD Skip Cnt  |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Cookie of the entity from which the signature is requested.  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A forward HMAC request is a request for one of the preceding middleboxes (e.g., one of those that has seen and processed the ESTABLISH message already) to insert an HMAC-based signature on subsequent DATA and RAWDATA packets. It consists of a flag byte (the first bit of which must be zero) containing an (S, H, L) triple. These flags inform the recipient what kind of signature it should insert; they have the same meaning as the (S, H, L) flags from the pickle packet header (Figure 3 (Layout of a Pickle Packet)). The rest of the bits in the first word are reserved and MUST be set to zero by the sender and MUST be ignored upon receipt. The second word of the forward HMAC request is the cookie value of the preceding node that should insert the requested signatures. Recall that each node must select a Flow Nonce whose low-order 32 bits differ from those of every other Flow Nonce chosen by upstream nodes.

A reverse HMAC request is a request for one of the following middleboxes (e.g., one of those that has not yet seen the ESTABLISH message) to insert an HMAC signature in DATA and RAWDATA packets that flow back towards the connection initiator. It consists of a flag byte (the fist bit of which must be one) containing an (S, H, L) triple. These flags are interpreted the same way as for a forward HMAC request. However, because the downstream nodes may not have yet chosen a unique Flow Nonce, and the Challenge values in their public key records are not guaranteed to be unique, the desired signature source must sometimes be indicated by name instead of by Cookie. The MSD Skip Count field gives the number of Message Source/Destination blocks to skip (counting from the MSD block inserted by the middlebox indicated in the first field of the Authentication Results/Request block). After arriving at the proper Message Source/Destination block, the Destination DNS name is the indicated node from which signatures are requested. If the node from which a signature is desired has not yet chosen a unique Flow Nonce, then the Cookie field is then set to the low-order 32 bits of the Destination's Challenge value from his public key DNS TXT record (Section 4.1 (Representation of Public Keys in DNS)). Otherwise, the Cookie is set to the low-order 32 bits of the node's chosen Flow Nonce. If the MSD Skip Count is equal to or greater than the number of Message Source/Destination blocks including and following the one inserted by the requesting node, it means that the Cookie field is the sole determinant of the downstream node.

Any middlebox that forwards an ESTABLISH or REGISTER message MAY hide the topology behind it by stripping out Authentication Results/Request blocks and signature blocks from the end of a message along with the corresponding Message Source/Destination blocks from the beginning of the message. A middlebox MUST NOT strip out any Authentication Result/Request blocks that request reverse HMACs from nodes further downstream of it. If such blocks exist, and the policy of the middlebox is to hide that topology, then its only choice is to respond to the ESTABLISH with a REFLECT containing status code BADTOPO.

REFLECT messages normally contain copies of all the Authentication Results/Request blocks that were received in the ESTABLISH or REGISTER message. Nodes MUST NOT strip out any Authentication Result/Request blocks from REFLECT messages that they are forwarding. However, the ultimate destination node (or the last pickle-packet aware node) MAY strip out blocks in accordance with the previous paragraph before generating its own Authentication Results/Request for inclusion in the REFLECT.

3.1.6.  Application Data Block

The Application Data Block contains up to 64k of application data intended to be carried from the connection initiator to the ultimate destination. It can appear only in DATA messages and at most once.

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Block Type = AppData       |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                       Application Data                      //
//                                                             //
//                                                             //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1.7.  Public Key Signature Block

Nodes will typically append a public key signature to a pickle packet as it is generated or as it passes through a middlebox. The format of a public key signature block is given in Figure 16 (Public Key Signature Block).

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Block Type = Pub Key Sig     |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Signer Cookie                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                    Key Selector of Signer                   //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                                                               +
|  Signature made with private key and algorithm corresponding  |
+                  to Key Selector and DNS Name                 +
|               (typically an R and S value for ECC)            |
+                                                               +
|                                                               |
+                                                               +
|                                                               |
+                                                               +
|                                                               |
+                                                               +
|                                                               |
+                                                               +
|                                                               |
+                                                               +
|                                                               |
+                                                               +
|                                                               |
+                                                               +
|                                                               |
+                                                               +
|                                                               |
+                                                               +
|                                                               |
+                                                               +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A Public Key Signature block starts with a Signer Cookie, which indicates the identity of the signer by matching against the low-order 32-bits of the Flow Nonce in the sequence of Message Source/Destination blocks at the top of the message. Next is a Timestamp value indicating the number of seconds since midnight on Jan 1, 1970 UTC. Next is a NULL-terminated string giving the key selector of the key used to compute the signature; a verifier can lookup the key by constructing "selector._pickle.hostname", where "hostname" is the host portion of the Source name in the Message Source/Destination block. The NULL-terminated key selector is followed by zero to three additional NULL characters to align the signature field on a 4-byte boundary. The Signature is constructed by computing a compression function over all previous blocks starting with the first Message Source/Destination block inserted by the signer, if any, or the first block that is not a Message Source/Destination block, otherwise, and continuing through to the last padding NULL following the key selector.

3.1.8.  Symmetric Key Signature Block

The Symmetric Key Signature Block is constructed in the same manner as the Fragment Signature in the pickle packet header, except that it is indexed by both a Signer Cookie and a Receiver Cookie to indicate which shared secret is used, and does not contain a Msg Type or Fragment Offset field. The (S, H, L) triple is taken from the HMAC Request block that caused this signature to be generated.

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Block Type = SymmetricSig   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Signer Cookie                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Receiver Cookie                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Message Timestamp (if S=0, this is not present)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Message ID/Nonce  (if S=0, this is not present)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                     Symmetric Signature                       |
+                  If S=0, this is not present.                 +
|                 If L=00, this is only 4 bytes.                |
+                 If L=01, this is 12 bytes.                    +
|                 If L=10, this is 20 bytes (as shown).         |
+                 If L=11, this is 32 bytes                     +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The secret key used to compute the PDU Signature is derived in the same way as it would be for a Fragment Signature between the two nodes. The Signer Cookie is the low-order 4 bytes from the Flow Nonce generated by the sender when the flow was established. The Receiver Cookie is the low-order 4 bytes from the Flow Nonce generated by the receiver when the flow was established. If H=1, the signature covers only this block starting with the Block Type field and ending with the final byte of the Message ID/Nonce. If H=0, the signature covers all the previous message data starting with the first Message Source/Destination block inserted by the signer, if any, and the first block that is not a Message Source/Destination block otherwise, and continuing through the rest of the message payload and ending with the Message ID/Nonce field of the Symmetric Key Signature Block itself.

The Symmetric Key Signature Block is needed to satisfy certain kinds of MAC Requests where the outer Fragment Signature is being used for some other purpose (i.e., to satisfy a request for an intervening middlebox).

3.1.9.  Symmetric Key Encryption Parameters Block

The Symmetric Key Encryption Parameters Block indicates that the payload of the very next block is encrypted under a private key using AES-256-CTR mode. Only the payload of the next block is encrypted, not the Block Type and Length fields.

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Block Type = Encr Params    |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sender Cookie                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Receiver Cookie                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|             CTR-mode Nonce / Initialization Vector            |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The two parties to the encryption are given by the Sender Cookie and Receiver Cookie; these are the low-order 4 bytes of the Flow Nonces chosen by the encryptor and decryptor, respectively. The CTR-mode Nonce / Initialization Vector is 96-bits and is used to salt the AES-256 cipher for CTR mode. This Nonce is concatenated with a 32-bit counter and repeatedly enciphered by AES-256 to form the stream of pseudo-random bits that is then XORed with the plaintext to produce the ciphertext. The secret key used in the AES cipher will be derived from the MSK between the two parties, by computing one of the following functions:

SHA-256( 0x00000001 || MSK || 0x0009 || "Downstream Pickle Encryption Key" )

SHA-256( 0x00000001 || MSK || 0x0009 || "Upstream Pickle Encryption Key" )

The first form is used for messages that flow "downstream"; i.e., the direction from the connection initiator (sender of the ESTABLISH or REGISTER message) toward the responder. The second form is used for messages that flow "upstream".

Note that an encrypted block using keys derived from a shared secret generated with a pair of static keypairs does NOT provide perfect forward secrecy because no ephemeral key exchange takes place.

3.1.10.  Pickle Fragment Block

The Pickle Fragment Block encapsulates a fragment of a pickle message. It can be used to encapsulate one pickle message inside another.

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Block Type = Pickle Frag    |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|     A Pickle fragment, including a Pickle header starting     |
+                    with the Pickle magic number               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.  Domain Name System Binding

It is expected that endpoints and pickle packet middleboxes will obtain the public keys of peer entities through queries to the DNS. The pickle packet fields described above as containing a key selector and name will be of the form

selector._pickle.name.example.com

where "selector" is an arbitrary string of legal DNS labels chosen by the host "name.example.com" to point to a given public key. A node that wishes to receive incoming connections MUST publish a public key in a DNS TXT record with an empty selector, e.g., "_pickle.name.example.com". This record indicates the most preferred public key at which the host can be reached, and contains a Challenge value to be used when computing the shared secret for HMAC computations.

4.1.  Representation of Public Keys in DNS

A public key TXT record is formatted as a sequence of attribute/value pairs separated by semicolons (";"). The list of possible attributes is as follows:

c=

Challenge value. A base-64 encoded 64-bit number. This attribute is MANDATORY in keys of type keyAgreement that will be used for receiving incoming connections.

k=

Key type. This is a string value (NOT an OID) taken from Section 2.1.1.1 of RFC 5480 (Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, “Elliptic Curve Cryptography Subject Public Key Information,” March 2009.) [4]. Can be one of the following:

secp256r1

u=

Intended key usage. A public key may be used either for key agreement or digital signatures, but not both. The usage of a key is indicated with the "u=" attribute. Can be one of the following:

keyAgreement

The key will be used in a Diffie-Hellman computation for generating shared secret material.

digitalSignature

The key will be used to compute the public key signatures using the ECDSA algorithm as specified for the public key signature block type (see Section 3.1.7 (Public Key Signature Block)).

h=

Hash algorithm. When u=keyAgreement, this indicates the type of signature that must be used in the Fragment Signature field of incoming packets.

sha1/4

HMAC-SHA-1 truncated to 4 octets (equivalent to L=00).

sha1/12

HMAC-SHA-1 truncated to 12 octets (equivalent to L=01).

sha1/20

A full HMAC-SHA-1 (equivalent to L=10).

sha256/32

A full HMAC-SHA-256 (equivalent to L=11).

When u=digitalSignature it indicates the compression function to be applied to the preceding data before computing the signature. In this case it be one of the following:

sha256/32

This value MUST be used when k=secp256r1.

p=

Public Key value. A base-64 encoded representation of the bytestring formed by concatenating the value of X with one byte indicating whether Y is irrelevant, positive, negative, or explicit followed by the value of Y in case it is given explicitly. The one byte can take on the following values:

0

Y is not given explicitly, and the value of Y is irrelevant.

1

Y is not given explicitly but is positive and can be calculated from X.

2

Y is not given explicitly but is negative and can be calculated from X.

3

Y follows explicitly.

np=

Next preferred public key selector. This is a string of DNS labels separated by periods (".") that indicates a selector that may be tried next in case the current TXT record is unsatisfactory. This attribute is OPTIONAL.

The entity retreiving public keys from DNS MUST have assurance that the records were created by the owner of the given hostname. The use of a protection mechanism such as DNSSEC (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.) [5] is STRONGLY RECOMMENDED.

4.2.  Vouch-by-Reference Records

The list of vouching domains present in a Vouch-by-Reference Information block (Section 3.1.2 (Vouch-by-Reference Information Block)) can be used by middleboxes to check the reputation of a Message Source. To do so, a middlebox would lookup a TXT record at a name constructed by concatenating the last NSuffLabels labels of the Source DNS Name (this would normally not include the key selector or the string "_pickle") with the label "_vouch" followed by the domain of the vouching service. This is as described in Vouch-by-Reference (Hoffman, P., Levine, J., and A. Hathcock, “Vouch By Reference,” April 2009.) [3], although we extend the set of strings that can be placed in the resulting TXT record to correspond with the Situation levels available in the Situation field of the Vouch-by-Refernce Information block. When a vouching service returns a given Situation level, it means that it attests that the Initiator will responsibly use that Situation level or higher. The allowed strings are given below in Table 7 (Vouching Strings).

5.  Acknowledgements

6.  IANA Considerations

This memo includes no request to IANA.

7.  Security Considerations

8. Normative References

Authors' Addresses