| Network Working Group | B. Trammell |
| Internet-Draft | M. Kuehlewind |
| Intended status: Experimental | ETH Zurich |
| Expires: September 14, 2017 | March 13, 2017 |
Path Layer UDP Substrate Specification
draft-trammell-plus-spec-01
This document specifies a common Path Layer UDP Substrate (PLUS) wire image for encrypted transport protocols carried over UDP. The base PLUS header carries information for driving a minimal state machine at middleboxes described in [I-D.trammell-plus-statefulness], and provides optional exposure of additional information to devices along the path using the mechanism described in [I-D.trammell-plus-abstract-mech].
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 September 14, 2017.
Copyright (c) 2017 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.
This document defines a wire image for a Path Layer UDP Substrate (PLUS), for limited exposure of information from encrypted, UDP-encapsulated [RFC0768] transport protocols. The wire image implements signaling to drive the minimal state machine defined in [I-D.trammell-plus-statefulness] as well as optional exposure of additional information to devices along the path using the mechanism described in [I-D.trammell-plus-abstract-mech].
As discussed in [I-D.hardie-path-signals], basic information about flows currently exposed by TCP are missing from transport protocols that encrypt their headers. Given the ossification of protocol wire images due to the widespread deployment of stateful network devices that rely on header inspection, this header encryption is necessary to support transport protocol evolution. However, the loss of basic information for on-path state maintenance as well as network performance measurement, diagnostics, and troubleshooting via header encryption makes network management more difficult. The PLUS wire image defined by this document aims to mitigate this difficulty, allowing deployment of encrypted protocols without loss of essential in- network functionality.
This wire image is intended primarily to support state maintenance and measurement; the principles of measurement and primitives we aim to support are drawn from recent work on explicit measurability in protocol design [IPIM].
The words “MUST”, “MUST NOT”, “SHOULD”, and “MAY” are used in this document. It’s not shouting; when these words are capitalized, they have a special meaning as defined in [RFC2119].
Every packet in each direction of a flow using PLUS carries a PLUS header. This can be either a basic header, or an extended header. The PLUS basic header supports multiplexing using a connection token; basic state maintenance using association and confirmation signals, packet serial numbers, and a two-way stop signal; and basic measurability using packet serial number echo. The format of the basic header, together with the UDP header, is shown in Figure 1.
The extended header is defined in Section 3.
3 2 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +------------------------------+-------------------------------+ | UDP source port | UDP destination port | +------------------------------+-------------------------------+ | UDP length | UDP checksum | +------------------------------+-----------------------+-+-+-+-+ | magic |L|R|S|0| +------------------------------------------------------+-+-+-+-+ | | +- connection/association token CAT -+ | | +--------------------------------------------------------------+ | packet serial number PSN | +--------------------------------------------------------------+ | packet serial echo PSE | +--------------------------------------------------------------+ / \ \ transport protocol header/payload (encrypted) / / \
Figure 1: PLUS header with basic exposure
Fields are encoded in network byte order and are defined as follows:
Since PLUS is designed to be used for UDP-encapsulated, encrypted transport protocols, overlying transports are presumed to provide encryption and integrity protection for their own headers. For the sake of efficiency, it is also assumed that this integrity protection can be extended to the bits in the PLUS Basic Header.
When a sender has a packet ready to send using PLUS, it determines the values in the Basic Header as follows:
When a receiver receives a packet containing a PLUS Basic Header, it processes the values in the Basic Header as follows:
The basic header provides all the signals necessary to drive the transport- independent state machine described in [I-D.trammell-plus-statefulness], as shown in Figure 2.
`- - - - - - - - - - - - - - - - - - - - - - - - - - - -'
` +============+ a->b +============+ '
` / \--------->/ \<-+ '
+--->( zero ) ( uniflow ) | a->b '
^ ` \ /<---------\ /--+ '
| ` +============+ TO_IDLE +============+ '
| `- - - - - - - - - - - - - - - | b->a - - - - - - - - -'
| V
| +============+
| TO_IDLE / \
+<-----------------------( associating )
| \ /
| +============+
| | a->b
| V
| +============+
| TO_ASSOCIATED / \<-+
+<-----------------------( associated ) | a<->b
| \ /--+
| +============+
| | stop y->z
| V
| +============+
| TO_ASSOCIATED / \<-+
+<-----------------( stop-wait ) | a<->b
| \ /--+
| +============+
| | stop z->y
| V
| +============+
| TO_STOPPING / \
+------------( stopping )
\ /
+============+
Figure 2: Transport-independent state machine as implemented by PLUS
On the first packet with a PLUS header forwarded by an on-path device for a given 5-tuple plus CAT, the device moves that flow from the zero state to the uniflow state. The device retuens the flow to zero state after not seeing a packet on the same flow in the same direction with the same CAT within a timeout interval TO_IDLE. Otherwise, it stays in uniflow state and continues forwarding packets, as long as it only observes packets in the same direction as the initial packet. (the a->b direction in Figure 2).
A PLUS-aware on-path device forwarding a packet with a PLUS header with a reversed 5-tuple and identical CAT (the b->a direction in Figure 2) to a flow in the uniflow state, moves that flow to the associating state. It then waits to see a packet with a PSE in the a->b direction equal to the PSN on the first reverse packet; on receipt of this packet, the device moves the flow to associated state. Otherwise, it drops state after a timeout interval TO_IDLE.
Once a flow has moved to the associated state, it will remain in that state for a timeout interval TO_ASSOCIATED. The on-path device forwards any packet with a PLUS header in either direction for this flow. It resets the TO_ASSOCIATED timer for every packet it forwards in this state.
A PLUS-aware on-path device forwarding a packet for a flow in the associated state with an S flag set moves that flow to stop-wait state. It stores the PSN on the packet causing the transition, and continues forwarding packets as if in associated state, dropping state on timeout interval TO_ASSOCIATED.
When it sees a packet in the opposite direction with the S flag set and the PSE set to exactly the stored PSN, it transitions the flow to stopping state. The device will forward packets in both directions for flows in the stopping state within a timeout interval TO_STOPPING; these packets will not reset the timer.
Note that even though the S flag is integrity-protected end to end, a packet with the S flag set could be forged by one on-path device to drive the flow into stop-wait state on all downstream devices. However, this forgery is of severely limited utility. First, it would require coordination between attackers on both sides of a given on-path device in order to forge a confirmation of the stop signal – a flag with the S bit set and a valid PSE corresponding to the PSN of the first stop signal to drive the flow into stopping state. Second, the information in the Basic Header on each packet will drive the state machine into associated state even in the middle of a flow, enabling fast recovery even in the case of such a coordinated attack.
One end of a PLUS association may change its address while maintaining on-path state; e.g. due to a NAT change. A PLUS-aware on-path device that forwards a packet for a flow in the zero state, where one of the endpoint identifiers (address and port) and the CAT, but not the other endpoint identifier, match a flow in a non-zero state, treats that packet as belonging to the existing flow, and updates the endpoint identifier.
The basic header trivially supports passive two-way delay measurement as well as partial loss estimation at a single observation point on path.
To calculate two-way delay, an observation point calculates the delay between seeing a PSN and a corresponding PSE in each direction, then adds the delays from each direction together. The fact that the PSN increments by one for every packet makes this measurement much simpler than the equivalent measurement using TCP sequence and acknowledgment numbers.
[EDITOR’S NOTE: specify this fully.]
Loss and reordering upstream from an observation point in each direction can be estimated through examination of the PSN sequence observed. A skipped PSN not seen within a specified interval can be counted as a lost packet, and the extent of reordering estimated by the degree of skipping seen in those skipped PSNs that are later observed. Since PLUS does not expose information about retransmissions (and, indeed, may not even carry a transport that uses retransmission for loss recovery), loss downstream from the observation point cannot be observed.
Additional facilities for communicating with on-path devices under endpoint control are provided by the PLUS Extended Header. The extended header shares the layout of its first 20 bytes with the PLUS Basic Header, except the Extended Header bit (0x01 on byte 11) is set. As with the Basic Header, overlying transports are presumed to provide encryption and integrity protection for the PLUS Extended Header. The Extended Header has a 1-byte type field, a 6-bit length field, a 2-bit Integrity indicator, and variable-length value field for the Path Communication Function (PCF):
3 2 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +------------------------------+-------------------------------+ | UDP source port | UDP destination port | +------------------------------+-------------------------------+ | UDP length | UDP checksum | +------------------------------+-----------------------+-+-+-+-+ | magic |L|R|S|1| +------------------------------------------------------+-+-+-+-+ | | +- connection/association token CAT -+ | | +--------------------------------------------------------------+ | packet serial number PSN | +--------------------------------------------------------------+ | packet serial echo PSE | +---------------+-----------+---+------------------------------+ | PCF Type | PCF Len | I | \ +---------------+-----------+---+ PCF value (variable) / / \ +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + \ / / transport protocol header/payload (encrypted) \ \ /
Figure 3: PLUS extended header with 1-byte PCF
The extended header is generally used to expose or request information from/to the path. If the value field is integrity protected it MUST NOT be changed by an element on the network path and provides only consumable information. Non-integrity protected parts of the value field carry a scratch space for path elements to provide the requested information defined by the PCF type. The type of the PCF determines the semantics of the value field and limits the intended use of the scratch space. A middlebox only needs to check for PCF types that are relevant for the function that middlebox provides. Knowing the type, also means that the semantics of the value field are fully known. Therefore a middlebox does not need to check the length and integrity field. These field are provided for receiver-side handling on unknown PCF types.
If a sender requests information from a path, these are generally used to expose information about the traffic for measurement or diagnostic purposes. These signals generally take the form of accumulators: initialized to some value by the sender, and subject to some aggregation function by each on-path device that understands them. In any case, the information sent and received is to be treated as advisory only, given its integrity cannot be checked.
A PLUS receiver that receives a PLUS packet with an extended header and an unknown PCF type where the integrity indication is smaller than 11, MUST feed the non-integrity-protected part of the PCF value field back to the sender, using an encrypted feedback channel provided by the upper layer protocol. The sender usually consumes this data as it has requested it previously from the path. The sender SHOULD check the reasonability of the received information, as follows:
The PCF types 0x00 and 0xff are used for special purposes. 0x00 indicates that another 1-byte type field is followed (before the length and integrity indication) to provide future extensibility. The type 0xff indicates that that PLUS payload data follows (without a PDF length and integrity indication). The semantics of this PLUS payload are not specified in this revision of this document but e.g. can be used to carry ICMP messages over PLUS.
If the length field is zero, the integrity indication field is not specified and reserved for future use. It MUST be set to zero and ignored by the receiver.
We have identified the following signals that can be exposed by the sender as potentially useful for measurement and diagnostic purposes. These signals are advisory only, and should not be presumed by either the endpoints or devices along the path to affect forwarding behavior. Details of type and encoding for these information
We have identified the following signals for request from the path as potentially useful. Note that accumulated values for use at the sender must be fed back to the sender by the overlying transport, and that the presence of non-PLUS aware devices on path at breaks in MTU mean that the accumulated value can only be used as a hint to processes for measurement and discovery of the accumulated values at the sender.
Here we discuss considerations for the implementation of overlying transports on PLUS, and their deployment in the Internet
[EDITOR’S NOTE: Since the overlying transport is responsible for providing the cryptographic context used for integrity protection and feedback, and may be responsible for feedback as well, the “northbound” interface needs to be concretely specified in a future revision of this document.]
[EDITOR’S NOTE: Discovery is currently explicitly out of band. Should there be a way for a PLUS-aware overlying transport to discover whether its peer wants to use a PLUS- or non-PLUS variant of the transport? This is a specific case of the generalized multi-transport discovery and negotiation problem, so whatever happens here should be interoperable with deployed/deployable approaches.]
This document has no actions for IANA. Path communication field types and PLUS magic numbers may be moved to a Standards Action registry in a future revision.
This document describes the PLUS Basic and Extended Headers, and the protocol they support. This protocol can be used to expose information to devices along the path to replace the analysis of transport- and application-layer headers when those headers are encrypted. Care must be taken in the exposure of such information to ensure no irrelevant application and/or user confidential information is exposed.
PLUS itself contains some security-relevant features. In concert with an encrypted overlying transport, the PLUS Basic and Extended Headers are integrity-protected to prevent manipulation on-path of any value except Path to Receiver values; this integrity protection prevents path elements from injecting values without explicit sender involvement, or from being stripped from the PLUS Extended Header.
The CAT and PSE described in Section 2 taken together, provide entropy to prevent on-path devices from being driven into incorrect states by off-path attackers. Bidirectional stop signaling as in Section 2.3.2 requires an on-path attacker of a given middlebox to forge traffic on both of the middlebox’s interfaces to drive a middlebox to inappropriately drop state for a flow.
This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat for Education, Research, and Innovation under contract no. 15.0268. This support does not imply endorsement. Thanks to Ted Hardie, Joe Hildebrand, Mark Nottingham, and the participants of the PLUS BoF at IETF 96 in Berlin for input leading to this design; and to Gorry Fairhurst for the detailed review.
| [RFC0768] | Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |