One document matched: draft-nsis-ext-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc3726 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3726.xml">
<!ENTITY rfc4080 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4080.xml">
<!ENTITY rfc4081 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4081.xml">
<!ENTITY ntlp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nsis-ntlp.xml">
<!ENTITY qosnslp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nsis-qos-nslp.xml">
<!ENTITY natfwnslp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nsis-nslp-natfw.xml">
<!ENTITY qspec SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nsis-qspec.xml">
<!ENTITY twolevel SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.braden-2level-signal-arch.xml">
<!ENTITY rfc1633 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1633.xml">
<!ENTITY rfc2205 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2205.xml">
<!ENTITY rfc4094 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4094.xml">
<!ENTITY rfc3692 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3692.xml">
<!ENTITY rfc3936 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3936.xml">
<!ENTITY nsisauth SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.manner-nsis-nslp-auth.xml">
<!ENTITY gistpio SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.manner-nsis-gist-dccp.xml">
<!ENTITY gistdccp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.manner-nsis-peering-data.xml">
<!ENTITY cl SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kappler-nsis-qosmodel-controlledload.xml">
<!ENTITY resvaggr SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bless-nsis-resv-aggr.xml">
<!ENTITY hypath SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cordeiro-nsis-hypath.xml">
<!ENTITY raobad SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rahman-rtg-router-alert-dangerous.xml">
<!ENTITY estmrm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bless-nsis-est-mrm.xml">
]>
<rfc category="info" docName="draft-nsis-ext-02.txt" ipr="full3978">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?target subcompact="yes"?>
<front>
<title abbrev="NSIS User and Extension Guide">Using and Extending the NSIS
Protocol Family</title>
<author fullname="Jukka Manner" initials="J." surname="Manner">
<organization abbrev="TKK">Helsinki University of Technology
(TKK)</organization>
<address>
<postal>
<street>P.O. Box 3000</street>
<city>Espoo</city>
<code>FIN-02015 TKK</code>
<country>Finland</country>
</postal>
<phone>+358 9 451 2481</phone>
<email>jukka.manner@tkk.fi</email>
<uri>http://www.netlab.tkk.fi/~jmanner/</uri>
</address>
</author>
<author fullname="Roland Bless" initials="R." surname="Bless">
<organization abbrev="Univ. of Karlsruhe">Institute of Telematics,
Universitaet Karlsruhe (TH)</organization>
<address>
<postal>
<street>Zirkel 2</street>
<city>Karlsruhe</city>
<code>76128</code>
<country>Germany</country>
</postal>
<phone>+49 721 608 6413</phone>
<email>bless@tm.uka.de</email>
<uri>http://www.tm.uka.de/~bless</uri>
</address>
</author>
<author fullname="John Loughney" initials="J" surname="Loughney">
<organization>Nokia</organization>
<address>
<postal>
<street>955 Page Mill Road</street>
<city>Palo Alto</city>
<code>94303</code>
<country>USA</country>
</postal>
<phone>+1 650 283 8068</phone>
<email>john.loughney@nokia.com</email>
</address>
</author>
<author fullname="Elwyn Davies" initials="E B" role="editor"
surname="Davies">
<organization>Folly Consulting</organization>
<address>
<postal>
<street></street>
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>elwynd@folly.org.uk</email>
<uri>http://www.folly.org.uk</uri>
</address>
</author>
<date month="November" year="2008" />
<abstract>
<t>This document gives an overview of the Next Steps in Signaling (NSIS)
framework and protocol suite created by the NSIS working group during
the period 2001-2008 together with suggestions on how the industry can
make use of the new protocols, and how the community can exploit the
extensibility of both the framework and existing protocols to address
future signaling needs.</t>
</abstract>
</front>
<middle>
<section title="Introduction and History">
<t>The Transport Area Directors held a Next Steps in Signaling (NSIS)
birds of a feather session on Wednesday 21st March 2001 at the 50th IETF
meeting in Minneapolis. The goal of the session was to discuss and
gather an initial set of requirements for a next generation Internet
signaling protocol suite as it was felt that the current RSVP-based
solutions have short-comings, e.g., with respect to mobility or QoS
interoperability. The NSIS Working Group was officially formed later
that year, in November 2001 and had its first meeting at the IETF 52 in
Salt Lake City in December 2001.</t>
<t>The initial charter of NSIS was focused on QoS signaling as the first
use case, taking the Resource ReSerVation Protocol (RSVP) as the
background for the work. In May 2003, middlebox traversal was added as
an explicit second use case. The requirements for the new generation of
signaling protocols are documented in <xref target="RFC3726"></xref> and
an analysis of existing signaling protocols can be found in <xref
target="RFC4094"></xref>.</t>
<t>The design of NSIS is based on a two-layer model, where a general
signaling transport layer provides services to an upper signaling layer.
The design was influenced by Bob Braden's Internet Draft entitled "A
Two-Level Architecture for Internet Signaling" <xref
target="I-D.braden-2level-signal-arch"></xref>.</t>
<t>This document gives an overview of what the NSIS framework and
protocol suite is at the time of writing (2008), provides help and
guidelines to the reader as to how NSIS can be used in an IP network,
and how the protocol suite can be enhanced to satisfy new use cases.</t>
</section>
<section title="The NSIS Architecture">
<t>The design of the NSIS protocol suite reuses ideas and concepts from
RSVP but essentially divides the functionality into two layers. The
lower layer, the NSIS Transport Layer Protocol (NTLP), is in charge of
transporting the higher layer protocol messages to the next signaling
node on the path. This includes discovery of the next hop NSIS node,
which may not be the next routing hop, and different transport and
security services depending on the signaling application requirements.
The General Internet Signaling Transport (GIST) <xref
target="I-D.ietf-nsis-ntlp"></xref> has been developed as the protocol
that fulfills the role of the NTLP. The NSIS suite supports both IP
protocol versions, IPv4 and IPv6.</t>
<t>The actual signaling application logic is implemented in the higher
layer of the NSIS stack, the NSIS Signaling Layer Protocol (NSLP). While
GIST is only concerned in transporting NSLP messages between two
end-points, the end-to-end signaling functionality is provided by the
NSLP protocols if needed - not all NSLP protocols need to perform
end-to-end signaling, even the current protocols have features to
confine the signaling to a limited path. Messages transmitted by GIST on
behalf of an NSLP are identified by a unique NSLP identifier (NSLPID)
associated with the NSLP. Two NSLP protocols are currently standardized:
one concerning Quality of Service signaling and one to enable
NAT/Firewall traversal.</t>
<t>NSIS is primarily designed to provide the signaling needed to install
state on nodes that lie on the path that will be taken by some
end-to-end flow of data packets in order to facilitate or enhance some
characteristic of the data flow. This is achieved by routing signaling
messages along the same path (known as "path-coupled signaling") and
intercepting the signaling message at NSIS capable nodes. Parameters
carried by the signaling message drive the operation of the relevant
transport or signaling application. In particular, the messages will
carry Message Routing Information (MRI) that will allow the NSIS nodes
to identify the data flow to which the signaling applies. Generally, the
intercepted messages will be reinjected into the network after
processing by the NSIS entities and routed further towards the
destination, possibly being intercepted by additional NSIS nodes before
arriving at the flow endpoint.</t>
<t>As with RSVP, it is expected that the signaling message will make a
complete round trip either along the whole end-to-end path or a part of
it if the scope of the signaling is limited. This implements a two-phase
strategy in which capabilities are assessed and provisional reservations
are made on the outbound leg; these provisional reservations are then
confirmed and operational state installed on the return leg. Unlike
RSVP, signaling is normally initiated at the source of the data flow
making it easier to ensure that the signaling follows the expected path
of the data flow, but can also be receiver initiated as in RSVP.</t>
<t>A central concept of NSIS is the Session Identifier (SID). Signaling
application states are indexed and referred to through the SID. This
decouples the state information from IP addresses, allowing dynamic IP
address changes for signaling flows, e.g., due to mobility: changes in
IP addresses do not force complete tear down and re-initiation of a
signaling application state, merely an update of the state
parameters.</t>
<t>The SID is not meaningful by itself, but is rather used together with
the NSLP identifier (NSLPID) and the Message Routing Information (MRI).
This 3-tuple is used by GIST to index and manage the signaling
flows.</t>
<t>The following design restrictions were imposed for the first phase of
the protocol suite. They may be lifted in future and new functionality
may be added into the protocols at some later stage.</t>
<t><list style="symbols">
<t>Path-coupled signaling only: GIST transports messages towards an
identified unicast data flow destination based on the signaling
application request, and does not directly support path-decoupled
signaling, e.g., QoS signaling to a bandwidth broker. The framework
also supports a "Loose-End" message routing method used to discover
GIST nodes with particular properties in the direction of a given
address, for example the NAT/FW NSLP uses this method to discover a
NAT along the upstream data path.</t>
<t>No multicast support: Introducing support for multicast was
deemed too much overhead, if considering the currently limited
support for global IP multicast. Thus, the current GIST and the NSLP
specifications consider unicast flows only.</t>
</list></t>
<t>The key documents specifying the NSIS framework are:</t>
<t><list style="symbols">
<t>Requirements for Signaling Protocols <xref
target="RFC3726"></xref></t>
<t>Next Steps in Signaling: Framework <xref
target="RFC4080"></xref></t>
<t>Security Threats for NSIS <xref target="RFC4081"></xref></t>
</list></t>
<t>The protocols making up the suite specified by the NSIS working group
are documented in:<list style="symbols">
<t>The General Internet Signaling Transport protocol <xref
target="I-D.ietf-nsis-ntlp"></xref></t>
<t>Quality of Service NSLP (QoS NSLP) <xref
target="I-D.ietf-nsis-qos-nslp"></xref></t>
<t>The QoS specification template <xref
target="I-D.ietf-nsis-qspec"></xref></t>
<t>NAT/Firewall traversal NSLP <xref
target="I-D.ietf-nsis-nslp-natfw"></xref></t>
</list>The next three sections provide a brief survey of GIST, the QoS
NSLP, and the NAT/Firewall NSLP.</t>
</section>
<section title="The General Internet Signaling Transport">
<t>The General Internet Signaling Transport (GIST) <xref
target="I-D.ietf-nsis-ntlp"></xref> provides a signaling transport and
security services to NSIS Signaling Layer Protocols (NSLP) and the
associated signaling applications. GIST does not define new IP transport
protocols or security mechanisms but rather makes use of existing
protocols, such as TCP, UDP, TLS and IPsec. Applications can indicate
the desired reliability, e.g., unreliable or reliable, and GIST then
uses the most appropriate transport protocol to achieve the goal. If
applications request also security, GIST uses TLS. The GIST layered
protocol stack is shown in <xref target="f-proto_arch"></xref>.</t>
<figure anchor="f-proto_arch" title="The NSIS protocol stack">
<artwork><![CDATA[
+-----+ +--------+ +-------+
| | | | | |
| QoS | | NAT/FW | | ... | NSLP
| | | | | |
+-----+ +--------+ +-------+
----------------------------------------------------------------------
+--------------------------+
| |
| GIST | NTLP
| |
+--------------------------+
----------------------------------------------------------------------
+--------------------------+
| TLS |
+--------------------------+
+--------------------------+
| TCP | UDP | SCTP | DCCP |
+--------------------------+
+--------------------------+
| IPsec |
+--------------------------+
+--------------------------+
| IPv4 | IPv6 |
+--------------------------+
]]></artwork>
</figure>
<t>GIST divides up the end-to-end path to be taken by the data flow into
a number of segments between pairs of NSIS aware peer nodes located
along the path. Not every router or other middlebox on the path needs to
be NSIS aware: each segment of the signaling path may incorporate
several routing hops. Also not every NSIS aware node necessarily
implements every possible signaling application. If the signaling for a
flow requests services from a subset of the applications, then only
nodes that implement those services are expected to participate as
peers, and even some of these nodes can decline to operate on a
particular flow if, for example, the additional load might overload the
processing capability of the node. These characteristics mean that
incremental deployment of NSIS capabilities is possible both with the
initial protocol suite, and for any future NSLP applications that might
be developed. The following paragraphs describe how a signaling segment
is setup offering the transport and security characteristics needed by a
single NSLP.</t>
<t>When an NSLP application wants to send a message to its next peer,
GIST starts the process of discovering the next signaling node by
sending a Query message towards the destination of the related data
flow. This Query carries the NSLP identifier (NSLPID) and Message
Routing Information (MRI) among others. The MRI contains enough
information to control the routing of the signaling message and identify
the associated data flow. The next GIST node on the path receives the
message and if it is running the same NSLP, it provides the MRI to the
NSLP application and requests it to make a decision on whether to peer
with the querying node. If the NSLP application chooses to peer, GIST
sets up a Message Routing State (MRS) between the two nodes for the
future exchange of NSLP data. State setup is performed by a three-way
handshake that allows for negotiation of signaling flow parameters and
provides counter-measures against several attacks like denial-of-service
by using cookie mechanisms and a late state installation option.</t>
<t>If a transport connection is required and needs to provide for
reliable or secure signaling, like TCP or TLS/TCP, a Messaging
Association (MA) is established between the two peers. An MA can be
re-used for signaling messages concerning several different data flows,
i.e., signaling messages between two nodes are multiplexed over the same
transport connection. This can be done when the transport requirements
(reliability, security) of a new flow can be met with an existing MA,
i.e., the security and transport properties of an existing MA are
equivalent or better than what is requested by the new MA.</t>
<t>For path-coupled signaling, we need to find the nodes on the data
path that should take part in the signaling of an NSLP and invoke them
to act on the arrival of such NSLP signaling messages. The basic concept
is that such nodes along a flow's data path intercept the corresponding
signaling packets and are thus discovered automatically. It was
originally envisaged that GIST would place a Router Alert Option (RAO)
in Query message packets to ensure that they are intercepted by NSIS
aware nodes as in RSVP.</t>
<t>Late in the development of GIST serious concerns were raised in the
IETF about the security risks and performance implications of extensive
usage of the RAO <xref
target="I-D.rahman-rtg-router-alert-dangerous"></xref>, as well as
discovery of evidence that several existing implementations of RAO were
inconsistent with the standards and would not support the NSIS usage.
There were also concerns that extending the need for RAO recognition in
the fast path of routers that are frequently implemented in hardware
would delay or deter implementation and deployment of NSIS. An
alternative mechanism was therefore standardized.</t>
<t>The approved version of GIST specifies that NSIS nodes recognise UDP
packets directed to a specific destination port and containing a GIST
specific "magic number" as the first 32 bits of the UDP payload as Query
messages that need to be intercepted. It is recognised that this
interception method is not the most efficient possible and GIST provides
for the use of alternatives, such as the RAO, for specific NSLPs as a
part of its extensibility design. Further intentional bypassing of
signaling nodes can be accomplished either in GIST or in the NSLP.</t>
<t>Since GIST carries information about the data flow inside its
messages (in the MRI), NAT gateways must be aware of GIST in order to
let it work correctly. GIST provides a special object for NAT traversal
so that the actual translation is disclosed if a GIST-aware NAT gateway
provides this object.</t>
<t>As with RSVP, all the state installed by NSIS protocols is
"soft-state" that will expire and be automatically removed unless it is
periodically refreshed. NSIS state is held both at the signaling
application layer and in the transport layer, and is maintained
separately. NSLPs control the lifetime of the state in the application
layer by setting a timeout and sending periodic "keep alive" messages
along the signaling path if no other messages are required. The MAs and
the routing state are maintained semi-independently by the transport
layer, because MAs may be used by multiple NSLP sessions, and can also
be recreated "on demand" if the node needs to reclaim resources. The
transport layer can send its own "keep alive" messages across a MA if no
NSLP messages have been sent, for example if the transport layer decides
to maintain a heavily used MA even though there is no current NSLP
session using it. State can also be deleted explicitly when no longer
needed.</t>
<t>If there is a change in the route used by a flow for which NSIS has
created state, NSIS needs to detect the change in order to determine if
the new path contains additional NSIS nodes that should have state
installed. GIST may use a range of triggers in order to detect a route
change. It probes periodically for the next peer by sending a GIST
Query, thereby detecting a changed route and GIST peer. GIST monitors
routing tables, the GIST peer states, and notifies NSLPs of any routing
changes. It is then up to the NSLPs to act appropriately, if needed,
e.g., by issuing a refresh message. The periodic queries also serve to
maintain the soft-state in nodes as long as the route is unchanged.</t>
<t>In summary, GIST provides several services in one package to the
upper layer signaling protocols:</t>
<t><list style="symbols">
<t>Signaling peer discovery: GIST is able to find the next hop node
that runs the NSLP being signaled for.</t>
<t>Multiplexing: GIST reuses already established signaling
relationships and messaging associations to peers if the signaling
flows traverse the same next signaling hop.</t>
<t>Transport: GIST provides transport with different attributes,
namely reliable/unreliable and secure/unsecure.</t>
<t>Confidentiality: If security is requested, GIST uses TLS to
provide an encrypted and integrity protected message transport to
the next signaling peer.</t>
<t>Routing changes: GIST detects routing changes, but instead of
acting on its own, it merely sends a notification to the local NSLP.
It is then up to the NSLP to act.</t>
<t>Fragmentation: GIST uses either a known Path MTU for the next hop
or limits its message size to 576 bytes. If fragmentation is
required it automatically establishes an MA and sends the signaling
traffic over a reliable protocol, e.g., TCP.</t>
<t>State maintenance: GIST establishes and then maintains the
soft-state that controls communications through MAs between GIST
peers along the signaling path, according to usage parameters
supplied by NSLPs and local policies.</t>
</list></t>
</section>
<section title="Quality of Service NSLP">
<t>The Quality of Service (QoS) NSIS Signaling Layer Protocol (NSLP)
establishes and maintains state at nodes along the path of a data flow
for the purpose of providing some forwarding resources for that flow. It
is intended to satisfy the QoS-related requirements of RFC 3726 <xref
target="RFC3726"></xref>. No support for QoS architectures based on
bandwidth brokers is currently included.</t>
<t>The design of the QoS NSLP is conceptually similar to RSVP, RFC 2205
<xref target="RFC2205"></xref>, and uses soft-state peer-to-peer refresh
messages as the primary state management mechanism (i.e., state
installation/refresh is performed between pairs of adjacent NSLP nodes,
rather than in an end-to-end fashion along the complete signaling path).
The QoS NSLP extends the set of reservation mechanisms to meet the
requirements of RFC 3726 <xref target="RFC3726"></xref>, in particular
support of sender or receiver-initiated reservations, as well as, a type
of bi-directional reservation and support of reservations between
arbitrary nodes, e.g., edge-to-edge, end-to-access, etc. On the other
hand, there is currently no support for IP multicast.</t>
<t>A distinction is made between the operation of the signaling protocol
and the information required for the operation of the Resource
Management Function (RMF). RMF-related information is carried in the
QSpec (QoS Specification) <xref target="I-D.ietf-nsis-qspec"></xref>
object in QoS NSLP messages. This is similar to the decoupling between
RSVP and the IntServ architecture, RFC 1633 <xref
target="RFC1633"></xref>. The QSpec carries information on resources
available, resources required, traffic descriptions and other
information required by the RMF.</t>
<t>The QoS NSLP supports different QoS models, because it does not
define the QoS mechanisms and RMF that have to be used in a domain. As
long as a domain knows how to perform admission control for a given
QSpec, QoS NSLP actually does not care how the specified constraints are
enforced and met, e.g., by putting the related data flow in the topmost
of four DiffServ classes, or by putting it into the third highest of
twelve DiffServ classes. The particular QoS configuration used is up to
the network provider of the domain. The QSpec can be seen as a common
language to express QoS requirements between different domains and QoS
models.</t>
<t>In short, the functionality of the QoS NSLP includes: <list
style="symbols">
<t>Conveying resource requests for unicast flows</t>
<t>Resource requests (QSpec) are decoupled from the signaling
protocol (QoS NSLP)</t>
<t>Sender- and receiver-initiated reservations, as well as,
bi-directional</t>
<t>Soft-state and reduced refresh (keep-alive) signaling</t>
<t>Session binding, session X can be valid only if session Y is
too</t>
<t>Message scoping, end-to-end, edge-to-edge or end-to-edge (proxy
mode)</t>
<t>Protection against message re-ordering and duplication</t>
<t>Group tear, tearing down several session with a single
message</t>
<t>Support for re-routing, e.g., due to mobility</t>
<t>Support for request priorities and preemption</t>
<t>Stateful and stateless nodes: stateless operation is particularly
relevant in core networks where large amounts of QoS state could
easily overwhelm a node</t>
<t>Reservation aggregation</t>
</list>The protocol also provides for a proxy mode to allow the QoS
signaling to be implemented without needing all end hosts to be capable
of handling NSIS signaling.</t>
</section>
<section title="NAT/Firewall Traversal NSLP">
<t>The NAT/Firewall Traversal NSLP <xref
target="I-D.ietf-nsis-nslp-natfw"></xref> lets end-hosts interact with
NAT and firewall devices in the data path. Basically it allows for a
dynamic configuration of NATs and/or firewalls along the data path in
order to enable data flows to traverse these devices without being
obstructed. For instance, firewall pinholes could be opened on demand by
authorized hosts. Furthermore, it is possible to block unwanted incoming
traffic on demand, e.g., if an end-host is under attack.</t>
<t>Configurations to be implemented in NAT and firewall devices
signalled by the NAT/Firewall NSLP take the form of a (Pattern, Action)
pair, where the pattern specifies a template for packet header fields to
be matched. The device is then expected to apply the specified action to
any passing packet that matches the template. Actions are currently
limited to ALLOW (forward the packet) and DENY (drop the packet). The
template specification allows for a greater range of packet fields to be
matched than those allowed for in the GIST MRI.</t>
<t>Basically NAT/Firewall signaling starts at the data sender (NSIS
Initiator) before any actual application data packets are sent.
Signaling messages may pass several NAT/Firewall NSLP-aware middleboxes
(NSIS Forwarder) on their way downstream and usually hit the receiver
(being the NSIS Responder). A proxy mode is also available for cases
where the NAT/Firewall NSLP is not fully supported along the complete
data path. NAT/Firewall NSLP is based on a soft-state concept, i.e., the
sender must periodically repeat its request in order to keep it
active.</t>
<t>Additionally, the protocol also provides functions for receivers
behind NATs. The receiver may request an external address that is
reachable from outside. The reserved external address must, however, be
communicated to the sender out-of-band by other means, e.g., by
application level signaling. After this step the data sender may
initiate a normal NAT/Firewall signaling in order to create firewall
pinholes.</t>
<t>The protocol also provides for a proxy mode to allow the NAT/Firewall
signaling to be implemented without needing all end hosts to be capable
of handling NSIS signaling.</t>
</section>
<section title="Deploying the Protocols">
<!--
Something about generic issues with deployment, e.g., which nodes and
what software needs updates, NAT/FW things, etc. incremental deployment.
-->
<t>First of all, NSIS implementations must be available in at least some
of the corresponding network nodes (i.e., routers, firewalls, or NAT
gateways) and end-hosts. That means not only GIST support, but also the
NSLPs and their respective control functions (such as a resource
management function for QoS admission control etc.) must be implemented.
NSIS is capable of incremental deployment and an initial deployment does
not need to involve every node in a network domain. This is discussed
further in <xref target="incremental"></xref>.</t>
<t>Another important issue is that applications may need to be made
NSIS-aware, thereby requiring some effort on the applications
programmer's behalf. Alternatively, it may be possible to implement
separate applications to control, e.g., the network QoS requests or
firewall pinholes, without needing to update the actual applications
that will take advantage of NSIS capabilities.</t>
<section title="Obstacles">
<t>Although GIST is no longer dependent on RAO (there is known to be
network equipment with broken implementations of the RAO deployed), if
NSIS is to be deployed in routers with hardware-based forwarding
engines it is not guaranteed that the hardware will be able to divert
Query packets identified by a well-known UDP port into the slow path,
which will make deployment of NSIS dependent on hardware replacement
rather than software upgrade. However, the removal of dependence on
RAO makes it more likely that NSIS Query packets can be forwarded
through nodes that are not NSIS aware.</t>
<t>NAT gateways and firewalls may also hinder initial deployment of
NSIS protocols as they may either filter signaling traffic or perform
NSIS-unaware address translations.</t>
</section>
<section anchor="incremental"
title="Incremental Deployment and Workarounds">
<t>NSIS is specifically designed to be incrementally deployable. It is
not required that all nodes on the signaling and data path are NSIS
aware. To make any use of NSIS at least two nodes on the path need to
be NSIS aware. However, it is not essential that the initiator and
receiver of the data flow are NSIS aware. Both the QoS and
NAT/Firewall NSLPs provide "proxy modes" in which nodes adjacent to
the initiator and/or receiver can act as proxy signaling initiator or
receiver. An initiator proxy can monitor traffic and, hopefully,
detect when a data flow of a type needing NSIS support is being
initiated. The proxies can act more or less transparently on behalf of
the data flow initiator and/or receiver to set up the required NSIS
state and maintain it while the data flow continues. This capability
reduces the immediate need to modify all the data flow end points
before NSIS is viable.</t>
</section>
</section>
<section title="Security Features">
<t>Basic security functions are provided at the GIST layer, e.g.,
protection against some blind or denial-of-service attacks. Conceptually
it is difficult to protect against on-path attacker and
man-in-the-middle attacks, because a basic functionality of GIST is to
discover yet unknown signaling peers. Transport security can be
requested by signaling applications and is realized by using TLS between
signaling peers, i.e., authenticity and confidentiality of signaling
messages can be assured between peers. GIST allows for mutual
authentication of the signaling peers (using TLS means like
certificates) and can verify the authenticated identity against a
database of nodes authorized to take part in GIST signaling. It is,
however, a matter of policy that the identity of peers is verified and
accepted upon establishment of the secure TLS connection.</t>
<t>While GIST is handling authentication of peer nodes, more fine
grained authentication may be required in the NSLP protocols. There is
currently an ongoing work to specify common authorization mechanisms to
be used in NSLP protocols <xref
target="I-D.manner-nsis-nslp-auth"></xref>, thus allowing, e.g.,
per-user and per-service authorization.</t>
</section>
<section title="Extending the Protocols">
<t>This section discusses the ways that are available to extend the NSIS
protocol suite. The Next Steps in Signaling (NSIS) Framework <xref
target="RFC4080"> NSIS Framework</xref> describes a two-layer framework
for signaling on the Internet, comprising a generic transport layer with
specific signaling layers to address particular applications running
over this transport layer. The model is designed to be highly extensible
so that it can be adapted for different signaling needs.</t>
<t>It is expected that additional signaling requirements will be
identified in future. The two layer approach allows for NSLP signaling
applications to be developed independently of the transport protocol.
Further NSLPs can therefore be developed and deployed to meet these new
needs using the same GIST infrastructure thereby providing a level of
macro-extensibility. However, the GIST protocol and the two signaling
applications have been designed so that additional capabilities can be
incorporated into the design should additional requirements within the
general scope of these protocols need to be accommodated.</t>
<t>The NSIS framework is also highly supportive of incremental
deployment. A new NSLP need not be available on every NSIS aware node in
a network or along a signaling path in order to start using it. Nodes
that do not (yet) support the application will forward it without
complaint until it reaches a node where the new NSLP application is
deployed.</t>
<t>One key functionality of parameter objects carried in NSIS protocols
is the so-called "Extensibility flags (AB)". All the existing protocols
(and any future ones conforming to the standards) can carry new
experimental objects, where the AB-flags can indicate whether a
receiving node must interpret the object, or whether it can just drop
them or pass them along in subsequent messages sent out further on the
path. This functionality allows defining new objects without forcing all
network entities to understand them.</t>
<section title="Overview of Administrative Actions Needed When Extending NSIS ">
<t>Generally, NSIS protocols can be extended in multiple ways, many of
which require the allocation of unique code point values in registries
maintained by IANA on behalf of the IETF. This section is an overview
of the administrative mechanisms that might apply. The extensibility
rules are based upon the procedures by which IANA assigns values:
"Standards Action" (as defined in [IANA]), "IETF Action", "Expert
Review", and "Organization/Vendor Private", defined below. The
appropriate procedure for a particular type of code point is defined
in one or other of the NSIS protocol documents, mostly <xref
target="I-D.ietf-nsis-ntlp"></xref>.</t>
<t>Extensions subject to "IETF Action" require publication of either a
Standards Track RFC, Experimental RFC or an Informational RFC with
details of the required allocation. In particular defining a new
signaling application for general deployment requires that it is
defined in a published RFC (generally Standards Track but possibly
Experimental) that would request the allocation of an NLSPID for the
new application.</t>
<t>Extensions subject to "Expert Review" refer to values that are to
be reviewed by an Expert designated by the IESG. The code points from
these ranges are typically used for experimental extensions; such
assignments MUST be requested by either Experimental or Information
RFCs that document their use and processing, and the actual
assignments made during the IANA actions for the document. Values from
"Expert Review" ranges MUST be registered with IANA.</t>
<t>"Organization/Vendor Private" ranges refer to values that are
enterprise-specific. In this way, different enterprises, vendors, or
Standards Development Organizations (SDOs) can use the same code point
without fear of collision.</t>
<t>In the NSIS protocols, experimental code points are allocated for
experimentation, usually within closed networks, as explained in <xref
target="RFC3692"></xref>. If these experiments yield useful results,
it is assumed that they will be formally allocated by one of the above
mechanisms. There is no guarantee that independent experiments will
not be using the same code point!</t>
</section>
<section title="GIST">
<t>GIST is extensible in several aspects. In this list, references to
document sections refer to the GIST specification <xref
target="I-D.ietf-nsis-ntlp"></xref>.<list style="symbols">
<t>Use of different Message Routing Methods: currently only two
message routing methods are supported (Path-coupled MRM and
Loose-End MRM), but further MRMs may be defined in the future. See
Section 3.8. One possible additional MRM under development is
documented in <xref target="I-D.bless-nsis-est-mrm"></xref>. This
MRM would direct signaling towards an explicit target address
other than the (current) data flow destination and is intended to
assist setting up of state on a new path during
'make-before-break' handover sequences in mobile operations. Note
that alternative routing methods may require modifications to the
firewall traversal techniques used by GIST and NSLPs.</t>
<t>Use of different transport protocols or security capabilities:
the initial handshake allows a negotiation of the transport
protocols to be used. Currently, a proposal to add DCCP and DTLS
to GIST exists <xref target="I-D.manner-nsis-gist-dccp"></xref>.
See Sections 3.2 and 5.7. GIST expects alternative capabilities to
be treated as selection of an alternative protocol stack. Within
the protocol stack, the individual protocols used are specified by
MA Protocol IDs which are allocated from an IANA registry if new
protocols are to be used. See Sections 5.7 and 9.</t>
<t>Use of alternative security services: Currently only TLS is
specified for providing secure channels with MAs. Section 3.9
suggests that alternative protocols could be used, but the
interactions with GIST functions would need to be carefully
specified. See also Section 4.4.2.</t>
<t>Query mode packet interception schemes: GIST has standardized a
simple scheme using a well-known UDP port number plus a "magic
number" at the start of the UDP payload. Alternative schemes,
possibly including a reversion to the original proposal to use RAO
mechanisms, can be specified as extensions. See Sections 5.3.2 and
5.3.2.5. Each NSLP needs to specify which interception mechanisms
apply through specifying membership of an "interception
class".</t>
<t>Use of alternative NAT traversal mechanisms: the mechanisms
proposed for both legacy NAT traversal (Section 7.2.1) and
GIST-aware NAT traversal (Section 7.2.2) can be extended or
replaced. Note that there is extensive discussion of NAT traversal
in the NAT/Firewall NSLP specification <xref
target="I-D.ietf-nsis-nslp-natfw"></xref>.</t>
<t>Additional error identifiers: Making extensions to any of the
above items may result in new error modes having to be catered
for. See Section 9 and Appendix A Sections A.4.1 - A.4.3.</t>
<t>Generally: the AB-flags enable the community to specify new
objects applicable to GIST, that can be carried inside a signaling
session without breaking existing implementations. The AB-flags
can also be used to indicate in a controlled fashion that a
certain object must be understood by all GIST nodes, which makes
it possible to probe for the support of an extension. One such
object already designed is the "Peering Information Object (PIO)"
<xref target="I-D.manner-nsis-peering-data"></xref> that allows a
QUERY message to carry additional peering data for the recipient
for making the peering decision.</t>
</list>Finally, and more generally, as asserted in Section 1 of the
GIST specification, the GIST design could be extended to cater for
multicast flows and for situations where the signaling is not tied to
an end-to-end data flow, but it is not clear whether this could be
done in a totally backwards compatible way, and is not considered
within the extensibility model of NSIS.</t>
</section>
<section title="QoS NSLP">
<t>The QoS NSLP provides signaling for QoS reservations on the
Internet. The QoS NSLP decouples the resource reservation model or
architecture (QoS model) from the signaling. The signaling protocol is
defined in Quality of Service NSLP (QoS NSLP) <xref
target="I-D.ietf-nsis-qos-nslp"></xref>. The QoS models are defined in
separate specifications and the QoS NSLP can operate with one or more
of these models as required by the environment where it is used. It is
anticipated that additional QoS models will be developed to address
various Internet scenarios in the future. Extensibility of QoS models
is considered in <xref target="model_ext"></xref>.</t>
<t>The QoS NSLP specifically mentions the possibility of using
alternative Message Routing Methods (MRMs), apart from the general
ability to extend NSLPs using new objects with the standard "AB"
extensibility flags to allow them to be used in new and old
implementations.</t>
<t>There is already work to extend the base QoS NSLP and GIST to
enable new QoS signaling scenarios. One such proposal is the
Inter-Domain Reservation Aggregation aiming to support large-scale
deployment of the QoS NSLP <xref
target="I-D.bless-nsis-resv-aggr"></xref>. Another current proposal
seeks to extend the whole NSIS framework towards path-decoupled
signaling and QoS reservations <xref
target="I-D.cordeiro-nsis-hypath"></xref>.</t>
</section>
<section anchor="model_ext" title="QoS Specifications">
<t>The QoS Specification template (QSpec) is defined in <xref
target="I-D.ietf-nsis-qspec"></xref>. This provides the language in
which the requirements of specific QoS models are described.
Introduction of new QoS models requires IETF action, with the
published document defining the specific elements within the QSpec
used in the new model. See <xref target="I-D.ietf-nsis-qspec"></xref>
for details.</t>
<t>The introduction of new QoS models is designed to enable deployment
of NSIS-based QoS control in specific scenarios. One such example is
the Integrated Services Controlled Load Service for NSIS <xref
target="I-D.kappler-nsis-qosmodel-controlledload"></xref>.</t>
<t>A key feature provided by defining the QSpec template is support of
a common language for describing QoS requirements and capabilities,
which can be reused by any QoS models intending to use the QoS NSLP to
signal their requirements for traffic flows. The commonality of the
QSpec parameters ensures a certain level of interoperability of QoS
models and reduces the demands on hardware that has to implement the
QoS control. Optional QSpec parameters support the extensibility of
the QoS NSLP to other QoS models in the future; new QSpec parameters
can be defined in the document that defines a new QoS model. See
Sections 4.4 and 7 of <xref target="I-D.ietf-nsis-qspec"></xref>.</t>
<t>The QSpec Template supports situations where the QoS parameters
need to be fine-grained, specifically targeted to an individual flow
in one part of the network (typically the edge or access part) but
might need to be more coarse-grained, where the flow is part of an
aggregate (typically in the core of the network).</t>
</section>
<section title="NAT/Firewall NSLP">
<t>The NAT/Firewall signaling can be extended broadly in the same way
as the QoS NSLP by defining new parameters to be carried in
NAT/Firewall NSLP messages. See Section 7 of <xref
target="I-D.ietf-nsis-nslp-natfw"></xref>. No proposals currently
exist to fulfill new use cases for the protocol.</t>
</section>
<section title="New NSLP protocols">
<t>Designing a new NSLP is both challenging and easy.</t>
<t>New signaling applications with associated NSLPs can be defined to
work in parallel or replace the applications already defined by the
NSIS working group. Applications that fit into the NSIS framework will
be expected to use GIST to provide transport of signaling messages and
appropriate security facilities which relieves the application
designer of many "lower level" problems. GIST provides many important
functions through its service layer API, and allows the signaling
application programmer to offload, e.g., the channel security,
transport characteristics and signaling node discovery to GIST.</t>
<t>Yet, on the other hand, the signaling application designer must
take into account that the network environment can be dynamic, both in
terms of routing and node availability. The new NSLP designer must
take into account at least the following issues:</t>
<t><list style="symbols">
<t>Routing changes, e.g., due to mobility: GIST sends Network
Notifications when something happens in the network, e.g., peers
or routing paths change. All signaling applications must be able
to handle these notifications and act appropriately. GIST does not
include logic to figure out what the NSLP would want to do due to
a certain network event. Therefore, GIST gives the notification to
the application, and lets it make the right decision.</t>
<t>GIST indications: GIST will also send other notifications,
e.g., if a signaling peer does not reply to refresh messages, or a
certain NSLP message was not successfully delivered to the
recipient. Again, NSLP applications must be able to handle these
events, too. Appendix B in the GIST specification discusses the
GIST-NSLP API and the various functionality required, but
implementing this interface can be quite challenging; the
multitude of asynchronous notifications than can from GIST
increases the implementation complexity of the NSLP.</t>
<t>Lifetime of the signaling flow: NSLPs should inform GIST when a
flow is no longer needed using the SetStateLifetime primitive.
This reduces bandwidth demands in the network.</t>
<t>NSLP IDs: NSLP messages may be multiplexed over GIST MAs. The
new NSLP needs to use a unique NSLPID to ensure that its messages
are delivered to the correct application by GIST. A single NSLP
could use multiple NSLPIDs, for example to distinguish different
classes of signaling nodes that might handle different levels of
aggregation of requests or alternative processing paths.</t>
<t>Source IP address: It is sometimes challenging to find out at
the NSLP, what will the source IP address be, especially when a
node has multiple interfaces. Moreover, the logic in specifying
the source IP address may differ if the node processing an NSLP
message is the source of the signaling flow, or an intermediate
node on the signaling. Thus, the NSLP must be able to find out the
right source IP address from its internal interfaces, and its
location on the signaling.</t>
<t>New MRMs: GIST defines currently two Message Routing Methods,
and leave the door open for new ideas. Thus, it is possible that a
new NSLP also requires a new MRM, path-decoupled routing being one
example.</t>
<t>Cooperation with other NSLPs: Some applications might need
resources from two or more different classes in order to operate
successfully. The NSLPs managing these resources could operate
cooperatively to ensure that such requests were coordinated to
avoid wasting signaling bandwidth and prevent race conditions.</t>
</list></t>
<t>The API between GIST and NSLPs (see Appendix B in <xref
target="I-D.ietf-nsis-ntlp"></xref>) is very important to understand.
The abstract design in the GIST specification does not specify the
exact messaging between GIST and the NSLPs but gives an understanding
of the interactions, especially what kinds of asynchronous
notifications from GIST the NSLP must be prepared to handle: the
actual interface will be dependent on each implementation of GIST.</t>
<t>Messages transmitted by GIST on behalf of an NSLP are identified by
a unique NSLP identifier (NSLPID). NSLPIDs are 16 bit unsigned numbers
taken from a registry managed by IANA and defined in Section 9 of the
GIST specification <xref target="I-D.ietf-nsis-ntlp"></xref>.</t>
<t>A range of values (32704-32767) is available for Private and
Experimental use during development, but any new signaling application
that expects to be deployed generally on the Internet needs to be
defined either in a standards track RFC or, possibly, an experimental
RFC. Such an RFC would request allocation of unique NSLPID value(s)
from the IANA registry. There is additional discussion of NSLPIDs in
Section 3.8 of the GIST specification.</t>
</section>
</section>
<section title="Security Considerations">
<t>This document provides information to the community. It does not
raise new security concerns.</t>
</section>
<section title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section title="Acknowledgements">
<t>This document combines work previously published as two separate
drafts: "What is Next Steps in Signaling anyway - A User's Guide to the
NSIS Protocol Family" written by Roland Bless and Jukka Manner, and
"NSIS Extensibility Model" written by John Loughney.</t>
<t>Max Laier, Nuutti Varis and Lauri Liuhto have provided reviews of
"User's Guide" draft and valuable input.</t>
<t>The "Extensibility Model" borrowed some ideas and some text from
<xref target="RFC3936">RFC3936</xref>, Procedures for Modifying the
Resource ReSerVation Protocol (RSVP); Robert Hancock provided text for
the original GIST section, since much modified and Claudia Keppler have
provided feedback on this draft, while Allison Mankin and Bob Braden
suggested that this draft be worked on.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc3726;
&rfc4080;
&rfc4081;
&ntlp;
&qosnslp;
&natfwnslp;
&qspec;
</references>
<references title="Informative References">
&twolevel;
&rfc1633;
&rfc2205;
&rfc4094;
&rfc3692;
&rfc3936;
&nsisauth;
&gistpio;
&gistdccp;
&cl;
&resvaggr;
&hypath;
&raobad;
&estmrm;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 02:53:26 |