1 © 2005 nokia mobike-transport.ppt/2005-11-09 mobike transport mode usage and issues mohan...

1 © 2005 Nokia mobike-transport.ppt/2005-11-09

MOBIKE Transport mode usage and issues

Mohan Parthasarathy

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


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


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 ?


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 ?


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 !


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


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


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 ?


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 ?

1 © 2005 nokia mobike-transport.ppt/2005-11-09 mobike transport mode usage and issues mohan...

Documents