1 IETF 64th meeting, Vancouver, Canada Context Transfer Using GIST Xiaoming Fu John Loughney

2 IETF 64th meeting, Vancouver, Canada Acknowledgments Thank Henning Peters (U. Goettingen) for his contribution and implementation Thank Kwok-Ho Chan (Nortel) for his helpful comments Thank Rajeev Koodli for his helpful comments

3 IETF 64th meeting, Vancouver, Canada Overview Motivation Context transfer using GIST Implementation status Open issues Next steps

4 IETF 64th meeting, Vancouver, Canada Problem: Context transfer pAR nAR CN MN Context Transfer: proactive v.s. preactive, network-controlled v.s. mobile-initiated MN-AR communication

5 IETF 64th meeting, Vancouver, Canada Problem RFC 4067 relies on a pre-established IPsec SA between oAR and nAR Practical implication: only used in intra-domain scenarios Not realistic in inter-domain cases RFC4067 specifies using SCTP for pAR  nAR communication (context transfer) Each context transfer has to establish a new SCTP association: performance limitation

6 IETF 64th meeting, Vancouver, Canada Proposal background NSIS base protocol suite is in final standardization effort GIST: the universal NSIS building block GIST creates and maintains soft state between two neighboring GIST nodes and provides a generic transport service for general signaling purposes This can be also used for other purposes, e.g., delivery of context data CXTP over GIST: using NSIS‘s GIST protocol to transport CXTP mesgs between ARs

7 IETF 64th meeting, Vancouver, Canada Context Transfer over GIST: Goals Not: to design a new, full-fledged context transfer protocol But: to provide a “better” transport for CXTP by reusing GIST CXTP basic semantic still exists Secure, reliable transport Reuse of existing GIST transport connections (soft state) Flexible transport mechanism: TCP/SCTP/UDP Automatic discovery of access routers Provisioning of secure channels Can be extended for other scenarios (more flexible network-controlled handovers, etc)

8 IETF 64th meeting, Vancouver, Canada Design overview ● Using CXTP semantics mapped to an NSIS end-to-end signaling application: ● This draft specifies a new “CXTP” NSLP running on top of GIST ● Only pAR/nAR communication using CXTP NSLP ● Keep lightweight communication between MN  pAR and MN  nAR ● More protocol flexibility using generic signaling ● Q: [KHC: what other benefit adding the NSIS layer will bring to CXTP? ] ● A: discovery of nAR is possible, details to be specified in next version ● Q: [RK: how does context information can be accessed by CXTP/GIST instance? One being in kernel space (data/forwarding plane) and the other being in user space?] ● A: Like interaction between any control plane and data plane, vertical control plane (CXTP/GIST) and horizon data plane (MN-AR-CN) forwarding needs certain resource management which requires read/write function between them. ● This can be implementation specific and a same issue as the interaction between RSVP/NSIS signaling and traffic control.

9 IETF 64th meeting, Vancouver, Canada Further issues raised by [KHC] Q: In addition to intra-domain case, is inter-domain considered? A: yes, this is one of the features the ID intends to enhance CXTP. By the use of secure MAs between ARs, inter-domain handover is possible. Q: What benefits NSIS will bring over the case where a IPsec tunnel exists between ARs? A: e.g., Soft state in GIST allows more efficient usage of resource access routers Q: GIST/NSIS is a signaling protocol, how it is used as transport protocol, right? It maybe the case that small data is piggybacked into signaling messages, but this is not true for GIST use here. Does this violate the nature of NSIS? A: well, GIST is designed as a signaling transport protocol, but can be also used for other purposes. The value for transport here is the discovery capability, embedded security, soft state management. Recall the evolution of SCTP use over the time.

10 IETF 64th meeting, Vancouver, Canada Example: MN-controlled context transfer

11 IETF 64th meeting, Vancouver, Canada Implementation status ● We developed a very basic first prototype implementation of CXTP NSLP, freely available under GPL ● Current status: Covering only most essential features Only pAR/nAR communication ● Experiences: ● Reusing GIST protocol stack greatly speeds up developing transport protocol transparent protocols: basic CXTP/GIST impl. as NSLP was done within 1 week. ● URL:

12 IETF 64th meeting, Vancouver, Canada Open Issues How to exactly discover the new access router Basically, generic, secure and reliable transport is not a problem, there is an open issue: how to trigger AR discovery in inter-domain movements Which context: QoS; authentication data; more to be defined by other community (3GPP etc)? ● Optimization: If MN also runs NSIS, may use NSIS to trigger context transfer

13 IETF 64th meeting, Vancouver, Canada Summary CXTP using GIST A way to remove the assumption of pre-established IPsec SA between ARs by discoverying nAR and Maintaining secure message associations between pAR-nAR A way to more efficiently context transfer Reuse existing MAs, no SCTP setup latency per-transfer. A way allows CT triggered from any sources A way allows more seamlessly work with QoS and middelboxes Is this work useful? Comments, suggestions appreciated!

14 IETF 64th meeting, Vancouver, Canada Backup: NSIS GIST protocol overview ● The lower layer of the 2- layer NSIS stack ● GIST provides signaling applications (NSLPs) with various benefits: Enabling communication across middleboxes Route change detection Built-in NAT & firewall awareness Interworking with QoS signaling