Path Layer UDP Substrate (PLUS)

Technical ConsiderationsBrian Trammell (@britram)

PLUS BoF — IETF 96 Berlin — 21 July 2016

ADVISORYEXPLICIT COOPERATION

P A R E N T A L

Explicit Cooperation• “Implicit cooperation” between endpoints and

middleboxes already widespread in the Internet, • where “cooperation” may be the wrong term:

some hacks and workarounds are quite hostile. • Explicit cooperation under endpoint control may be a

way to reduce tension in this tussle • Declarative, advisory signaling with no trust required

between endpoint and path. • Encrypt everything devices on path don’t need to see

(including transport headers), to prevent future “implicit cooperation” without sender authorization.

4

Three and a half mechanisms to make the path layer explicit• Sender – Path Signaling • Path – Receiver Signaling

• with encrypted feedback to sender

• Direct Path – Sender Signaling • information about

dropped packets

Application Layer

http etc

Transport Layer

tcp sctpudp

Internet Layer

ip4 ip6

Link Layerwifieth lte

Path Layer

5

Sender to Path (sender-side)

6

sender receivermiddle-box

IP

path

x: nsubflow

MAC

transport

application

Sender to Path (on-path)

7

sender receivermiddle-box

IP

path

x:subflow

MACn

5-tuple subflow x n

transport

application

Sender to Path (receiver-side)

8

sender receivermiddle-box

IP

path

x: nsubflow

MAC

5-tuple

subflow x:

key

nMAC

transport

application

Sender to Path Transport State Signaling

9

sender receivermiddle-

box

IP

path

startsubflow

MAC

IP

path

subflow

MACIP

path

subflow

MAC

5-tuple subflow

start

started

start

5-tuple

subflow

key

startMAC

tpt: SYN

application

tpt: SYN

applicationtpt: SYN

application

Path to Receiver (sender-side)

10

sender receivermiddle-box

IP

path

y: 0subflow

MAC

transport

application

Path to Receiver (on-path)

11

sender receivermiddle-box

IP

path

y:subflow

MACm

5-tuple subflow y m

transport

application

Path to Receiver (receiver-side)

sender receivermiddle-box

IP

transport

path

application

y: msubflow

MAC

5-tuple

subflow y:

key

0MAC

12

sender receivermiddle-box

IP

path

y: msubflow

MAC

5-tuple

subflow y:

key

0MAC

transport

application

Receiver Feedback

13

sender receivermiddle-box

IP

path

subflowMAC

feedback

y: m

Path Direct to Sender (sender-side)

14

sender receivermiddle-

box

IP s:r

path

subflowMAC

transport

application

Path Direct to Sender (on-path)

15

sender receivermiddle-

box

IP s:r

path

subflowMAC

transport

application

Path Direct to Sender (feedback)

sender receivermiddle-

box

IP r:s

path

subflowz: q

16

Anatomy of the Path Layer• UDP encapsulation

• userspace implementation

• ports for NAT • ~95% deployable

today • encoding for

signaling mechanisms • crypto to protect

transport headers and above

17

Internet Layer

ip4 ip6

Transport Layer

tcp+ sctp+

Path Layer

neo

UDP encapsulation

shimDTLS (or other crypto)

path signaling

meanwhile, on the spud@ietf.org list…

Is this a user tracking and network neutrality violation machine?

• Will it be possible for a middlebox to use PLUS to insert user identifiers in the server-bound stream of a client-server protocol? • No, unless the client specifically requests it. • (Note: possible without PLUS, out of band, today)

• Will it be possible to use PLUS to require a client to insert a particular kind of metadata into a stream? • Bad news: yes; no technical solution exists here. • (Worse news: also many ways to do this without PLUS) • Good news: PLUS brings transparency to this behavior.

19

Internet Layer

ip4 ip6

Transport Layer

tcp’ sctp’

Path Layer

neo

UDP encapsulation

shim layerDTLS (or other crypto)

path signaling

Can we make transport innovationwork without explicit cooperation?• draft-herbert-transports-over-udp

• x over DTLS over UDP. • Make transport innovation

possible with crypto. • Breaks middleboxes.

• This is a feature.

• Equivalent to PLUS when neither endpoint decides to expose anything to the path.

20

Can we use IPv6 extension headers?

• IPv6 extension headers can be used to implement PLUS mechanisms • Ignore IPv4 in future deployments • DO to expose to path:

hack, but more deployable • HBH for exchange with path:

cleaner, but less deployable • DO/HBH already supported in

most socket APIs • But: more impaired than UDP

Internet Layer

Transport Layertcp’ sctp’

Path Layer

neo

DTLS (or other crypto)

ip6

base header

DO/HBH EH

path signaling

21

web MX NSDO 89.5% 88.5% 79.7%

HBH 61.0% 54.5% 45.9%

1-p(loss), 8-byte DO/HBH to Alexa top 1M domains, 8.2014-6.2015

(draft-ietf-v6ops-ipv6-ehs-in-real-world-02)

Can we use UDP Options?• draft-touch-tsvwg-udp-options

• add option space to UDP in a “gap” between the UDP and IP lengths of a packet.

• Allows optional data to be added to existing UDP applications in a backward compatible manner.

• Proposal: use this option space for PLUS

• Are these the same problem? • Must be in-kernel: no

userspace implementation.

Internet Layer

ip4 ip6

Transport Layer

tcp’ sctp’

Path Layer

neo

UDP encaps

DTLS (or other crypto)UDP opt trailerpath signaling

22

Do we need to choose now?

and in conclusion…

Things we need• A mechanism for making widespread cooperation

between endpoints and middleboxes explicit • Endpoint control over explicit cooperation • A clear boundary between what the path can see

and what it cannot, enforced by encryption • A design for this facility that deploys on the

endpoints from day zero • All this without requiring a trust relationship

between the endpoints and middleboxes

25