PLUS Protocol
draft-hildebrand-plus-protocol

Abstract

Minimal in-band firewall and load balancer signaling for UDP.

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 February 5, 2017.

Copyright Notice

Copyright (c) 2016 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.

1. Introduction

This document defines a common minimal path layer protocol for UDP- encapsulated transport protocols with in order to provide minimal, transport- independent state exposure to support firewall and load balancer operation [EDITOR’S NOTE cite appropriate section of draft-kuehlewind-plus-ps once it exists].

1.1. Requirements

• Hint to Initiator’s network path that PLUS is likely in use
• Hint to Initiator’s network path that Initiator wants to initiate a new connection
• Further indication to path that PLUS protocol is in use when Responder’s messages are seen by the path, better than 5-tuple.
• Matching Responder’s packets to Initiator’s intent to communicate, better than 5-tuple

2. Terminology

• Initiator: The active opener of a transport-layer association. In a client- server protocol, this is generally the client.
• Responder: The listener (passive opener) of a transport-layer association. In a client-server protocol, this is generally the server.
• Upper-layer transport: The transport protocol which uses PLUS for common signaling.

3. Protocol Specification

The PLUS protocol fits between the UDP header and the (encrypted) upper layer transport header and payload, adding eight bytes to each packet sent by the initiator, and four bytes to each packet sent by the responder. The initiator’s PLUS header allows elements on the network path that can see both inbound and outbound traffic for an association (including typical firewalls and load balancers) to group packets together into flows with better accuracy than provided by the 5-tuple of (Source Address, Source Port, Destination Address, Destination Port, Protocol).

3.1. Bit pattern: Initiator

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      UDP Source Port          |   UDP Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         UDP Length            |      UDP Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Magic                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Association Token                 |R|X|   tflags  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Upper Layer Transport Header/Payload             |
|                             . . .                             |

The following bits are defined:

• Magic: 32 bits. Magic numbers should be chosen such that they do not appear as the first 32 bits of any widely deployed UDP-based protocol, to allow initiator packets to be probabilistically separated from reflected UDP traffic. For the version of the PLUS protocol described in this document, the value of the Magic field is 0xd80000d8.
• Association Token: 24 bits. A cryptographically random token chosen by the initiator for this association.
• R bit (Reset): The initiator sets this bit to indicate the association is closing.
• X bit (Reserved): Reserved for future use in this protocol. Must be zero.
• tflags: 6 bits: available for use in the next layer

3.2. Bit pattern: Responder

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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Source Port           |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         UDP Length            |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        HMAC                   |R|X|   tflags  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The following bits are defined:

• hmac, 24 bits: HMAC_SHA256(magic, ConnectionID), truncated
• R, 1 bit: Reset
• X, 1bits: reserved for future use in this protocol
• tflags: 6 bits: available for use in the next layer

3.3. Indication of implementation

The receiver performs HMAC_256(0xd80000d8, Association Token), and uses the first 3 bytes as the first 3 bytes of the reply. This is used as a further hint that the magic number use was intentional. Call this function Indicator(Association Token).

Usefully, none of these truncated HMACs return the magic number.

3.4. Reset bit

Set the Reset bit to tell the path that you’re shutting down. Work will need to be done on this section to define what actions the path will take; one possible approach is to shorten the association timer to a smaller, constant value.

Upper-layer transports should consider providing security around this bit before trusting that it comes from the other endpoint.

4. Processing

Basic idea: Initiator sends bits defined in Section 3.1, Responder sends bits defined in Section 3.2. Initiator always has to send first over every new path.

4.1. Processing by applications

• If the RSV bit is set, ignore the packet
• Initiator: If the hmac doesn’t match what you expect, it’s either an attack or leftover traffic from a previous connection. Maybe send an unsigned RST? (maybe this is a policy or transport-specific decision)
• Responder: If the magic number isn’t there, it’s likely an attack. Probably best to ignore it.

4.2. Processing by path elements

• Assume that all bits are protected by next layer, so you can’t change them. Even if you could change them, you may as well just drop the packet, since delivery won’t work.
• Don’t think that having RSV set means this is an attack. It’s just something we haven’t specified as of the time you wrote your code.

4.3. From inside to outside:

• Match magic number
  • If not, treat as non-PLUS UDP
• Forward 6tuple = 5tuple + Association Token
• Reverse 6tuple = Reverse 5tuple + Indicator(Association Token)
• Look up Forward
  • If not, create state keyed by Forward and Reverse
• Reset timer
  • When timer fires, either drop state or send RST hint both ways without e2e crypto
• Allow

4.4. From outside to inside:

• Look up Reverse, allow if match
  • If not, treat as non-PLUS UDP

(TODO: determine if reverse timer is useful)

5. Guidelines for next layer

New transport’ protocols like QUIC.

• Define tflags as you see fit
• Consider if these bits need protection. At least tflags do.
• Consider multipath consequences, send before you receive on each path, and consider using a different Association Token on different paths to make tracking harder. If so, figure out how load balancers are going to deal with the problem.

6. Security Considerations

Next layer transport protocols SHOULD discuss whether any of these bits need to be protected.

Discuss the actual number of bits that window tracking gives you for TCP. Contrast this with how useful this would be for tracking people.

Association Tokens MUST NOT be under the control of untrusted code, like JavaScript. It’s likely there’s a reason for making them not available to untrusted code as well.

7. IANA Considerations

Do we need a registry of magic numbers?

8. Informative References

Authors' Addresses

Table of Contents

• 1. Introduction
• 1.1. Requirements
• 2. Terminology
• 3. Protocol Specification
• 3.1. Bit pattern: Initiator
• 3.2. Bit pattern: Responder
• 3.3. Indication of implementation
• 3.4. Reset bit
• 4. Processing
• 4.1. Processing by applications
• 4.2. Processing by path elements
• 4.3. From inside to outside:
• 4.4. From outside to inside:
• 5. Guidelines for next layer
• 6. Security Considerations
• 7. IANA Considerations
• 8. Informative References
• Authors' Addresses