One document matched: draft-trammell-plus-abstract-mech-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.30 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-trammell-plus-abstract-mech-00" category="info">
<front>
<title abbrev="Path Layer Mechanisms">Abstract Mechanisms for a Cooperative Path Layer under Endpoint Control</title>
<author initials="B." surname="Trammell" fullname="Brian Trammell">
<organization>ETH Zurich</organization>
<address>
<postal>
<street>Gloriastrasse 35</street>
<city>8092 Zurich</city>
<country>Switzerland</country>
</postal>
<email>ietf@trammell.ch</email>
</address>
</author>
<date year="2016" month="September" day="28"/>
<area>Transport</area>
<workgroup>PLUS BoF</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document describes the operation of three abstract mechanisms for
supporting an explicitly cooperative path layer in the Internet
architecture. Three mechanisms are described: sender to path signaling with
receiver integrity verification; path to receiver signaling with confidential
feedback to sender; and direct path to sender signaling.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>The boundary between the network and transport layers was originally defined
to be that between information used (and potentially modified) hop-by-
hop, and that used end-to-end. End-to-end information in the transport layer
is associated with state at the endpoints, but processing of network-layer
information was assumed to be stateless.</t>
<t>The widespread deployment of network address and port translation (NAPT) in
the Internet has eroded this boundary. Since the first four bytes after the IP
header or header chain – the source and destination ports – are frequently
used for forwarding and access control decisions, and are routinely modified
on path, they have de facto become part of the network layer. In-network
functions that exploit the fact that transport headers are in cleartext in the
absence of widespread deployment of IPsec <xref target="RFC4301"/> further erode this
boundary.</t>
<t>Evolution above the network layer and integrity of transport layer functions
is only possible if this layer boundary is reinforced. Asking on-path devices
nicely not to muck about in the transport layer and below – stating in an RFC
that devices on path MUST NOT use or modify some header field – has not
proven to be of much use here. A new approach is necessary, consisting of
cryptographic integrity protection of network and transport layer headers
which the endpoints choose to expose to the path, and cryptographic
confidentiality protection of transport layer headers not to be exposed.</t>
<t>We define the “path layer” to consist of the headers and associated functions
that are explicitly exposed to devices along the path in this scheme. This
document describes three abstract mechanisms for implementing path layer
communications. The first principles in the design of these mechanisms are
endpoint control, signaling transparency, and support of arbitrary
relationships between endpoints and path devices.</t>
<t>The principle of endpoint control means that all signaling, even from the
path, is initiated by a sending endpoint, allowing a sending endpoint to opt
into or out of path layer communications as it sees fit.</t>
<t>The principle of signaling transparency means that at least the semantic type
of all signals using these mechanisms must be visible to all path elements.
This makes it possible for users and network operators to use traffic
inspection to observe what is being signaled. As a last resort, users and
networks wishing to limit signaling using these mechanisms can simply drop
packets containing signals they would prefer not to have sent.</t>
<t>The principle of arbitrary relationship means that the basic mechanisms do not
require any trust or cryptographic state between endpoints and path elements
to function, though integrity protection and confidentiality for communication
with path elements can be layered over these mechanisms; definition of key
exchange and cryptographic protocols for this layering is out of scope for
this document, however.</t>
</section>
<section anchor="mechanism-definitions" title="Mechanism Definitions">
<t>Three abstract mechanisms suffice to implement in-band path layer communications,
given our first principles. First, a sender can make declarations about itself
or about traffic it is sending to devices along the path, relying on the
receiver to verify integrity of the declaration. Second, a sender can allow
path elements to make declarations about themselves or their treatment of
given traffic, by creating space for the path elements to do so. In this case,
the integrity of the presence, type, and size of this space is verified by the
receiver, but not the content of the declaration made by the path. Third, a
path element can make a declaration about a dropped packet back to the sender
of that packet.</t>
<t>These mechanisms are described in an implementation-independent way; however,
there are a few basic assumptions made by the design:</t>
<t><list style="symbols">
<t>There exists a technique by which packets can be selected and grouped by the
sending endpoint such that these groups are visible to devices along the path
(e.g. using an N-tuple).</t>
<t>The mechanisms can add information to selected packets in a communication
between two endpoints.</t>
<t>The mechanisms use a shared secret between the two endpoints provided by
some upper layer.</t>
<t>The confidentiality and integrity of upper layer’s headers and payload are
cryptographically protected by the upper layer.</t>
<t>The declarations carried by the mechanisms can be expressed in terms of key-
value pairs, such that the type and semantic meaning of the declaration are
completely defined by the key. The mechanisms don’t necessarily need to be
implemented using a generic key-value framing (e.g. CBOR <xref target="RFC7049"/>); the key
can be implied by a position in a defined packet header.</t>
</list></t>
<section anchor="sectxpath" title="Sender-to-Path Declarations">
<t>To make a declaration about a packet or flow to all path elements, the sender
adds a key-value pair to a packet within the flow. The fact that this is a
sender-to-path declaration is part of the definition of the key. Multiple
declarations can appear in a single packet. All the declarations within a
packet, together with other transport and network layer information which must
not be modified by the path, are protected by a message authentication code
(MAC) sent along with the packet, generated with a key derived from a secret
known only to the endpoints.</t>
<t>The receiver then verifies the MAC on receipt. Verification failure implies an
attempt to modify the header used by this mechanism, and therefore must cause
the transport association to reset.</t>
<t>This arrangement is illustrated in <xref target="figtxpath"/>.</t>
<figure title="Sender to Path Declaration" anchor="figtxpath"><artwork><![CDATA[
++=============++ ++=============++
|| app layer || || app layer ||
++=============++ ++=============++
|| transport || || transport ||
++=============++ ++=============++
| path | | path |
[ Sender ] ->| decl. X->A |-> [ Path ] ->| decl. X->A |-> [ Receiver ]
^ | MAC(path,udp) | | | MAC(path,udp) | |
| +---------------+ | +---------------+ |
| | UDP | | | UDP | |
| +---------------+ | +---------------+ |
| | IP | | | IP | |
| +---------------+ v +---------------+ v
declare X->A read X->A read X->A
compute MAC associate w/flow verify MAC
]]></artwork></figure>
</section>
<section anchor="secpathrx" title="Path-to-Receiver Declarations with Feedback">
<t>To allow one or more path elements to make a declaration about itself with
respect to a packet or a flow to the receiver, the sender adds a key-value
pair to a packet within the flow. The fact that this is a path-to-receiver
declaration is part of the definition of the key. Further, the value has a
fixed length of N bytes (which my also be part of the definition of the key).
Path-to-receiver declarations may be combined in a packet with sender-to-path
declarations as in <xref target="sectxpath"/>, and are covered by the same MAC. However,
when calculating the MAC for a path-to-receiver declaration, its value is
assumed to be an N-byte array of zeroes. The MAC therefore protects the
presence of the key and the length of the value, but not its content.</t>
<t>The initial value of a path-to-receiver declaration is up to the sender, and
is generally defined by the declaration itself. The behavior of a path element
in filling in a path-to-receiver declaration given which value is already
present is also part of the declaration defintion. Declarations may accumulate
by some operation (e.g., max, min, sum for measurement declarations), be
determined by the first or last path element, or be addressed to a specific
path element to fill in.</t>
<t>This arrangement is illustrated in <xref target="figpathrx"/>.</t>
<figure title="Path to Receiver Declaration" anchor="figpathrx"><artwork><![CDATA[
++=============++ ++=============++
|| app layer || || app layer ||
++=============++ ++=============++
|| transport || || transport ||
++=============++ ++=============++
| path | | path |
[ Sender ] ->| decl. Y->null |-> [ Path ] ->| decl. Y->B |-> [ Receiver ]
^ | MAC(path,udp) | ^ | MAC(path,udp) | |
| +---------------+ | +---------------+ |
| | UDP | | | UDP | |
| +---------------+ | +---------------+ |
| | IP | | | IP | |
| +---------------+ V +---------------+ v
request Y recognize Y read Y->B
compute MAC overwrite Y->B verify MAC (Y->null)
]]></artwork></figure>
<t>This mechanism allows the sender to allow the receiver to receive path
declarations. However, if it is the sender that needs to know the final result
of the path declaration, this can be fed back to the sender over an encrypted
channel. Depending on the characteristics of the upper layer, this encrypted
channel can either be provided by the upper layer, or be provided by the layer
implementing the mechanisms, using a key derived from the same secret known
only to the endpoints used to generate the MAC. The fact that a path-to-
receiver declaration should be fed back to the sender is part of the
definition of the key.</t>
<t>This arrangement is illustrated in <xref target="figfeedback"/>.</t>
<figure title="Receiver Feedback" anchor="figfeedback"><artwork><![CDATA[
+---------------+
| path |
| +crypt.-----+ |
| | feedback | |
| | Y->B | |
[ Sender ] <--------------------------------| +-----------+ |<- [ Receiver ]
^ | MAC(path,udp) | |
| +---------------+ |
| | UDP | |
| +---------------+ |
| | IP | |
V +---------------+ v
read Y->B feedback Y->B
verify MAC encrypt
compute MAC
]]></artwork></figure>
</section>
<section anchor="secpathtx" title="Direct Path-to-Sender Declarations">
<t>Path-to-receiver declaration is impossible if a path element will drop a
packet. In order to allow a path element to provide information about why a
packet was dropped, it can send back a packet containing only a path-to-sender
declaration. The fact that this is a direct path-to-sender declaration is part
of the definition of the key. A path-to-sender declaration packet can only
contain path-to-sender declarations. Since in the general case the path
element has no shared secret with which to generate a MAC, this declaration
cannot be integrity protected.</t>
<t>In order for a path-to-sender declaration to traverse any network address
translation (NAT) function along the path, the path element must send the
packet with the IP addresses and transport/encapsulation layer ports reversed.</t>
<t>The sender must indicate it is willing to receive path-to-sender declarations,
and this indication must include some nonce or other identifier that is hard
to guess by devices not on path, which is returned with the path-to-sender
declaration to identify the packet to which the declaration applies.</t>
<t>Only one path-to-sender declaration packet may be sent per dropped packet;
this mitigates the abuse of this mechanism for executing amplified reflection
attacks.</t>
<t>This arrangement is illustrated in <xref target="figpathtx"/>.</t>
<figure title="Direct Path to Sender Declarations" anchor="figpathtx"><artwork><![CDATA[
++=============++
send packet || app layer ||
| ++=============++
| || transport ||
| ++=============++
V | path |
[ Sender ] ->| MAC(path,udp) |-> [ Path ]
+---------------+ |
| UDP p->q | |
+---------------+ |
| IP s->r | |
+---------------+ V
drop packet
signal drop
+---------------+ |
| path | V
[ Sender ] <-| decl. Z->C |<- [ Path ]
| +---------------+
| | UDP q->p |
| +---------------+
| | IP r->s |
V +---------------+
read Z->C
]]></artwork></figure>
</section>
</section>
<section anchor="technical-considerations" title="Technical Considerations">
<t>A few details must be considered in the implementation of the mechanisms
described above; some are general, and some apply only in specific
circumstances. They are described in the subsections below.</t>
<section anchor="bootcrypto" title="Cryptographic Context Bootstrapping">
<t>These mechanisms rely on an upper layer to establish a cryptographic context
in order to establish a shared secret from which MAC keys can be derived. This
cryptographic state may be established with each transport session or may be
resumable across multiple transport sessions, depending on the upper layer’s
design. If no context exists, though, the integrity of the declarations made
via these mechanisms cannot be protected by MAC. We propose two possible
solutions to this situation:</t>
<t><list style="numbers">
<t>The mechanisms can be implemented such that MAC is mandatory. In this
arrangement, no sender-to-path and/or path-to-receiver declarations can be
made until cryptographic context is bootstrapped. The vocabulary of
declarations can therefore not include declarations that must be sent on the
first packet.</t>
<t>The mechanisms can be implemented such that the MAC is eventual. In this
arrangement, sender-to-path declarations can be made before cryptographic
context establishment, but are open to undetected modification along the path;
path-to-receiver declarations are not allowed before cryptographic context
establishment. A MAC for previous sender-to-path declarations must be sent
after cryptographic context establishment; lack of receiving this MAC within a
defined (and small) number of packets from the sender is treated by the
receiver as verification failure and leads to transport association reset.</t>
</list></t>
</section>
<section anchor="adding-integrity-and-confidentiality-protection-along-the-path" title="Adding Integrity and Confidentiality Protection Along the Path">
<t>If a path element and the sender share some cryptographic context through some
out-of-band means, sender to path declarations can also be integrity protected
using a MAC generated by the sender and carried within the declaration itself.
In this case, if the path element fails to verify the MAC, it simply ignores
the declaration.</t>
<t>Similarly, if a path element and the receiver share some cryptographic context
through some out-of-band means, path to receiver declarations can also be
integrity protected using a MAC generated by the path element and carried
within the declaration itself. The use of a MAC is part of the definition of
the key. In this case, if the receiver fails to verify the MAC, it causes a
transport association reset.</t>
<t>This design pattern can also be used to address sender-to-path declarations to
specific path elements: a declaration with an encrypted value is inherently
addressed to only those path elements that possess the private or secret key
to decrypt the value.</t>
<t>In each of these cases, the presence of a MAC within the declaration value
and/or encryption of the declaration value is part of the definition of the
key. Further definition of mechanisms for building cryptographic protocols
over these mechanisms is out of scope for this document.</t>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>This document has no actions for IANA. A future document specifying a concrete
implementation of these mechanisms and a vocabulary of declarations may create
and modify an IANA registry of such declarations. [EDITOR’S NOTE: please
remove this section at publication.]</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>This document describes abstract mechanisms by which endpoints can share
information about traffic flows with devices along the path, replacing the
functions currently performed using traffic inspection of cleartext transport
headers with explicit exposure when those headers are encrypted. We consider
four potential threats against the design of these abstract mechanisms:</t>
<t><list style="numbers">
<t>Injection of packets or declarations by an on-path attacker</t>
<t>Injection of packets declarations by an off-path attacker</t>
<t>Sender fingerprinting or other inference about the content of encrypted communications by an on-path attacker</t>
</list></t>
<section anchor="defending-against-on-path-injection-of-declarations" title="Defending against On-Path Injection of Declarations">
<t>The MAC generated by a sending endpoint protects against on-path injection of
declarations not authorized by the sender, or an on-path device spoofing the
sending endpoint. Even if one on-path device manages to spoof a declaration to
a device further along the path, MAC verification failure at the receiving
endpoint will lead to upper layer association reset.</t>
</section>
<section anchor="defending-against-off-path-injection-of-declarations" title="Defending against Off-Path Injection of Declarations">
<t>Since MAC verification requires the receiving endpoint, it may be possible for
an off-path attacker to spoof a declaration that an on-path device would not
be able to verify. In order to defend against this threat, the mechanisms
should be implemented by exposing a hard-to-guess token selected by a sending
endpoint and verified by a receiving endpoint as well as by on-path devices.
This token may itself take the form of a declaration, or appear in a header
enclosing the set of declarations.</t>
</section>
<section anchor="defending-against-fingerprinting-attacks-and-overexposure" title="Defending against fingerprinting attacks and overexposure">
<t>Since these abstract mechanisms are designed to explicitly expose metadata
about encrypted traffic, the concern naturally arises that overexposure of
metadata can be used to infer information about the type or content of
encrypted information, or that information radiated off a sending endpoint can
be used to create a fingerprint of that sender.</t>
<t>In order to defend against this threat, the vocabulary of signals to be used
with this mechanism must be designed in a restrictive way:</t>
<t><list style="symbols">
<t>Definition of obviously-overexposing signals must be prohibited by the
process used to define the vocabulary. Examples of obvious overexposure
include sharing end-to-end secrets with on-path devices, tagging flows with
a globally unique ID that can be associated with a sender (e.g. for mobility
applications), or exposure of endpoint location at high resolution.</t>
<t>Signals must be defined to use as few bits on the wire as possible, in order
to reduce the cross section of the path layer packet header that can be used
for fingerprinting, or potentially abused to coerce endpoints to add more
information about their traffic.</t>
</list></t>
<t>The first restriction can be implemented using an IANA registry for the
vocabulary of signals with a restrictive policy for addition of signals such
as Standards Action <xref target="RFC5226"/>, as well as a purposefully restricted
codepoint space. The second restriction can also be assisted by defining a
small maximum per-packet size for signals exposed using the mechanism, which
would also have overhead benefits.</t>
<t>We note that by replacing present plain-text transport headers with encrypted
transport headers, and allowing sending endpoints to explicitly expose (or not
expose) information about those, that the cross section available for
fingerprinting with these abstract mechanisms is much smaller than that
presented by the current TCP/IP stack;
see <xref target="I-D.trammell-privsec-defeating-tcpip-meta"/>.</t>
</section>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>This work is 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.</t>
<t>Thanks to Aaron Falk, Ted Hardie, Joe Hildebrand, Mirja Kuehlewind, Natasha
Rooney, Kyle Rose, and the participants at the PLUS BoF at IETF 96 in Berlin
for the conversations leading to and informing the publication of this
document. Special thanks to Mark Nottingham for posing the questions that led
to the design space for the mechanisms described herein.</t>
</section>
</middle>
<back>
<references title='Informative References'>
<reference anchor='RFC4301' target='http://www.rfc-editor.org/info/rfc4301'>
<front>
<title>Security Architecture for the Internet Protocol</title>
<author initials='S.' surname='Kent' fullname='S. Kent'><organization /></author>
<author initials='K.' surname='Seo' fullname='K. Seo'><organization /></author>
<date year='2005' month='December' />
<abstract><t>This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4301'/>
<seriesInfo name='DOI' value='10.17487/RFC4301'/>
</reference>
<reference anchor='RFC5226' target='http://www.rfc-editor.org/info/rfc5226'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></author>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'><organization /></author>
<date year='2008' month='May' />
<abstract><t>Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t>In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t>This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='26'/>
<seriesInfo name='RFC' value='5226'/>
<seriesInfo name='DOI' value='10.17487/RFC5226'/>
</reference>
<reference anchor='RFC7049' target='http://www.rfc-editor.org/info/rfc7049'>
<front>
<title>Concise Binary Object Representation (CBOR)</title>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author>
<date year='2013' month='October' />
<abstract><t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t></abstract>
</front>
<seriesInfo name='RFC' value='7049'/>
<seriesInfo name='DOI' value='10.17487/RFC7049'/>
</reference>
<reference anchor='I-D.trammell-privsec-defeating-tcpip-meta'>
<front>
<title>Detecting and Defeating TCP/IP Hypercookie Attacks</title>
<author initials='B' surname='Trammell' fullname='Brian Trammell'>
<organization />
</author>
<date month='July' day='29' year='2016' />
<abstract><t>The TCP/IP stack provides protocol features that can potentially be abused by on-path attackers to inject metadata about a traffic flow into that traffic flow in band. When this injected metadata is provided by an entity with knowledge about the natural person associated with a traffic flow, it becomes a grave threat to privacy, which we term a hypercookie. This document defines a threat model for hypercookie injection and hypercookie coercion attacks, catalogs protocol features that may be used to achieve them, and provides guidance for defeating these attacks, with an analysis of protocol features that are disabled by the proposed defeat mechanism. The deployment of firewalls that detect and reject abuse of protocol features can help, but the relative ease of injecting metadata for attackers on path, and trivial combination of metadata injection attacks, leads to a recommendation to add cryptographic integrity protection to transport layer headers to defend against injection attacks. tl;dr: at least with respect to metadata injection in the current Internet protocol stack, everything is ruined.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-trammell-privsec-defeating-tcpip-meta-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-trammell-privsec-defeating-tcpip-meta-00.txt' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:42:26 |