A Middlebox-Cooperative TCP for a non End-to-End Internet Ryan - - PowerPoint PPT Presentation

▶
a middlebox cooperative tcp for a non end to end internet
SMART_READER_LITE
LIVE PREVIEW

A Middlebox-Cooperative TCP for a non End-to-End Internet Ryan - - PowerPoint PPT Presentation

Jun 29, 2023 166 likes •558 views

A Middlebox-Cooperative TCP for a non End-to-End Internet Ryan Craven (NPS / SPAWAR) Robert Beverly (NPS) Mark Allman (ICSI) Support from: ACM SIGCOMM 19 Aug 2014 1 TCPs knowledge of end -to-end path conditions a priori ??? ???

slide-1
SLIDE 1

A Middlebox-Cooperative TCP for a non End-to-End Internet

Ryan Craven (NPS / SPAWAR) Robert Beverly (NPS) Mark Allman (ICSI)

ACM SIGCOMM 19 Aug 2014

1

Support from:

slide-2
SLIDE 2

TCP’s knowledge of end-to-end path conditions a priori

  • ???
  • ???
  • ???
  • ???
  • ???

2

slide-3
SLIDE 3

But TCP has questions…

  • How fast can I send?
  • How much should I send at once?
  • Did the other end get my data?
  • Was a piece lost?
  • Was it in the right order?
  • Was it error-free?

3

slide-4
SLIDE 4

…so it makes inferences

  • How fast can I send?
  • How much should I send at once?
  • Did the other end get my data?
  • Was a piece lost?
  • Was it in the right order?
  • Was it error-free?

4

Congestion Control

  • Sequence Numbers
  • Duplicate Acknowledgements
  • Selective Acknowledgements

Checksums

slide-5
SLIDE 5

One more…

  • How fast can I send?
  • How much should I send at once?
  • Did Bob get my data?
  • Was a piece lost?
  • Was it in the right order?
  • Was it error-free?
  • Am I being misinterpreted?

5

slide-6
SLIDE 6

6

Bob Alice

slide-7
SLIDE 7

7

Bob Alice

???

slide-8
SLIDE 8

8

Bob Alice

“Across all network sizes, the number of middleboxes is on par with the number of routers in a network”

Sherry et al., SIGCOMM ‘11 (from a survey of NANOG admins)

slide-9
SLIDE 9

9

Bob Alice

“A majority of administrators stated misconfiguration as the most common cause

  • f [middlebox] failure”

Sherry et al., SIGCOMM ‘11 (from a survey of NANOG admins)

slide-10
SLIDE 10

Example: ECN

10

1980 1980 2000 2000

slide-11
SLIDE 11

Example: ECN

  • Switch was copying a

value to the ToS byte1

11

1Bauer et al. “Measuring the State of ECN Readiness in

Servers, Clients, and Routers.” In Proc. of IMC 2011.

0b11 == congestion experienced

slide-12
SLIDE 12

12

Alice Bob

TCP/IP Headers Source: Alice Dest: Bob … … Window Size 1024

  • Win. Scale

7 Data TCP/IP Headers Source: Alice Dest: Bob … … Window Size 1024

  • Win. Scale

7 Data

  • Win. scale
slide-13
SLIDE 13

13

Alice Bob

TCP/IP Headers Source: Alice Dest: Bob … … Window Size 1024

  • Win. Scale

7 Data TCP/IP Headers Source: Alice Dest: Bob … … Window Size 1024

  • Win. Scale

Data

  • Win. scale
  • 1corbet. “TCP window scaling and broken routers.”

http://lwn.net/Articles/92727/

Misconfigured Middlebox1

slide-14
SLIDE 14

14

Alice Bob

TCP/IP Headers Source: Alice Dest: Bob … … Window Size 1024

  • Win. Scale

7 Data TCP/IP Headers Source: Alice Dest: Bob … … Window Size 1024

  • Win. Scale

Data

  • Win. scale
  • corbet. “TCP window scaling and broken routers.”

http://lwn.net/Articles/92727/

Misconfigured Middlebox

Alice thinks her window size is 12 128k Bob thinks her window size is 1k 1k

slide-15
SLIDE 15

Other Examples

  • TCP SACK
  • Artificial TCP flow control
  • Path MTU discovery
  • ICMP blocking
  • ICMP misquoting
  • TCP MSS alterations
  • IP and TCP options stripped
  • Extra problematic:
  • Asymmetric (stripped on SYN-ACK but not SYN)
  • Allowed in handshake, then stripped

15

slide-16
SLIDE 16

Middlebox Misconfiguration

  • These are real problems
  • Will continue to occur
  • The network is not getting any less intelligent
  • Are critical and timely right now
  • Multipath TCP
  • TCP Fast Open
  • Gentle Aggression TCP (proactive/reactive/corrective)
  • tcpcrypt
  • ECN (still)

