Traditional IPv4 multihoming. IPv6 host-based multihoming. Drawbacks of BGP-based multihoming. How long will IPv4 last?

Transcription

1 host-based multihoming raditional IPv4 multihoming /8 Provider2 AS /8 Olivier Bonaventure Sébastien Barré IP Networking Lab Department of Computing Science and Engineering Université catholique de Louvain (UCL) Place Sainte-Barbe, 2, B-1348, Louvain-la-Neuve (Belgium) :123::ABC 1 2 Stub AS /16 BGP ensures stub!s prefix is reachable even after link failures :456::EDC Drawbacks of BGP-based multihoming Size of the BGP routing tables Difficult to control incoming traffic How long will IPv4 last? Internet bubble CID works well Growth is back again! Growth is back pre-cid fast growth Networks/ Source : O. Bonaventure, 2007 Networks/ Source : O. Bonaventure, 2007

2 Size of BGP routing tables Host-based multihoming Provider uses Provider Independent addresses Stubs receive one Provider Aggregatable address block from each of its providers 1 2 Stub - no AS# :123 Stub - no AS# :456 Networks/ Still close to the number of ASes that have deployed :456::EDC :123::ABC :4565::ABC Source : :1234::DEF O. Bonaventure, 2007 :4564::DEF Evaluation of host-base multihoming Advantages educes growth of BGP routing tables Only transit ISPs need Provider Independent addresses Stub ASes use PA addresses allocated by their provider hosts can now use multiple paths to reach each destination Hosts can potentially find better paths than the BGP paths Incoming traffic engineering is possible with any BGP advertisement Performance benefits of host-based multihoming Measurement based study here is now one implementation of hostbased multihoming, it is not yet widely deployed IPE est raffic Measurement boxes Located inside large ISP networks in different countries Perform frequent delay measurements between themselves Issue How to deal with failures of one of the providers BGP does not anymore advertise the reachability of the stub!s prefixes

3 Performance benefits of host-based multihoming (2) Measurement study Clustering of M boxes Consider each city containing more than one M box as one multihomed stub AS attached to different ISPs Use the one-way delay measurements gathered by the M boxes in full-mesh to determine path quality Performance benefits of host-based multihoming Belgacom, Brussels Spacenet, Munich Belnet, Brussels D, Munich his is a new flow that will break transport layer he basics of hostbased multihoming 2001:CCCC:ABC 1 2 Provider3 - AS3 2001:CCCC flow Source : :456::EDC Dest 2001:CCCC::ABC :456::EDC flow Source : :456::EDC Dest 2001:CCCC::ABC Constraints for host-based multihoming When a provider becomes unreachable, all belonging to this provider are unreachable, but BGP does not advertise another path to reach these addresses Hosts must be able to divert open flows Ingress/egress filtering forces hosts to use the assigned by the provider via which the packet will be sent Source host must change source and/or destination addresses when diverting flows ransport layer is not prepared for changes of addresses for an open flow Hosts must hide the change of addresses from the transport layer

4 he basics of hostbased multihoming he shim6 sublayer Packet must appear to transport as Source : Dest :456::EDC 2001:CCCC:ABC Provider3 - AS3 2001:CCCC Applications ransport layer layer Upper-layer identifier (ULID) : An IP address which has been selected for communication with a peer to be used by the upper layer protocol. 128 bits. his is used for pseudo-header checksum computation and connection identification in the Upper Layer Protocol. AH ESP Frag eas SHIM6 Dest opt. 1 2 flow Source : Dest 2001:CCCC::ABC ransport source : :456::EDC :456::EDC flow Source : :456::EDC Dest 2001:CCCC::ABC Data Link Layer IP routing sublayer Locator : An IP layer topological name for an interface or a set of interfaces (128 bits). he locators are carried in the IP address fields as the packets traverse the network. he shim6 sublayer Shim6 flow establishment Host A S: ULID(A)=L1(A) D: ULID(B)=L1(B) ransport layer S: ULID(A)=L1(A) D: ULID(B)=L1(B) Host B ransport layer Shim6 initiator Init context:1234 Init Nonce: 6789 I1 Shim6 responder No state is created. Stateless 1 reply SHIM6 S: L2(A) D: L2(B) contextid IP routing sublayer On host A, shim6 maintains a context for the flow ULID(A)-ULID(B) with information about the address translation SHIM6 S: L2(A) D: L2(B) contextid IP routing sublayer Init context:1234 esp. nonce : 0246 Hash : ABCD 1 I2 2 esp. nonce : 0246 Init nonce:6789 Hash(I1 1 params): ABCD esp context : 8765

5 How to secure shim6? Usage of the shim6 context wo possible approaches Use CGA addresses as identifiers and sign shim6 control messages Each host generates one public/private key pair address is Prefix:Hash(public key) Signature and CGA structures included in I2 and 2 messages to sign locator lists Use hash-based addresses (HBA) A shim6 host having prefixes A, B, C and D should use the following addresses A Hash[andom A List(A,B,C,D) ] B Hash[andom B List(A,B,C,D) ] C Hash[andom C List(A,B,C,D) ] D Hash[andom D List(A,B,C,D) ] Shim6 initiator Src: A::1 Dest:2001:BBBB::1 Init context:1234 esp. nonce : 0246 Hash : ABCD Loc:2001::CCCC::1 Src: A::1 Dest:2001:BBBB::1 No context tag Src: A::1 Dest:2001:DDDD::1 Cag : 8765 I2 2 Shim6 responder Src: 2001:BBBB::1 Dest: A::1 esp context : 8765 Loc:2001:DDDD::1, ::1 Src: 2001:BBBB::1 Dest: 2001::AAAA::1 No context tag Src: 2001:DDDD::1 Upon reception of I2 or 2, shim6 hosts can check that Dest: 2001::AAAA::1 the addresses are linked together by the hash Cag: 1234 What happens when a failure has been detected? How to recover connectivity? Need to find alternate working source or destination address Host A : A Src: A Dest: B1 Bidirectional failure recovery Host B : B1, B2 Src: :678::ABC Dest: :456::EDC 2001:CCCC::ABC :678::ABC Provider3 - AS3 2001:CCCC A<->B1 fails Src: B1 Dest: A Nonce : p 1 2 Src: Dest: 2001:CCCC::ABC :456::EDC A learns that B2 is ok Src: A Dest:B2 Nonce : r State:InboundOk ecvd probe : q Src: A Dest: B2 Dest: A Nonce : q Dest: A Nonce : s State : Operational ecvd probe : r

6 Unidirectional failure recovery Conclusion Host A : A1,A2 Src: A1 Dest: B1 A thinks that B1 is ok Src: A1 Dest:B1 Nonce : q State:InboundOk ecvd probe : p Src: A2 Dest:B2 Nonce : s State:InboundOk ecvd probe : p,r A1->B1 fails Host B : B1, B2 Src: B1 Dest: A1 Nonce : p Dest: A2 Nonce : r Dest: A2 Nonce : t State : Operational ecvd probe : s host-based multihoming Hosts pay the cost of supporting multihoming First implementation available on Linux, see Sébastien Barré!s demo Initially designed for endhosts attached to ADSL and CAV for example equirements from enterprise and ISP networks were not really taken into account Network operators have potentially better knobs to control their incoming and outgoing traffic equires a cooperation between the hosts and the network See Benoit Donnet!s presentation