Design Issues for NSIS Signaling Protocols

1
Design Issues for NSIS Signaling Protocols

• Henning Schulzrinne
• Columbia University
• hgs_at_cs.columbia.edu
• NSIS working group meeting
• IETF 56 (March 2003, San Francisco)

2
Overview

• My NSIS assumptions
• Logical components of NSIS functionality
• Transport layer
• requirements
• transport protocols
• Peer node discovery

3
My NSIS mental model

• Want to support a variety of signaling
  applications
• not just QoS and FW/NAT ? otherwise, why bother
  with 2-layer model?
• path-associated state management
• applications
• manage data flows along path NAT/firewall, QoS
• just along path
• active network code deposits
• network property discovery (traceroute-on-steroid
  s)
• network property management (not just
  NATs/firewalls)
• we are not designing all applications now, but
  should not lightly prevent future use
• Noel Chiappa the measure of a great
  architecture is one which meets requirements the
  designers didn't know about
• bidirectional signaling support with equivalent
  functionality
• NI ? NR and NR ? NI
• possibly NE ? NE

4
Logical components of a signaling protocol

• Three logical components of any signaling
  protocol
• Discovery whats the next node along the data
  path?
• Transport get information there (reliably)
• Service set up some state
• May be combined into one message, e.g., PATH
  combines discovery, transport (with 2961),
  session setup
• RSVP design makes it difficult to separate
  components
• addressing model (h-b-h, e2e) tied to message
• But a general signaling protocol should allow to
  swap out each part
• discovery ? may know from routing table or want
  to visit "old" path
• transport ? wide variety of requirements and
  underlying network support
• service ? two-layer model ?

5
Layering

• Some terminology confusion for NTLP service vs.
  protocol
• well take protocol (and contradict framework)
• functionality added to lower layer
• maybe messaging layer is less overloaded

peer discovery
NSLP2
NSLP1
NTLP
?
reliable transport
UDP
IPv4, IPv6
6
Reliability

• Most signaling applications require that end
  systems have reasonable assurance that state was
  established
• if it wasnt important, why bother sending
  message to begin with ??
• often, modestly time-critical
• human factors ? call setup latency
• economic ? fast and reliable teardown
• RSVP discovered later ? staged refresh timer (RFC
  2961)

7
Transport requirements

• Signaling transport users may require large data
  volumes
• active network code
• signed objects (easily several kB long if
  self-contained standard cert is 5 kB)
• objects with authentication tokens (OSP, )
• diagnostics accumulating data
• Signaling applications may have high rates
• DOS attacks
• automated retry after reservation failure
  (redial)
• odd routing (load balancing over backup link)

8
Other transport issues

• In-sequence delivery
• avoids lost teardown messages
• MTU discovery
• MTU can change during session ? may force
  end-to-end rediscovery
• NSIS packet size can change during transit
• not a problem if all messages are small (lt 512
  bytes?)
• Congestion control ? prevent network overload
• traffic burst for state synchronization
• retry after failures

9
Other transport issues (2)

• Flow control ? prevent NE overload
• traffic burst for state synchronization
• AAA makes per-node processing much more variable
• Security association
• needed for any channel security
• Message bundling
• probably interesting mostly for small (optimistic
  refresh?) messages
• DOS prevention
• need validated peer ? never, ever send more than
  one message for each request!

10
Transport protocols for IETF protocols

• trivial
• no RTT discovery
• no fragmentation
• exponential back-off for retransmission
• no windowing (although often unclear whether
  multiple outstanding messages are ok)
• no protection against identifier re-use after
  reboot
• work very poorly in wireless environments
• examples SIP (UDP), tftp, RSVP 2961, DNS, SLP
  (UDP)
• real
• examples SCTP, TCP
• flow control, congestion control, fragmentation,
  RTT estimation
• enhancements for selective acknowledgments
• fast retransmit (duplicate acknowledgements)

11
Building your own real transport protocol

• Only worthwhile if it avoids initial handshake
• Thus, one cannot just copy TCP or SCTP at the
  application layer (rely on session-based sequence
  numbers)
• Interoperability of transport protocols is
  non-trivial (see SCTP)
• Greatly increases protocol complexity (SCTP 134
  pages)
• Upgrades unlikely, both in specification and
  implementation (cant leverage large base)
• Unlikely that anything but most basic
  functionality gets implemented

12
Transport protocol options

• None ? raw IP
• limited to IPsec for NE-NE channel security
• cant send Path via IPsec no idea what SA
• TCP
• needs encapsulation ( one-word message length)
• HOL blocking waiting for old message
• IPsec or TLS for channel security
• SCTP
• easier end system diversity ? relevant mostly for
  path de-coupled
• avoids HOL blocking but effect is very hard to
  actually observe (see upcoming IEEE Network
  article)

UDP raw IP
TCP

• requires layering reliability on top of UDP
• add complications (see SIP experience)

13
Reliability options (1)

• End-to-end retransmission
• NI retransmits until confirmation by NR
• simple only requires NI state
• deals with node failures
• usually, no good RTT estimate ? flying blind
• doesnt work well for NR-initiated messages
• node processing (incl. AAA) adds delay
  variability ? RTT very unpredictable
• Hop-by-hop below NTLP
• share congestion state between sessions ? better
  RTT estimate
• re-use transport optimizations such as SACK
• inappropriate services?
• mandates explicit discovery (see later)

14
Reliability options (2)

• Hop-by-hop by NTLP per session
• can use implicit discovery
• RFC 2961
• simple exponential back-off no windowing, no
  SACK ? bad for long-delay pipes
