Design Issues for NSIS Signaling Protocols - PowerPoint PPT Presentation

1 / 28
About This Presentation
Title:

Design Issues for NSIS Signaling Protocols

Description:

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) – PowerPoint PPT presentation

Number of Views:87
Avg rating:3.0/5.0
Slides: 29
Provided by: HenningSc7
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com