Bound End-to-End Tunnel (BEET) Presentation at 58th IETF, - - PowerPoint PPT Presentation

▶
bound end to end tunnel beet
SMART_READER_LITE
LIVE PREVIEW

Bound End-to-End Tunnel (BEET) Presentation at 58th IETF, - - PowerPoint PPT Presentation

Sep 13, 2022 162 likes •252 views

Bound End-to-End Tunnel (BEET) Presentation at 58th IETF, Minneapolis Pekka Nikander Ericsson Research Nomadiclab draft-nikander-esp-beet-mode-00.txt Presentation outline Background BEET in a nutshell Motivation Answers to

slide-1
SLIDE 1

Presentation at 58th IETF, Minneapolis Pekka Nikander Ericsson Research Nomadiclab draft-nikander-esp-beet-mode-00.txt

Bound End-to-End Tunnel (BEET)

slide-2
SLIDE 2

2

  • Background
  • BEET in a nutshell
  • Motivation
  • Answers to common objections
  • Summary

Presentation outline

slide-3
SLIDE 3

3

  • mobike proposing mobility extensions to IKEv2
  • nsrg, multi6, and hip discussing id/locator split
  • Separate end-point identifier and locator

roles of IP addresses

  • Avoid transport protocol reconnection when

underlying IP addresses change

Background

slide-4
SLIDE 4

4

  • Transport header but tunnel semantics
  • A fixed pair of inner addresses
  • Address ranges not allowed

= Transport mode + Bellovin’s hostNAT

BEET in a nutshell

BEET SA

srci dsti payload srco dsto payload esp

slide-5
SLIDE 5

5

  • “This is useless, just use tunnel mode!”
  • Counter-argument: sometimes bytes matter

Motivation 1: save bytes

Headers Uncompressed ROCH Baseline: IPv4 + TCP 20 + 20 2 IPv4 + ESP + IPv4 + TCP 80 58 IPv4 + ESP + TCP 60 38 IPv6 + ESP + IPv6 + TCP 120 78 IPv6 + ESP + TCP 80 38 51% saving

slide-6
SLIDE 6

6

  • Inner addresses work as end-point identifiers
  • Visible to upper layer protocols
  • No change with mobility / multi-addressing
  • Outer addresses work as locators
  • Bound to the topological location
  • Change with mobility / multi-addressing
  • Difference to tunnel mode is architectural
  • Inner addresses internal, not visible on wire

Motivation 2: Id/loc split

slide-7
SLIDE 7

7

  • “Adds complexity”
  • Does 98 lines of code really matter?
  • “Hard to add to existing implementations”
  • Make optional, use tunnel mode if not there
  • “Optional features are bad for portability”
  • Easy to check whether supported (PF_KEY)
  • “Not needed”
  • NAT traversal, HIP

, multi6, ...

Common objections (and answers to them)

slide-8
SLIDE 8

8

  • New mode to ESP
  • Tunnel semantics, inner and outer addresses
  • Fixed inner addresses, no address ranges
  • Transport mode header structure
  • PF_KEY support via SADB_IDENTTYPE
  • Up to 51% header savings when ROCH is used
  • Facilitates id/locator separation
  • Minimal added complexity: 98 lines of code

Summary