Made with OpenOffice.org 1 TCP Multi-Home Options Arifumi Matsumoto Graduate School of Informatics, Kyoto University, Japan 11/11 IETF 58th - draft-arifumi-tcp-mh-00.txt -

Made with OpenOffice.org 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. 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

Made with OpenOffice.org 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.

Made with OpenOffice.org 4 Protocol Behavior Overview EST ADD NodeA NodeB

Made with OpenOffice.org 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.

Made with OpenOffice.org 6 Considerations -Path Switch- Path switches when Several times(should be 3) of RTOs(cwnd->0) occurs. This typically takes about 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

Made with OpenOffice.org 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. B A T 1) Add(T) 2) Ack 3) Data NodeA NodeB(adr1)NodeB(adr2) Add(adr2) Confirm Con-Ack Add-Ack Add(adr2) RST

Made with OpenOffice.org 8 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 A B 1) Add 2) Ack 1) Add 2) Ack MIM A B MIM 2 (and it's possible to use TCP ISN as a shared secret but not perfect)

Made with OpenOffice.org 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 ?

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

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