NSIS and Mobility Layer Split & Framework Issues

1. NSIS and MobilityLayer Split & Framework Issues Robert Hancock NSIS Interim Meeting – Columbia University February 2003

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

3. 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)

4. 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…

5. 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 …

6. 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

7. 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?

8. 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?

9. 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)

10. 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

11. 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

12. 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

13. 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?

14. 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

15. 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?

16. 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

17. 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