Efficient Cross-Layer Negotiation Bryan Ford Janardhan Iyengar - - PowerPoint PPT Presentation

▶
efficient cross layer negotiation
SMART_READER_LITE
LIVE PREVIEW

Efficient Cross-Layer Negotiation Bryan Ford Janardhan Iyengar - - PowerPoint PPT Presentation

Jul 04, 2023 307 likes •697 views

Efficient Cross-Layer Negotiation Bryan Ford Janardhan Iyengar MPI-SWS and Franklin & Marshall Yale University College Presented at HotNets-VIII, October 22, 2009 Tng: Transport Next Generation Project Support: NSF FIND grants

slide-1
SLIDE 1

Efficient Cross-Layer Negotiation

Bryan Ford MPI-SWS and Yale University Janardhan Iyengar Franklin & Marshall College Presented at HotNets-VIII, October 22, 2009 “Tng: Transport Next Generation” Project

Support: NSF FIND grants CNS-0916413 and CNS-0916678

slide-2
SLIDE 2

A Proliferation of Layers and Layer Combinations

SCTP DCCP DTLS IPv6 IPsec UDP HTTP DNS RTP FTP Application SSL Transport Security TCP UDP Transport IPsec Network Security IP Network Ethernet Token-Ring PPP Data Link TCP SSL HTTP IPv6 IPsec IPsec UDP Teredo IPv6 (DirectAccess) HTTP SSL TCP IP Ethernet

slide-3
SLIDE 3

Future: Ever More Layers/Combinations?

Application Stream Stream Network Link Channel

Multi-Streaming Transports

