1 / 11

TCP Multi-Home Options

This draft proposes TCP-MH-Options, a simple solution for multi-address and host-centric model in TCP. It defines new TCP options for multi-home capability negotiation and address configuration. It ensures backward interoperability, fairness, and rapid recovery from transmission failure. The protocol also provides protection against redirection attack, session hijack, and syn-flood attack.

maribelj
Download Presentation

TCP Multi-Home Options

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 11/11 IETF 58th TCP Multi-Home Options - draft-arifumi-tcp-mh-00.txt - Arifumi Matsumoto Graduate School of Informatics, Kyoto University, Japan arifumi@kuis.kyoto-u.ac.jp

  2. Multi6a Design Team (DT2) • In DT2, as a short term solution, • Multi-address & host-centric model is reasonable. • Multi-homed site does “Source Address Based Routing” to provide as many pathes as possible to upper layer. • And IMO, improved TCP is necessary and is a simple solution. • Network failure can only be detected by transport or upper layers before session time-outs. • Existing TCP can't manipulate multi-addresses. • SCTP isn't TCP. (no interoperability) • So I designed and implemented TCP MH-Options

  3. 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.

  4. Protocol Behavior Overview NodeA NodeB EST EST ADD ADD ADD ADD

  5. 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.

  6. Considerations -Path Switch- • Path switches when • Several times(should be 3) of RTOs(cwnd->0) 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

  7. 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(adr2) NodeB(adr1) NodeA Add(adr2) Add(adr2) Confirm Con-Ack Add-Ack RST

  8. Considerations -Security(2/2)- MIM2 MIM B A • 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)

  9. Conclusions • I proposed Transport Layer based Multi-home solution. • This is not the consensus of Multi6a DT though. • There is a running implementation for NetBSD. • Future Work: • Return Routability and NAT/NAPT Traversal evaluation. • Comparison with L3.5 approaches. • TCP-MH is enough ?

  10. Basic Capabilities Survive any network outage 3.1.1 3.1.1 Redundancy Redundancy Per TCP session 3.1.2 3.1.2 Load Sharing Load Sharing maybe 3.1.3 3.1.3 Performance Performance possible 3.1.4 3.1.4 Policy Policy Quite simple 3.1.5 3.1.5 Simplicity Simplicity 3.1.6 3.1.6 Transport Transport That's what this is for. Survivability Survivability No impact 3.1.7 3.1.7 Impact on DNS Impact on DNS No impact 3.1.8 3.1.8 Packet Filtering Packet Filtering

  11. Additional capabilities No problem 3.2.1 3.2.1 Scalability Scalability 3.2.2 3.2.2 Impact on Routers Impact on Routers SABR is desired Interoperable with legacy nodes 3.2.3 3.2.3 Impact on Hosts Impact on Hosts 3.2.4 3.2.4 Host Host - - Routing Routing Desired but not required interaction interaction 3.2.5 3.2.5 Operations & Operations & Possible Management Management 3.2.6 3.2.6 Cooperation Cooperation Not required between Transit Providers between Transit Providers 3.2.7 3.2.7 Multiple Solutions? Multiple Solutions? Can co-exist with L3 solutions MITM can hijack 4 4 Security Considerations Security Considerations

More Related