NSIS and Mobility Layer Split & Framework Issues Robert Hancock NSIS Interim Meeting – Columbia University February 2003

Overview Basic Definitions New path problems Crossover detection problem Reservation ownership problem CT and CARD

Why Bother? Soft-state for all will remove old state and install new Imposes yet another criterion for timer setting Or, long periods of poor mid-call operation Alternative: explicit messaging How to prevent TEAR message deleting the entire path? How to avoid double reservation being rejected (spurious resource limitation)

Mobility != Re-Routing Local repair is a simpler problem Includes address-preserving micromobility as a special case Re-routing/local repair properties: End system addresses not changed Packet classifier update not needed No end to end signalling logically required Reservation theft is hard Depend on ‘weak security’ of routing network But – path characteristics may change…

Mobility Properties Mobility with ES address changes is harder For NSIS and other protocols NB: applies to MIP, HIP, SIP, … Different properties: E2E packet classifier update needed Other E2E signalling unavoidable (ignoring proxies…) Harder to prevent reservation theft And, path characteristics may change …

Path Characteristics Changing In each case: for unchanged path part, should avoid AAA/policy control Could be the major saving in mobility case Provided ownership can be shown For new part, different rules may apply Different cost/byte, firewall policies Implication: signalling application must be re-executed along changed part

Partial NSLP Execution (I) What we want to do is re-execute NSLP between crossover points How does this relate to original e2e NSLP execution? NB: Implications for NTLP – not everything takes place in e2e upper layer context How do interior points take charge Does it have to take place in the same ‘orientation’ as the original transaction? Examples????? What assumptions can be made?

Partial NSLP Execution (II) Pre-preparation to speed up partial execution Authorise upper bound on ‘resource’, not the actual amount immediately needed Requires different concept of ‘resource’ from e.g. IntServ Make reservations SE-like (with some constraints) rather than FF Cf. old pre-RSVP ‘dynamic filter’ style Cost of SE compared to FF reservations? Getting back to multicast complexity?

Crossover Detection Re-routing case: flow-tuple not changed, just input/output interfaces (peers) Any additional identifiers needed to correlate old and new paths? Mobility case: flow-tuple is changed Another identifier needed What else is it used for? What properties does it need? Needs to be e2e ‘unique enough’ (crossover point can be anywhere)

Reservation ID NB framework terminology used here… A: Is this ID used just to detect crossover? And then re-trigger partial NSLP NSLP must have some other reason to believe that progressing application with changed flow tuple is valid… B: Or, does simply presenting the ID prove ownership in itself? In other words, this is a security issue

Reservation ID Security Challenge #1: State the security properties required to use ID for (B) NB: could be a challenge without general authorisation framework for all NSLPs One issue: should be considered from both endpoints’ perspectives – may need two Ids (!) Challenge #2: Define an identifier mechanism with the properties defined in challenge #1. NB: not very surprisingly, challenge #2 gets done first

Reservation ID Mechanisms Three proposals so far: Some random combination of address etc ‘Random’ in perjorative sense No detectable security (or even uniqueness) properties Westphal/Chaskar proposal & variants Uses counters & asymmetric cryptography Very expensive. Other flaws? CASP Make it random and confidentiality protected

CT and CARD Background assumptions Framework has ancient text (5.3.5) NSIS protocols MUST still function correctly if they don’t exist NSIS protocols SHOULD NOT make the seamoby performance optimisations useless Anything to say about commonality in signalling application space? Should depend on seamoby to solve the general edge mobility problem and use their results?

CT interactions Two models: 1: Handover triggers context transfer which triggers signalling application which then uses NSIS protocols to initiate session 2: Handover triggers NSIS protocols which use context transfer to propagate NSIS state (both layers) to new AR and continue session (2) is similar to ‘virtual AR’ model (Thomas) Implications for NSIS peer relationships Could be an interesting application of SCTP multihoming

CT Interactions (2) Which model to use? And how to decide? What has to be done to make NSIS protocol state ‘context transferable’? How to handle the CT/non-CT case Retain seamoby optimisation => default on handover must be ‘no refresh’ Who generates ‘refresh please’ if no CT?

CARD Interactions Point-point negotiations scope-limited to mobile-AR link don’t need to involve NSIS protocols CARD process also involves query/preparation of resources on path from AR back into network So, NSIS protocols are a natural way to deal with this

CARD Interactions (2) Assumption: CARD can invoke NSIS signalling to query/prepare resources Consequences: 1: Need signalling applications with ‘query’ as well as ‘reserve’ semantics 2: Success of query involves knowing that new request will replace old one I.e. not a double reservation Starts to look like a complete test handover/local repair/mobility update procedure Limited to changed path segment