SCTP [rfc4960], SST [SIGCOMM'07] Network Link Application Subflow Multipath Transport Subflow

Multipath Transports

SCTP [rfc4960], MPTCP [WIP] Network Link Application Endpoint Flow Semantic Isolation

Further Decomposition [“Breaking Up the Transport Logjam”,

HotNets'08]

slide-4
SLIDE 4

The Negotiation Problem

Decisions, decisions!

Network Transport Transport Security Application

IPv4 IPv6 TCP SCTP SSL HTTP IPv4 IPv6 UDP DCCP DTLS SIP IAX

slide-5
SLIDE 5

Compatibility and Preference

Which combinations do both endpoints support? Which combinations do they prefer?

IPv4 IPv6 UDP DCCP DTLS SIP IAX

Host A Host B

IPv4 IPv6 UDP DCCP DTLS SIP IAX

?

slide-6
SLIDE 6

Talk Outline

  • Background and Alternatives
  • A Model for Negotiation
  • Negotiation Transport Protocol
  • Discussion, Conclusion
slide-7
SLIDE 7

Background and Alternatives

slide-8
SLIDE 8

Approach 0: Name Encoding

[draft-wood-tae- specifying- uri-transports]

http++sctp:// means:

HTTP SCTP IP

http++ssl++sctp:// means:

HTTP SCTP IP SSL

?

http:// means:

HTTP TCP IP

[rfc2616]

https:// means:

HTTP TCP IP SSL

[rfc2818]

slide-9
SLIDE 9

Disadvantages of Name Encoding

Loss of Transparency

– User cares about application, not underlying stack...

but is forced to see and care about underlying stack

– When underlying stack changes, URLs change/break

  • redirectors proliferate between http:// and https:// spaces

Loss of Compatibility

– If user puts “http++sctp://...” link on a web page,

legacy browsers break; cannot fall back to TCP

Where Do You Stop?

– “http++tls++tcp++ipv6++ethernet” ???

slide-10
SLIDE 10

Approach 1: Try and Fall Back

Host A Host B

SCTP INIT TCP INIT SCTP RST TCP ACK

slide-11
SLIDE 11

Challenge 1: Controlling Delay

  • Failures can incur timeouts (e.g., due to NATs)
  • ...potentially compounded by layering

UDP DCCP

Host A Host B

UDP DCCP

Timeout(s)

IPv4 IPv6 DTLS SIP IAX IPv4 IPv6 DTLS SIP IAX

Timeout(s) Timeout(s) Timeout(s)

slide-12
SLIDE 12

Approach 2: Try in Parallel

Host A Host B

SCTP INIT TCP INIT SCTP RST TCP ACK

slide-13
SLIDE 13

Challenge 2a: Redundant State

Host A Host B

SCTP INIT TCP INIT SCTP ACK TCP ACK

slide-14
SLIDE 14

SIP UDP IPv4 SIP UDP IPv4 DTLS IAX UDP IPv4 IAX UDP IPv4 DTLS SIP DCCP IPv4 SIP DCCP IPv4 DTLS IAX DCCP IPv4 IAX DCCP IPv4 DTLS SIP UDP IPv6 SIP UDP IPv6 DTLS IAX UDP IPv6 IAX UDP IPv6 DTLS SIP DCCP IPv6 SIP DCCP IPv6 DTLS IAX DCCP IPv6 IAX DCCP IPv6 DTLS

Challenge 2b: Combinations

Layering can lead to explosion of choices

IPv4 IPv6 UDP DCCP DTLS SIP IAX

Host A Host B

slide-15
SLIDE 15

Approach 3: Out-of-Band Information

Host A Host B

DNS++ Req DNS++ Reply

IPv4 IPv6 UDP DCCP DTLS SIP IAX

SIP DCCP IPv6 DTLS

DNS Server

slide-16
SLIDE 16

Challenge 3a: Administration

Host B DNS Server

“Dynamic DNS++”?

DNS server must know:

  • Name→IP mapping

(as before)

  • Entire protocol stack

supported by Host B

  • Protocol options...?

⇒ Synchronization Nightmare?

slide-17
SLIDE 17

Challenge 3b: E2E Robustness

If endpoints agree on configuration X, will it work?

IPv4 IPv6 UDP DCCP DTLS SIP IAX

Host A Host B

IPv4 IPv6 UDP DCCP DTLS SIP IAX IPv4 IPv6 UDP DCCP

Middlebox

slide-18
SLIDE 18

Our Solution: Negotiation

  • Hosts explicitly describe possible configurations

during initial “meta-communication” exchange, before actual communication commences

Host A Host B

“Hi, I speak: ”

IPv4 IPv6 UDP DCCP DTLS SIP IAX

“Hi, I speak: ”

IPv4 IPv6 UDP DCCP DTLS SIP IAX

slide-19
SLIDE 19

A Model for Negotiation

slide-20
SLIDE 20

Negotiation Model Overview

1.Initiator sends a Protocol Graph Proposal 2.Responder returns Revised Protocol Graph 3.(Optional) further protocol graph revision steps 4.Peers commit, Acknowledge Protocol Graph 5.Peers communicate via negotiated protocols

slide-21
SLIDE 21

Message 1: Initiator → Responder: Propose Protocol Graph

TCP DCCP TLS DTLS

  • pt1
  • pt2
  • pt1
  • pt2
  • pt1
  • pt2
  • pt1
  • pt2

(alternatives) goal (SIP)

  • pt1
  • pt2

base (IP) Negotiation Message 1

Host A Host B

slide-22
SLIDE 22

Negotiation Message 2

Host A Host B

Message 2: Responder → Initiator: Revise Protocol Graph

TCP DCCP TLS DTLS

  • pt1
  • pt2
  • pt1
  • pt2
  • pt1
  • pt2
  • pt1
  • pt2

base (IP) goal (SIP)

  • pt1
  • pt2
slide-23
SLIDE 23

Message 3: Initiator → Responder: Acknowledge Protocol Graph

TCP TLS

  • pt1

base (IP) goal (SIP)

  • pt2

Negotiation Message 3

Host A Host B

slide-24
SLIDE 24

Message 4+: According to Negotiated Stack

TCP TLS SIP

Host A Host B

Normal Packets

slide-25
SLIDE 25

Concurrent Protocol Initialization

Whenever feasible:

  • embed protocol-specific handshake info into graph
  • run handshakes concurrently while negotiating
  • commit only negotiated configuration atomically

Host A Host A

TCP DCCP TLS DTLS

ClientHello ClientHello INIT Request

SIP

REGISTER

IP 1 TCP DCCP TLS DTLS

ServerHello ServerHello INIT-ACK Reply

SIP

200 OK

IP 2

slide-26
SLIDE 26

Key Benefits of Negotiation Model

  • Supports backward-compatible evolution

– New smart nodes can fall back on old dumb protocols

  • Happens strictly between nodes concerned

– Users don't have to care (e.g., between http: & https:) – Name server administrators don't have to care

  • Protocol graph representation scales to handle:

– Arbitrarily deep protocol stacks – Many alternatives per layer

  • Setup whole “layer cakes” in minimal # of RTTs

– Regardless of protocol stack depth

slide-27
SLIDE 27

Further Challenges & Extensions

(see paper)

  • Multi-Round Negotiation

– due to dependencies, hiding of alternatives, graph size

  • Negotiation Across Multiple Contexts

– IPv4 vs IPv6, new protocol vs legacy, UDP encapsulation

  • Recursive Negotiation

– negotiate “crypto wrapper” and “contents” concurrently

  • Peer-to-Peer Negotiation

– symmetric peers must converge on a configuration

slide-28
SLIDE 28

Negotiation Transport Protocol

slide-29
SLIDE 29

How to Express Protocol Graphs?

Node #2 Node #1 Node #n ... Child 1 Node ID Child 2 Node ID Child m Node ID ... Negotiation Message Node Description Options Length Num Children Protocol-Specifc Data (variable) Negotiation Options (variable)

Negotiation Message Structure:

slide-30
SLIDE 30

How to Convey Protocol Graphs?

Negotiation messages might be big:

– Many layers × many alternatives for each to describe – Embedded protocol-specific data: crypto keys, etc.

Individual graph nodes may be large or small

– Segment large nodes, aggregate small ones into packets

Receiver probably wants only specific nodes

– Efficiently ignore/drop anything it doesn't understand

⇒ Specialized Negotiation Transport Protocol

slide-31
SLIDE 31

Chunk #2

Negotiation Transport: Packet Structure

Fixed Header Chunk #n ... Negotiation Transport Packet Chunk #1

Fixed header + multiple chunks [SCTP] each describing different graph node

slide-32
SLIDE 32

Negotiation Transport

Negotiation Protocol Magic Cookie Transmit Seq Negotiation Transaction ID Ack Seq Transport Header AckCt Step Number – Msg T ype

Negotiation packet sequencing permits individual packet ack/retransmit [SST]

slide-33
SLIDE 33

Negotiation Transport

Node ID Protocol ID Chunk Length Chunk Payload (variable) Transport Chunk –

Each chunk describes [part of] a graph node

  • Receiver can ack & discard all chunks

for unknown protocols without storing any

slide-34
SLIDE 34

Not needed

Let negotiated protocol worry about:

  • Connection state machines
  • Application-friendly semantics (e.g., streams)
  • Flow control
  • Congestion control (beyond slow-start)
  • ...
slide-35
SLIDE 35

Discussion, Conclusion

slide-36
SLIDE 36

What Doesn't (Really) Work

  • Encoding protocol stacks in names

– Non-transparent to user; compatibility hell

  • Try alternatives serially & fall back

– Delay/timeout hell

  • Probe alternatives in parallel

– Redundant protocol instances; combinatorial hell

  • Encode alternatives in DNS responses

– Not end-to-end robust; administrative hell

slide-37
SLIDE 37

What Might Work

Explicit In-Band Negotiation:

  • Get user & third parties out of the loop
  • Describe alternatives in compact protocol graphs
  • Handshake deep layer cakes concurrently
  • Receiver stores only what he understands & wants

“Tng: Transport Next Generation” project http://bford.info/tng/

Support: NSF FIND grants CNS-0916678 and CNS-0916413