Transcript 21-06-0763-00-0000-GIST-overview

IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN: 21-05-0763-00-0000
Title: An Overview of General Internet Signaling Transport
(GIST)
Date Submitted: September 19th, 2006
Presented at IEEE 802.21 session #NN in Melbourne
Authors or Source(s):
Robert Hancock, Eleanor Hepworth
Abstract: This presentation provides an overview of the history,
purpose and functionality of the GIST protocol being developed
in the IETF. GIST is a possible solution for the MIH transport
problem in IP networks.
21-05-0763-00-0000
IEEE 802.21 presentation release statements
This document has been prepared to assist the IEEE 802.21 Working Group. It is
offered as a basis for discussion and is not binding on the contributing
individual(s) or organization(s). The material in this document is subject to
change in form and content after further study. The contributor(s) reserve(s)
the right to add, amend or withdraw material contained herein.
The contributor grants a free, irrevocable license to the IEEE to incorporate
material contained in this contribution, and any modifications thereof, in the
creation of an IEEE Standards publication; to copyright in the IEEE’s name
any IEEE Standards publication even though it may include portions of this
contribution; and at the IEEE’s sole discretion to permit others to reproduce in
whole or in part the resulting IEEE Standards publication. The contributor also
acknowledges and accepts that this contribution may be made public by IEEE
802.21.
The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of
the IEEE-SA Standards Board Operations Manual
<http://standards.ieee.org/guides/opman/sect6.html#6.3> and in
Understanding Patent Issues During IEEE Standards Development
http://standards.ieee.org/board/pat/guide.html>
21-05-0763-00-0000
An Overview of General Internet
Signaling Transport (GIST)
Robert Hancock, Eleanor Hepworth
Melbourne, September 19th, 2006
21-05-0763-00-0000
Contents
• Status of this presentation
• Signaling at the IETF
• The evolution of the GIST concept
• The GIST problem space
• The fundamental requirements
• Derived requirements for a self-contained solution
• Four example functional areas
• Reliability
• Security
• NAT traversal
• Peer discovery
• Relevance to 802.21
• Status of the GIST proposal
21-05-0763-00-0000
Status of this Presentation
• For the avoidance of doubt:
• This is not a formal communication from the IETF, mipshop
WG or nsis WG
• It is an individual contribution to provide background to a
proposal that has been made in the mipshop WG about MIH
transport
• Purpose is to explain
• Not to convert (at least not explicitly)
• Explanation covers:
• What types of problem GIST has been designed to solve
• Why it has the functions that it does
• How it could be used
21-05-0763-00-0000
The Origins of GIST
What is ‘signaling’?
The first stages of NSIS
The final scope of GIST
21-05-0763-00-0000
What is ‘Signaling’?
• GIST = “General Internet Signaling Transport”, but what comes
in the scope of ‘signaling’ in the first place?
• A crude but high-level definition: signaling is everything that
is needed for host endpoints to interact explicitly with the
network infrastructure
• So, signaling includes all the problems of normal data transport
between application endpoints
• But it also involves additional problems and constraints because
of the infrastructure interactions:
• More varied deployment environments (e.g. a node might be
attached to any sort of technical or administrative domain)
• Different issues about migration and extensibility (because
infrastructure is always harder to evolve)
• Some additional functions (e.g. finding out about the
infrastructure as you move around)
21-05-0763-00-0000
The First Stages of NSIS (1/2)
• For a long time, the only IETF protocol with
explicit end-system/infrastructure interactions
was RSVP (RFC2205 etc.)
• The Internet architectural goal of
‘transparency’ actually makes signaling
unusual compared to telecomms networks
• RSVP was designed specifically to support
resource reservation following the Integrated
Services model
The Signaling Problem
Space: I
IntServ/
RSVP
• It was recognised around 2000-2001 that IntServ/RSVP was actually a
special case of a more general signaling problem: management of network
state along the path taken by a flow
• However, RSVP itself was not seen as directly extensible to handle this
broader problem space
• The ‘Next Steps in Signaling’ (NSIS) working group was formed to address
this problem
21-05-0763-00-0000
The First Stages of NSIS (2/2)
Signaling Applications
The Signaling Problem
• The goal of NSIS was to develop a
Space: II
generally usable protocol that could
Path
be applied to multiple ‘path-coupled’
measurement
signaling applications
Middlebox
• Resource reservation (a.k.a.
control
RSVPv2)
Resource
reservation
• Firewall control
• NAT control
• Path measurement and accounting
Pathcoupled
• Active networking
NTLP
• Etc. etc. etc.
• All the path-coupled transport problems would be handled by a
common protocol, the NSIS Transport Layer Protocol (NTLP)
• GIST is the solution for the NTLP
• Each signaling application would be implemented in a
dedicated NSIS Signaling Layer Protocol (NSLP)
21-05-0763-00-0000
The Final Scope of GIST
• It was recognised during the development of GIST that
signaling along a flow path is not the only type of signaling that
is useful
• Specific case (required for NAT control): “find a node at the
edge of the network I will be reachable via”
• There is no flow to couple the signaling to!
• However, all the other engineering requirements are
unchanged
The Signaling Problem
• This is the status of GIST today
21-05-0763-00-0000
Signaling Applications
• So there is a second stage of
generalisation: message routing
methods define how the signaling
is moved around the network
Space: III
Path
measurement
Middlebox
control
Resource
reservation
Overlay
management
Message
Routing
Methods
GIST
core
Pathcoupled
routing
Looseend
routing
Pattern
exploration
GIST Functionality
Core and derived requirements
The external view of GIST
Four key functions:
Reliability
Security
NAT traversal
Peer discovery
21-05-0763-00-0000
Core and Derived Requirements
• The basic requirements that GIST has to satisfy are simple (conceptually, at
least):
• Discover the next peer to signal to; usually, this means explicitly
discovering the IP address of the peer
• Transport each signaling application payload to it in turn, reliably and
securely if this is what the signaling application wants
• However, the necessity to have a complete solution introduces a whole set of
supporting requirements
• Reliability must be supported by congestion control
• It is not possible to define a once-and-for-all-circumstances security
protocol; therefore, this protocol must be negotiated
• The negotiation mechanism itself must not introduce reliability or
security weaknesses
• The negotiation and signaling setup must work through NATs
• The solution must work in the presence of IP tunnelling and multiple IP
versions
• The discovery process must be reactive to changes in the infrastructure
• And so on
• The end result is that internally, GIST has some complex aspects
21-05-0763-00-0000
However …
• Despite the internal complexity of some aspects of GIST, the
externally visible functionality remains just the basic
requirements defined at the outset
• The GIST specification defines a (non-normative) API
through which NSLPs should access its services
• Most of the details of the discovery and negotiation process,
transport functions, NAT traversal and so on are hidden from
the upper layers.
• Conceptually, the API looks like a very beefed-up UDP socket
API
Any NSLP
SendMessage
RecvMessage
InvalidateRoutingState
MessageStatus
SetStateLifetime
NetworkNotification
GIST
21-05-0763-00-0000
Key Function 1: Reliability (1/3)
• Why is this needed for GIST?
• In any system where there are multiple levels and timescales at which
errors can occur…
• It is often efficient to implement recovery mechanisms which are
optimised for the different error classes
•
Example: if all traffic is IP, link-layer ARQ is conceptually useless; however, we also
know it is a major benefit for most wireless systems
• Signalling application layer errors have one set of attributes:
• Usually caused by node failures (software or hardware), or failed
transactions with other protocols (AAA, database lookup)
• Often, failures are rare and non-recoverable
• Successful transactions have very variable latency
• Network layer errors have the opposite set of attributes
• Caused by packet loss (congestion or corruption)
• Failure is common and almost always recoverable
• Transactions are fast and have predictable latency
21-05-0763-00-0000
Key Function 1: Reliability (2/3)
• Why (continued):
• GIST provides fast recovery from network layer transmission
problems for efficient message transfer
• Especially for large messages
• GIST is able to use very aggressive transmission and recovery
schemes
• Windowing (multiple transmissions in parallel)
• Retransmission timers dynamically tuned to local network
characteristics
• Still protecting the network from congestion
• The signalling layer is able to concentrate on providing a robust
error detection mechanism to handle bigger catastrophes
• Without trying to optimise for faster recovery from more
frequent problems
21-05-0763-00-0000
Key Function 1: Reliability (3/3)
• How is it implemented?
• Simple: GIST embeds a TCP stack
• Extension in progress allows the use of SCTP as an option
• Signalling application layer is allowed to indicate whether
reliable transfer is required; if it is, GIST will guarantee to
deliver the message or return an error
• This indication can be done at the per-message level
• No need for the application to use different transport
protocols to handle different classes of message
• Reliability is optional to use (depends on the signalling
application design); however, it’s strongly recommended not to
attempt to implement transport functions in the signalling
application itself
21-05-0763-00-0000
Key Function 2: Security Negotiation (1/2)
• Why is this needed for GIST?
• Multi-stage argument:
• Message protection is MUST for at least some signalling
messages
• Channel security mechanisms are the most efficient and DoS
resistant solutions, but have to be integrated at or below the
transport layer
•
•
In the long run, variant parallel solutions will be required
•
•
•
One is strongly advised against re-inventing them at upper layers
As the state of security protocol engineering advances
Different solutions will be valuable for different deployment environments
However, the negotiation must not open the door to bidding
down attacks
• Hence, GIST needs to implement security protocol negotiation
securely
21-05-0763-00-0000
Key Function 2: Security Negotiation (2/2)
• How is it implemented?
• GIST (initially) embeds TLS to operate over TCP
• Other protocols can/will be embedded in the future
• IPsec; other embeddings of TLS, either over UDP or SCTP,
or using different authentication methods
• The GIST peer discovery handshake also includes capability
payloads which are used as an input to the selection process
• Post-setup, the negotiation is checked against bidding down
• The negotiation completes in 1RTT between peers
• The authenticated identities of the signalling peers are exposed
to the signalling applications so they can decide what level of
trust to apply
21-05-0763-00-0000
Key Function 3: NAT Traversal
• Why is it needed for GIST?
• NATs are everywhere
• Ideally, it is necessary to allow signalling to be initiated from
either side of the NAT
• The allowed set of protocols that GIST can use will be
influenced by the presence of the NAT
• Presence of the NAT may need to modify the signaling
payloads themselves (e.g. if the payloads contain addressing
information)
• How is it implemented?
• GIST defines a set of guidelines for modifying NATs to
make them GIST-friendly; it also contains heuristics to
identify unmodified NATs and options are in preparation to
work around them
• The solution is basically invisible to NSLPs
21-05-0763-00-0000
Key Function 4: Discovery (1/2)
• Why is it needed for GIST?
• We want to avoid depending on specific supporting protocols
• Some of the routing methods depend on discovering data that is
not easily configured into existing lookup mechanisms
• In general: what needs to be discovered depends on the local
topology and additional attributes of the signaling, but what
can be configured depends on a lookup against a global
name, or must be the same for all devices on a subnet
• Integrating the discovery process automatically integrates
reactiveness to infrastructure changes
• Discovery can be efficiently integrated with capability
negotiation, and makes the performance and security analysis
much easier
21-05-0763-00-0000
Key Function 4: Discovery (2/2)
• How is it implemented?
• The GIST negotiation handshake (Query/Response) also carries
out peer discovery
• Depending on the message routing method, the Query message
is encapsulated in a special way and processed in a special way
in the network infrastructure; the only requirement is that it
makes its way to the peer, which then completes the handshake
• Current message routing methods depend mainly on router
interception, but can also be used to send the Query to a
specific node which has been identified externally (fallback
solution)
• All of the details of the mechanism are invisible to the NSLP;
however, it has to provide the attributes (names, whatever) that
control the lookup
21-05-0763-00-0000
Status
Status of GIST
Status of GIST for MIH
21-05-0763-00-0000
Status of GIST
• Standardisation:
• GIST is currently at version -11
•
•
See the gory details at http://tools.ietf.org/wg/nsis/draft-ietf-nsis-ntlp/
Version -11 has just gone through one stage of IESG review
•
IESG review is the last stage before going into the editorial process
• There are about 6-8 implementations depending on exactly how
you count them
• Including open source implementations in C, C++ and Java
• There are also several supporting documents in their early
stages
• TLS extensions
• SCTP extensions
• NAT traversal
• Extensibility guidelines
21-05-0763-00-0000
Status of GIST for MIH
• Currently an individual submission into the mipshop WG
• Current draft at http://tools.ietf.org/wg/mipshop/draft-hancock-mipshop-gistfor-mih-00.txt
• Slides from Montreal at
http://www3.ietf.org/proceedings/06jul/slides/mipshop-4/sld1.htm
• A separate design considerations draft.
http://tools.ietf.org/wg/mipshop/draft-hepworth-mipshop-mih-designconsiderations-00.txt and
http://www3.ietf.org/proceedings/06jul/slides/mipshop-3/sld1.htm covers
some of the more general signaling issues
• Our initial assessment: that GIST is a good match for the MIH transport
problem
• Interestingly, the layer split evolved significantly during the course of the
NSIS work; however, it has ended up in the same place as MIH
• Main issues relate to the discovery process, and how to manage identifier
bindings between the two layers (see slides for further details)
21-05-0763-00-0000
The End
thanks!
21-05-0763-00-0000