1. 1 © 2005 Nokia mobike-transport.ppt/2005-11-09 MOBIKE Transport mode usage and issues Mohan Parthasarathy

2. 2 © 2005 Nokia V1-Filename.ppt / yyyy-mm-dd / Initials MOBIKE transport mode use cases summary SCTP Mobile IPv6 IP-IP tunnel + transport mode SA (RFC 3884 interaction) TCP/UDP + transport mode SA

3. 3 © 2005 Nokia V1-Filename.ppt / yyyy-mm-dd / Initials SCTP – Stream Control Transmission Protocol (RFC 2960) SCTP (RFC 2960) supports multi-homing Exchange multiple addresses during SCTP association setup After successful “ASSOCIATE”, SCTP picks one of the destination address as the primary path It also returns a transport address list that can be used by ULP to override primary path Destination address (and source address) of a packet can change due to various reasons Applications can change the primary path at any time Retransmission SHOULD use a different destination address from last time SACKs to duplicate data may be transmitted using different address from the source in the received packet HEARTBEATs (used on idle associations) can be used to mark an address inactive causing new address to be selected Packets can change addresses can from either side of the association

4. 4 © 2005 Nokia V1-Filename.ppt / yyyy-mm-dd / Initials SCTP use case (contd..) SCTP Dynamic Address Configuration (draft-ietf-tsvwg-addip-sctp-12.txt) Reconfigure IP addresses on an existing association Supports ADD/DELETE/Set primary path primitives Requires SCTP-AUTH for these primitives SCTP-AUTH draft – a non WG draft expired (draft-tuexen-sctp-auth-chunk-03) SCTP usage in IKEv1 RFC 3554 describes SCTP usage with IPsec for IKEv1 Not a commonly used feature SCTP usage in IKEv2 TSi/TSr can be used to exchange additional addresses TSi/TSr not sufficient to support dynamic address configuration of SCTP Not yet implemented by anyone ?

5. 5 © 2005 Nokia V1-Filename.ppt / yyyy-mm-dd / Initials SCTP and MOBIKE usage MOBIKE allows only initiator to change the addresses of the SA MOBIKE uses only one address pair at any time for both sending and receiving sides Issues Similar problem exists in shim6 WG (shim6 – SCTP interaction) Either side of the SCTP association can change the path anytime conflicting with MOBIKE ? SCTP HEARTBEAT Vs IKEv2 PATH_TEST conflict ? SCTP chooses a path and IKEv2 overrides with a different path ?

6. 6 © 2005 Nokia V1-Filename.ppt / yyyy-mm-dd / Initials Mobile IPv6 Usage (RFC 3775/3776) Mobile Node and Home Agent use transport mode SA for protecting the Binding Updates and Binding Acknowledgements There are two addresses : Fixed Home Address and transient care-of address IKE uses care-of address while the IPsec SA itself is bound to the home address Use case 1 (Francis draft) Use MOBIKE to add the home address as alternate address (using ADDITIONAL_ADDRESS_IPv6 notification) Issues IPsec may try to use the home address if the CoA does not work ? RR may not work always ! Use case 2 MIPv6 has in-built functionality for updating the SAs when CoA changes CoA change (after the initial SA setup) is not authorized MOBIKE can provide this using the RR No additional changes needed in the MOBIKE spec for both use cases !

7. 7 © 2005 Nokia V1-Filename.ppt / yyyy-mm-dd / Initials Use of IPsec Transport mode for Dynamic Routing (RFC 3884) This use case was closed as Issue 7 IP-IP tunnel is used between the peers and the traffic protected using transport mode IPsec SA MOBIKE support should be similar to NAT-T support for IPsec protected IP- IP/L2TP tunnel NAT reboot can cause IP address change similar to MOBIKE Implementations may not implement this NAT-T feature today. Mobility support Update the IPsec SA with the new address from the UPDATE_SA message Questions Do we update the tunnel endpoints and traffic selectors ? If NO, reuse of original tunnel endpoint address by some other node will cause problems

8. 8 © 2005 Nokia V1-Filename.ppt / yyyy-mm-dd / Initials MOBIKE multi-homing support with RFC 3884 Multi-homing support Two possible models Model 1 Single IP-IP tunnel between the peers MOBIKE manages multiple addresses between the peers No issues ? Model 2 Multiple IP-IP tunnels between the peers and routing protocols running over the tunnels IPsec protects each of the tunnel traffic using transport mode SA MOBIKE manages multiple addresses between the peers Routing Protocols (depending on its reachability) decides the forwarding of packets over the tunnel MOBIKE protocol (depending on its reachability) decides what source and destination will be used by the packet Bad interaction similar to SCTP ? Routing switches to tunnel 1, MOBIKE switches to a different address pair Bad effects needs to be studied further

9. 9 © 2005 Nokia V1-Filename.ppt / yyyy-mm-dd / Initials MOBIKE support for TCP/UDP Similar to IP-IP tunnel + transport mode TCP connection setup or UDP packet to destination X triggers IPsec MOBIKE exchanges the “available” addresses Mobility support Update the IPsec SA with the new address Updating the TCP connection state will break applications Traffic selectors, TCP, UDP still based on the original address Issue Reuse of original address will cause issues (duplicate traffic selector!) Multi-homing support Similar to IP-IP tunnel + transport mode except that no interaction with routing ?

10. 10 © 2005 Nokia V1-Filename.ppt / yyyy-mm-dd / Initials Conclusion IPsec acts like a “shim” layer in the context of multi-homing SCTP Use of IPsec for SCTP does not seem to be common MOBIKE address selection interacts badly with SCTP address selection MIPv6 Nothing special needed in MOBIKE itself IP-IP tunnel + transport mode RFC 3884 use case may be more common Interaction with routing layer needs to be studied TCP + transport mode Does not seem to be an interesting case ?