NSIS and Mobility Layer Split

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 dont 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 gt 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 dont 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