IETF P. McCann
Internet-Draft
Intended status: Standards Track S. Gilbert
Expires: June 10, 2011 Motorola, Inc.
December 7, 2010
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
McCann & Gilbert Expires June 10, 2011 [Page 1]
Internet-Draft Pickle Packet December 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Bearer Packet Filtering . . . . . . . . . . . . . . . . . 3
1.1.1. Filter using Network and Transport Header . . . . . . 3
1.1.2. Attack Detection Through Counting Packets . . . . . . 4
1.1.3. Filter Using Cookie Value . . . . . . . . . . . . . . 4
1.1.4. Cryptographic Header MAC . . . . . . . . . . . . . . . 4
1.1.5. Cryptographic Header and Payload MAC . . . . . . . . . 5
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
3. Pickle Packet Structure . . . . . . . . . . . . . . . . . . . 10
3.1. Payload Block Types . . . . . . . . . . . . . . . . . . . 14
3.1.1. Message Source/Destination Block . . . . . . . . . . . 14
3.1.2. Vouch-by-Reference Information Block . . . . . . . . . 18
3.1.3. Point-of-Contact Address Block . . . . . . . . . . . . 19
3.1.4. Binding Distribution Restriction Block . . . . . . . . 22
3.1.5. Authentication Results/Request . . . . . . . . . . . . 24
3.1.6. Application Data Block . . . . . . . . . . . . . . . . 27
3.1.7. Public Key Signature Block . . . . . . . . . . . . . . 27
3.1.8. Symmetric Key Signature Block . . . . . . . . . . . . 29
3.1.9. Symmetric Key Encryption Parameters Block . . . . . . 31
3.1.10. Pickle Fragment Block . . . . . . . . . . . . . . . . 32
4. Domain Name System Binding . . . . . . . . . . . . . . . . . . 32
4.1. Representation of Public Keys in DNS . . . . . . . . . . . 32
4.2. Vouch-by-Reference Records . . . . . . . . . . . . . . . . 34
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 35
8. Normative References . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
McCann & Gilbert Expires June 10, 2011 [Page 2]
Internet-Draft Pickle Packet December 2010
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.
+--------------+
|sources of DoS|
|attack packets|
+--------------+
|
|
+--------+ V congestible +-----------+
|original| +----------+ +---------+ channel |ultimate |
|sender |-->|IP network|-->|middlebox|-------------->|destination|
+--------+ +----------+ +---------+ +-----------+
Figure 1: Middlebox Mitigates Traffic Congestion DoS Attack
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
McCann & Gilbert Expires June 10, 2011 [Page 3]
Internet-Draft Pickle Packet December 2010
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
McCann & Gilbert Expires June 10, 2011 [Page 4]
Internet-Draft Pickle Packet December 2010
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 [1].
2. Protocol Overview
The message sequence chart in Figure 2 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.
McCann & Gilbert Expires June 10, 2011 [Page 5]
Internet-Draft Pickle Packet December 2010
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
Figure 2: Message Sequence Chart If Parties Initially Unknown to Each
Other
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
McCann & Gilbert Expires June 10, 2011 [Page 6]
Internet-Draft Pickle Packet December 2010
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, 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) are Server.net, and DNSs. The Point-of-
Contact Block shown in Figure 6 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) which in
this example has a registration Status Code (Table 4) 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
McCann & Gilbert Expires June 10, 2011 [Page 7]
Internet-Draft Pickle Packet December 2010
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) 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) to Mbox2 containing the
Point-of-Contact Address Block (Figure 6) which has a registration
Status Code (Table 4) 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) 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). It includes the name of a vouching service that will
vouch for it in a Vouch-by-Reference Information block
(Section 3.1.2). It signs the message with its public key by
including a Public Key Signature block (Section 3.1.7). The message
McCann & Gilbert Expires June 10, 2011 [Page 8]
Internet-Draft Pickle Packet December 2010
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) containing the client's Flow Nonce and
a forward HMAC Request payload using the format shown in Figure 13.
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. 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
McCann & Gilbert Expires June 10, 2011 [Page 9]
Internet-Draft Pickle Packet December 2010
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 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.
McCann & Gilbert Expires June 10, 2011 [Page 10]
Internet-Draft Pickle Packet December 2010
A pickle packet that does contain signaling, cookies, MACs, encrypted
payload, or payload that begins with the magic number is shown in
Figure 3.
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 //
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Layout of a Pickle Packet
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
McCann & Gilbert Expires June 10, 2011 [Page 11]
Internet-Draft Pickle Packet December 2010
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.
+----+----+---------------------------------------------------------+
| L0 | L1 | Description |
+----+----+---------------------------------------------------------+
| 0 | 0 | Fragment Signature is the first 4 octets of an |
| | | HMAC-SHA-1. |
| 0 | 1 | Fragment Signature is the first 12 octets of an |
| | | HMAC-SHA-1. |
| 1 | 0 | Fragment Signature is all 20 octets of an HMAC-SHA-1. |
| 1 | 1 | Fragment Signature is all 32 octets of an HMAC-SHA-256. |
+----+----+---------------------------------------------------------+
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). 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
McCann & Gilbert Expires June 10, 2011 [Page 12]
Internet-Draft Pickle Packet December 2010
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.
+------+-----------+------------------------------------------------+
| Msg | Name | Description |
| Type | | |
+------+-----------+------------------------------------------------+
| n/a | BARE | A plain packet of the given transport |
| | | protocol, with no pickle fields. If pickle |
| | | packets are multiplexed on the same transport |
| | | connection, the transport payload of a BARE |
| | | packet MUST NOT begin with 0x501c4b1e. |
| 1 | REGISTER | Publish a DNS entry with contact information, |
| | | and/or create forwarding state at intervening |
| | | middleboxes. This message MUST have 'S'=1, |
| | | 'H'=0, and 'L'=10 or 11. |
| 2 | ESTABLISH | Create state at each middlebox along the path. |
| | | This message MUST have 'S'=1, 'H'=0, and |
| | | 'L'=10 or 11. |
| 3 | REFLECT | Response to ESTABLISH, gives the recipient |
| | | identity information for downstream |
| | | middleboxes. This message MUST have 'S'=1, |
| | | 'H'=0, and 'L'=10 or 11. |
| 4 | DATA | Contains a pickled fragment of a transport |
| | | data segment encapsulated in an Application |
| | | Data Block Header (and possibly other block |
| | | types). This message may have any setting of |
| | | 'S', 'H', and 'L' bits that are acceptable to |
| | | the recipient. |
| 5 | RAWDATA | Contains a pickled fragment of a transport |
| | | data segment with no encapsulating block |
| | | header (note that RAWDATA still contains the |
| | | pickle packet header given in Figure 3). This |
| | | message may have any setting of 'S', 'H', and |
| | | 'L' bits that are acceptable to the recipient. |
+------+-----------+------------------------------------------------+
Table 2: Pickle Packet Message Types
McCann & Gilbert Expires June 10, 2011 [Page 13]
Internet-Draft Pickle Packet December 2010
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 Type | Name |
+------------+-----------------------------------------------------+
| 0x0001 | Message Source/Destination (Section 3.1.1) |
| 0x0002 | Vouch-by-Reference Information (Section 3.1.2) |
| 0x0003 | Point-of-Contact Address (Section 3.1.3) |
| 0x0004 | Binding Distribution Restriction (Section 3.1.4) |
| 0x0005 | Authentication Results/Request (Section 3.1.5) |
| 0x0006 | Application Data (Section 3.1.6) |
| 0x0007 | Public Key Signature (Section 3.1.7) |
| 0x0008 | Symmetric Key Signature (Section 3.1.8) |
| 0x0009 | Symmetric Key Encryption Parameters (Section 3.1.9) |
| 0x000a | Pickle Fragment (Section 3.1.10) |
+------------+-----------------------------------------------------+
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.
McCann & Gilbert Expires June 10, 2011 [Page 14]
Internet-Draft Pickle Packet December 2010
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") //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Message Source/Destination Block
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. 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
McCann & Gilbert Expires June 10, 2011 [Page 15]
Internet-Draft Pickle Packet December 2010
secret (LTSS) by running Elliptic Curve Cofactor Diffie-Hellman (as
specified in Section 5.7.1.2 of NIST SP 800-56A [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 [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 )
McCann & Gilbert Expires June 10, 2011 [Page 16]
Internet-Draft Pickle Packet December 2010
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),
and Public Key Signature (Section 3.1.7) 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.
McCann & Gilbert Expires June 10, 2011 [Page 17]
Internet-Draft Pickle Packet December 2010
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 [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. 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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: VBR-Info Block
Any middlebox through which the request passes can use one or more of
the vouching domains as given in Section 4.2. 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.
McCann & Gilbert Expires June 10, 2011 [Page 18]
Internet-Draft Pickle Packet December 2010
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.
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) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Point-of-Contact Address Block
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).
McCann & Gilbert Expires June 10, 2011 [Page 19]
Internet-Draft Pickle Packet December 2010
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.
+------+----------+-------------------------------------------------+
| Code | Name | Description |
+------+----------+-------------------------------------------------+
| 1 | ACCEPTED | The REGISTER was accepted and the binding |
| | | published. |
| 2 | ADDRDIFF | The REGISTER was not accepted because the |
| | | source of the REGISTER message did not match |
| | | the Point-of-Contact address and the 'F' bit |
| | | was not set to 1. |
| 3 | MIDBOX | The REGISTER was intercepted by a middlebox |
| | | that does address translation, and is offering |
| | | the translated address in the Point-of-Contact |
| | | field. |
| 4 | REDIRECT | The REGISTER or ESTABLISH should be re-sent to |
| | | the address given in the Point-of-Contact |
| | | field. |
+------+----------+-------------------------------------------------+
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
McCann & Gilbert Expires June 10, 2011 [Page 20]
Internet-Draft Pickle Packet December 2010
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
+------+---------+--------------------------------------------------+
| Type | Name | Description |
+------+---------+--------------------------------------------------+
| 1 | IPv4 | An IP Protocol number (e.g., 6 for TCP or 17 for |
| | | UDP) followed by a Port number followed by an |
| | | IPv4 address. |
| 2 | IPv6 | An IP Protocol number (e.g., 6 for TCP or 17 for |
| | | UDP) followed by a Port number followed by an |
| | | IPv6 address. |
| 3 | 48-bit | 6 octets containing a 48-bit IEEE MAC address. |
| | IEEE | |
| | MAC | |
| 4 | EUI-64 | A 64-bit Endpoint Unique Identifier. |
+------+---------+--------------------------------------------------+
Table 5: Address Type Values
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: IP Version 4 Address
McCann & Gilbert Expires June 10, 2011 [Page 21]
Internet-Draft Pickle Packet December 2010
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 |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: IP Version 6 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)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: IEEE MAC 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 64-bit EUI-64 Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: EUI-64 Address
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.
McCann & Gilbert Expires June 10, 2011 [Page 22]
Internet-Draft Pickle Packet December 2010
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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Binding Distribution Restriction Block
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
McCann & Gilbert Expires June 10, 2011 [Page 23]
Internet-Draft Pickle Packet December 2010
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.
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. //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Authentication Results/Request Block
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/
McCann & Gilbert Expires June 10, 2011 [Page 24]
Internet-Draft Pickle Packet December 2010
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.
+------+------------+-----------------------------------------------+
| Code | Name | Description |
+------+------------+-----------------------------------------------+
| 1 | ACCEPTED | The middlebox has accepted the flow and is |
| | | propagating the ESTABLISH message. |
| | | Subsequent messages should be signed as |
| | | indicated by the HMAC Requests. This value |
| | | is also used by the original source to |
| | | request that the connection be accepted. |
| 2 | HMACNEEDED | The middlebox has not accepted the flow |
| | | because needed HMACs were missing. |
| | | Subsequent messages should be signed as |
| | | indicated by the HMAC Requests. |
| 3 | REFUSED | The middlebox refused the connection. |
| 4 | BADTOPO | The middlebox cannot forward the ESTABLISH |
| | | message because it would require downstream |
| | | nodes to have visibility to topology that |
| | | should be hidden. |
+------+------------+-----------------------------------------------+
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 or
Figure 14.
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. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Format of a Forward HMAC Request
McCann & Gilbert Expires June 10, 2011 [Page 25]
Internet-Draft Pickle Packet December 2010
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. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Format of a Reverse HMAC Request
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). 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). 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
McCann & Gilbert Expires June 10, 2011 [Page 26]
Internet-Draft Pickle Packet December 2010
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 //
// //
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Application Data Block
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.
McCann & Gilbert Expires June 10, 2011 [Page 27]
Internet-Draft Pickle Packet December 2010
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) |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Public Key Signature Block
McCann & Gilbert Expires June 10, 2011 [Page 28]
Internet-Draft Pickle Packet December 2010
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.
McCann & Gilbert Expires June 10, 2011 [Page 29]
Internet-Draft Pickle Packet December 2010
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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Symmetric Key Signature Block
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).
McCann & Gilbert Expires June 10, 2011 [Page 30]
Internet-Draft Pickle Packet December 2010
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 |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Symmetric Key Encryption Parameters Block
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
McCann & Gilbert Expires June 10, 2011 [Page 31]
Internet-Draft Pickle Packet December 2010
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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Pickle Fragment Block
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:
McCann & Gilbert Expires June 10, 2011 [Page 32]
Internet-Draft Pickle Packet December 2010
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 [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).
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:
McCann & Gilbert Expires June 10, 2011 [Page 33]
Internet-Draft Pickle Packet December 2010
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 [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) 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 [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.
McCann & Gilbert Expires June 10, 2011 [Page 34]
Internet-Draft Pickle Packet December 2010
+------+-----------------+---------------------------------------+
| Code | TXT String | Description |
+------+-----------------+---------------------------------------+
| 0 | "all" | Unspecified situation. |
| 1 | "list" | See Section 6.2 of RFC5518 [3]. |
| 3 | "entertainment" | Personal entertainment. |
| 5 | "educational" | Research or training. |
| 7 | "transaction" | See Section 6.3 of RFC5518 [3]. |
| 10 | "safety" | A situation affecting public safety. |
| 13 | "emergency" | A serious life-threatening emergency. |
+------+-----------------+---------------------------------------+
Table 7: Vouching Strings
5. Acknowledgements
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
8. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Barker, E., Johnson, D., and M. Smid, "Recommendation for Pair-
Wise Key Establishment Schemes Using Discrete Logarithm
Cryptography (Revised)", NIST Special Publication 800-56A,
March 2007, <http://csrc.nist.gov/publications/nistpubs/800-56A/
SP800-56A_Revision1_Mar08-2007.pdf>.
[3] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By Reference",
RFC 5518, April 2009.
[4] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key Information",
RFC 5480, March 2009.
[5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
McCann & Gilbert Expires June 10, 2011 [Page 35]
Internet-Draft Pickle Packet December 2010
Authors' Addresses
Peter J. McCann
1074 N Stone Ct
Naperville, Illinois 60563
USA
Phone: +1 630 369 9693
Email: mccap@petoni.org
Steve Gilbert
Motorola, Inc.
1301 E. Algonquin Rd.
Schaumburg, Illinois 60196
USA
Phone: +1 847 576 0247
Email: steve.gilbert@motorola.com
McCann & Gilbert Expires June 10, 2011 [Page 36]