Design and Implementation of

1
Design and Implementation of TCP Multihome Option
FUJIKAWA Kenji (fujikawa_at_i.kyoto-u.ac.jp) MATSUMOT
O Arifumi (arifumi_at_net.ist.i.kyoto-u.ac.jp OKABE
Yasuo (okabe_at_i.kyoto-u.ac.jp) Kyoto
University 2003/02/06
2
Backgrounds

• Internet connection using multiple lines
  (multihoming) is becoming common
• Reliable connection is required for a personal
  use with multiple lines
• Seamless connection is required without loss of
  connection when moving
• IPv6 multihoming is also required, as IPv6 is
  promoted
• The multihome method based on the current BGP has
  problems
• Routing table size becomes huge
• Cannot support site-level or host-level
  multihoming
• We propose End-to-end Multihoming

3
End-to-End Multihoming

• End nodes change the path in order to avoid
  failure by themselves

2002330/64
133.69.66.2
L4 or upper layer support is needed for
detecting commucation failure
3ffe11/64
20011122/64
43.245.1.2
Highly reliable communication without depending
on routing (solving the current problems)
4
Barriers to E2E Multihoming

• Limitation from the current TCP/IP
• Only one pair of addresses can be used for one
  connection
• Addresses cannot be changed when the connection
  is continuing
• Ingress Filtering in ISP
• An apropriate src address is required for each
  next-hop
• Otherwise, the packet will be discarded by the
  filtering
• Enormous assets (applications, nodes)
• Relpacing all the nodes for the purpose of
  multihoming is unrealistic
• Rewriting all the applications is also
  unrealistic
• Just modify TCP on end nodes

5
Proposal of TCP Multihome Method

• Support at Transport layer (L4)
• Define a protocol and TCP multihome options
• Functions
• Address info. exchange
• Detecting comm. failure
• Changing a path
• Asymmetric path support
• Advantage
• Current applications can be applied without
  rewriting
• Independent of L3 protocols
• Can use multiple L3 protocols simultaneously
• Co-exists all the L3 mobility protocols

Application
L5
TCP-MH
UDP
L4
MIP
MIP6
LIN6
IPv4
IPv6
L3
6
Related Works

• L4 Model
• SCTP(Add-IP extension)
• No interoperability with TCP.
• Troel's TCP
• Uses IPv6's extension header
• IPv6 dependent
• TCP Migrate Option
• ECDH key agreement.
• Used up TCP option space
• vulnerable to syn-flood attack and other DoS
  attacks.

• L3.5 Model
• MAST
• Idea of Layer3.5
• No interaction with layer 4
• No clear specification
• NOID/SHIM
• No interaction with layer 4
• Router support
• HIP
• No interaction with layer 4
• Yet to support Multi-home
• LIN6
• No Multi-Home support

7
Basic Protocol Design

• Simple and Minimum change to the existing TCP
• Defines several new TCP Options
• Not affect any other functions of TCP(flow
  control, congestion avoidance)
• Backward interoperability and fairness
• Rapid recovery from transmission failure
• After some RTOs, path(src-dst address pair)
  changes.
• Traverse ingress filter by trying all the source
  addresses.
• Protection for Redirection Attack, Session Hijack
  and Syn-Flood Attack.

8
Protocol Behavior Overview
NodeA
NodeB
EST
EST
ADD
ADD
ADD
ADD
9
Packet Format

• TCP Option field size is up to 40 bytes!
• MH-Permitted Option
• Negotiates multi-home capability.
• Address Configuration Options
• MH-Add/Delete Option
• MH-Serial is incremented by one if its ack
  returns.
• Each hosts can have one outstanding MH-Serial.
• Address Configuration Ack. Options
• MH-Add/Non-Ack Option
• MH-Serial is copied from MH-Add/Delete Option.

10
Considerations -Path Switch-

• Path switches when
• Several times(should be 3) of RTOs(cwnd-gt0)
  occurs. This typically takes about 10-20 sec.
• ICMP Error is received. (temporary network
  failure)
• Path is discarded when
• RST is the first received packet from that path.
  (the packet is probably from irrelevant host.
  e.g. private address)
• Path's address is deleted by either of nodes.
• When a path changes, window size is almost always
  set to 1MSS because of RTOs.

Path Flapping Avoidance
11
Considerations -Security(1/2)-

• Redirection Attack
• Redirects traffic to third party for DoS attack.
• Targeted host can RST connection,
• so this seems not so serious.
• By introducing Return-Routablity
• check, this is easily prevented but not yet
  included.

T
3) Data
B
2) Ack
1) Add(T)
A
NodeB(adr1)
NodeB(adr2)
NodeA
Add(adr2)
Add(adr2)
Confirm
Con-Ack
Add-Ack
RST
12
Considerations -Security(2/2)-

• Session Hijack
• protected by strict MH-Serial number management.
• Unexpected Serial number means being attacked and
  session itself should soon be canceled.
• This mechanism, however, doesn't have any
  protection against Man-In-the-Middle attack. This
  is also true for the existing TCP.
• The difference is that MITM host can fetch a
  session to anywhere else. (This degrades TCP
  security ?)

MIM
2) Ack
1) Add
1) Add
B
2) Ack
A
(and it's possible to use TCP ISN as a shared
secret but not perfect)
13
TCP-MH Status

• Basic Specification and its implementation
  Completed
• On NetBSD1.6.1
• Future Works
• Return-Routability Check
• NAT/NAPT Traversal
• Related Works
• MIP/MIP6 multiple home-address support
• Interaction with Routing Table (Source Address
  Selection)

14
Application to usual use

• A TCP-MH-support host runs SOCKS/HTTP Proxy
  (SOCKS box)
• E2E multihoming is available beyond the SOCKS box

E2E-MH
E2E-MHsupport
TCP
E2E-MH support SOCKS/HTTP Proxy
Hosts without TCP-MH functions also receive
benefits of TCP
E2E-MH unsupported
15
Concluding Remarks

• Propose TCP Multihoming protocol and TCP options
  for it
• Implemented on NetBSD 1.6.1
• TCP-MH support SOCKS box is available for usual
  use
• Future Work,
• Evaluate on real environments
• Propose TCP-MH in IETF.