Title: Design Issues for NSIS Signaling Protocols. Henning ..
1Design Issues for NSIS Signaling Protocols
- Henning Schulzrinne
- Columbia University
- hgs_at_cs.columbia.edu
- NSIS working group meeting
- IETF 56 (March 2003, San Francisco)
2Overview
- My NSIS assumptions
- Logical components of NSIS functionality
- Transport layer
- requirements
- transport protocols
- Peer node discovery
3My 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
4Logical 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 ?
5Layering
- 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
6Reliability
- 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)
7Transport 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)
8Other 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
9Other 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!
10Transport 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)
11Building 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
12Transport 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)
13Reliability 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)
14Reliability 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?
15Transport (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()
16Transport (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
17Finding 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)
18When 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
19Next-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?
20Peer 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
21Peer 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
22Tradeoffs 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)
23Identifiers
- 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
24Identifiers 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
25Identifiers
- 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
26Globally 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)
27Cryptographically 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
28Strawman 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