• timer estimation difficult
• often few messages for one NSIS session
• must only have transport semantics
• Hop-by-hop by NSLP
• diversity of needs vs. cost
• what does a feature cost if not used/needed?
• whats left for NTLP in that case?

15
Transport (non-)issues

• But xP is stateful and we want soft-state
• existence of transport association should not be
  coupled to NTLP or NSLP state lifetime
• loss of transport does not signify anything
  (except maybe a reboot of the peer)
• primarily an optimization issue state
  maintenance vs. state establishment overhead
• Multicast
• Each branch can have own transport session
• In RSVP, only Path are multicast
• End-to-end principle
• not clear what the ends are here
• each NE is not just forwarding, but processing
  and modifying messages
• explicitly noted for performance enhancement
• Number of associations per node
• limited by select(), but not poll()

16
Transport (non-)issues

• State overhead
• information about next/previous hop has to be
  somewhere
• Transport header overhead
• most messages are likely gtgt 40 bytes
• Transport implementation overhead
• Conceivable end systems and routers already
  implement IP, UDP, TCP
• TCP needed for DIAMETER, SNMP in routers
• TCP on any reasonable mobile device (HTTP, SMTP,
  POP, IMAP, )
• Less clear for SCTP

17
Finding NSIS peers

• The problem is not finding (all/some) NSIS
  elements
• ? service location problem (SLP, DNS, etc.)
• but rather finding the next NE on the data path
  to the NR

implicit (send to destination)
active (by probing)
routing tables
explicit
passive (by observation)
next-hop router
directory (e.g., map next AS to NSIS node)
18
When to discover peers

• Can be triggered by NI or NE
• May not want it automatically
• e.g., remove reservation dont want to be first
  on new path!
• good to have separation of discovery and
  operation
• Options
• for every new NI-NR session
• including edge changes
• for every application-layer refresh
• requested by NI
• when detecting a route change in the middle of
  the network

NE
NE
no more traffic for session 42!
cannot tell (directly) that route has changed
19
Next-node discovery

• Next-node discovery probably causes operational
  distinction between path-coupled and
  path-decoupled
• path-coupled
• one of the routers downstream
• unless every data packet is a signaling packet,
  always only guess at coupling!
• path-decoupled
• some server in next AS
• anything else make (interdomain) sense?

20
Peer discovery RSVP style

• Forward messages (Path, PathTear) addressed to NR
• Backward messages (Resv,PathErr) sent hop-by-hop
• Path messages discovery special application
  semantics

NI
NE
NE
NR
non NE
Path
Ack
Resv
21
Peer node discovery path-coupled

• With forward connection setup
• Only needed if next IP hop is not NSIS-aware
• Discovery messages pure or application-enabled?

NI
NE
NE
NR
non NE
discovery
TP setup (if no existing assoc.)
NSIS
22
Tradeoffs for transport

• Waiting for TP connection adds additional delay
• always ½ RTT waiting for discovery response
• SCTP one round-trip for cookie exchange
• Likely only an issue at edge, since nodes in the
  middle will usually have existing transport
  connection
• Matters for mobile if first NE changes frequently
• may not if deeper inside the access network
• (and use SCTP to allow end system to change IP
  addresses)
• but TP address reverse-routing verification also
  makes some kinds of DOS attacks harder
• CPU exhaustion by sending bogus PK objects (e.g.,
  CMS)
• AAA attacks by forcing authorization checks that
  fail
• might use only on roaming handoff (get session
  secret)

23
Identifiers

• Need identifiers for each logical
  association/session
• know whether this path has been traversed before
• need discovery or not
• pass to correct upper layer handler
• SIP lesson do not overload identifiers

24
Identifiers should be

• globally unique
• otherwise, theyll have to be combined with
  something else
• not depend on host addresses
• NI and NR may change during session (mobility)
• NAT and RFC 1918-uniqueness issues
• RSVP SENDER_TEMPLATE and SESSION object ?
• constrains applications
• hard to match (multiple formats)
• same session has different identifiers along a
  path ? hard to manage
• probably not depend on globally unique host
  identifier (MAC) address
• constant length
• easy to parse and compare
• cryptographically random
• not sufficient for security, but often helps to
  prevent long-distance session stealing attacks
• can often avoid a complicated hash function

25
Identifiers

• Two types
• mappable
• via some lookup protocol or directory to another
  (lower-layer) identifier
• domain names, URLs, URNs, IP addresses
• not relevant to NSIS session identification
• non-mappable (distinguishers)
• just unique, but only operation is

26
Globally unique identifiers

• Only three known approaches
• Allocate hierarchically
• DNS, URLs
• expensive ? not likely to be another hierarchy
• Allocate centrally (maybe in pools)
• IEEE blocks
• Allocate randomly
• birthday problem
• None of existing global IDs are useful for NSIS
• MAC address not every interface/host has one
• IP addreses NATs
• DNS not every host has a domain name (or can
  find it)

27
Cryptographically random identifiers

• If sufficiently long, collision probability ltlt
  other failure scenarios (e.g., repeated packet
  loss)
• collision probability ? 1-e-n(n-1)/2d
• for n10,000, d264 ? 10-11
• for d2128 ? 10-30
• cf. Powerball lottery 10-8
• PSTN call failure probability 10-5

28
Strawman design considerations

• Do not try to replicate a real transport
  protocol at NTLP/NSLP
• Allow raw IP any suitable transport protocol
• Allow combining of discovery with NSLP signaling
• with tight MTU constraints (lt 500 bytes)
• with trivial transport functionality