16

slide-17
SLIDE 17

Wouldn’t it be great if we had an easy way to detect these?

17

  • Performance
  • Extensibility

TCP

  • End-to-end

debugging

Operators Could benefit

  • New network

measurement tools

Researchers

slide-18
SLIDE 18

Challenges

  • Available and reliable communications channel
  • Out-of-band ICMP?
  • New IP or TCP option?
  • Redefine a field?
  • Capacity
  • Incrementally deployable
  • Middlebox-cooperative
  • Inform both endpoints

18

slide-19
SLIDE 19

HICCUPS

  • HICCUPS seeks to automate the question:

“Did my packet arrive at the destination with the same headers as sent?”

19

HICCUPS is a lightweight TCP extension that exposes in-flight packet header modification to endpoints

slide-20
SLIDE 20

HICCUPS Methodology

  • Overloads three header fields in TCP 3WHS…
  • …with a function of the packet headers

20

ISN ISN, HICCUPS IPID Rwin IPID, HICCUPS Rwin, HICCUPS 0x47a0b136

slide-21
SLIDE 21

HICCUPS Methodology

  • Spread over 3 fields in case one is changed
  • Lightweight hash function
  • Only have three sets of 12-bits
  • Assume no shared secret available
  • Preimage and hash sent together
  • Primary goal is to reduce collisions
  • Add randomness (salt) to ISN

21

slide-22
SLIDE 22

HICCUPS Methodology

  • Creates an end-to-end tamper-evident seal over the

packet headers

  • Different than a checksum
  • If mods occur, we still accept the packet

22

slide-23
SLIDE 23

Using HICCUPS

  • Once a host’s TCP stack is HICCUPS-enabled,

HICCUPS can be used without endpoint coordination

  • Our long-term vision: all TCP stacks include HICCUPS

23

TCP HICCUPS Infers e2e packet header modification state TCP Congestion Control Infers e2e congestion state

slide-24
SLIDE 24

Implementation

  • Patch written for Linux kernel v3.9.4 TCP stack
  • Requires no action by applications
  • However, we do provide optional features:
  • Get HICCUPS status
  • Manually specify fields to check
  • Engage AppSalt mode (see paper)
  • Set of cross-platform userspace tools

24

slide-25
SLIDE 25

Performance

  • Analyzed HICCUPS kernel overhead with ftrace
  • Increases mean processing time by about 10μs
  • About 8.5% of the total SYN/ACK processing time
  • If load gets too high, automatically mitigates with

SYN cookies

25

slide-26
SLIDE 26

Validation

  • Controlled environment
  • VMs
  • Range of tests

26

Simulates a middlebox that

  • verwrites different fields

in forwarded packets (scapy)

Host A HICCUPS-enabled Host B HICCUPS-enabled 50,000 trials each run

slide-27
SLIDE 27

Measurements

  • Over 26k directed port/path pairs across 197 ASes and

48 countries

  • Different ports: 22, 80, 443, and 34343
  • Range of parameters

27

slide-28
SLIDE 28
  • Meas. Summary
  • Almost half of the nodes saw at least one in-path

header modification

  • More than we expected to find
  • Saw asymmetric cases

28

slide-29
SLIDE 29

Mods Detected

29

slide-30
SLIDE 30

What can go wrong?

30

Potential SACK disruption

slide-31
SLIDE 31

What can go wrong?

31

Potential ToS byte semantics

slide-32
SLIDE 32

ECN IP bits

32

slide-33
SLIDE 33

ECN IP bits

33

slide-34
SLIDE 34

What can go wrong?

34

Options stripped

slide-35
SLIDE 35

What can go wrong?

35

New behavior

slide-36
SLIDE 36

Window Scaling

  • Israeli PlanetLab node

planetlab2.mta.ac.il

  • Window scaling
  • ption added
  • Only when going to

ports 80 or 443

36

SYN SYN-ACK

A B

X Add WINSCL Remove WINSCL X

M

slide-37
SLIDE 37

Window Scaling

  • Israeli PlanetLab node

planetlab2.mta.ac.il

  • Window scaling
  • ption added
  • Only when going to

ports 80 or 443 Result: bulk transfer is flow-controlled, doubles when WINSCL ignored

37

SYN SYN-ACK

A B

X Add WINSCL Remove WINSCL X

M

slide-38
SLIDE 38

Conclusions

  • HICCUPS can help TCP infer whether it is being

misinterpreted

  • Integrates nicely with TCP, incrementally deployable
  • End-to-end
  • Middlebox-cooperative
  • Demonstrated ease of deployment through mass

Internet measurements

38

http://tcphiccups.org