One document matched: draft-ietf-nsis-ext-06.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 rfc5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.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 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 raouse SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hancock-nsis-gist-rao.xml">
<!ENTITY estmrm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bless-nsis-est-mrm.xml">
<!ENTITY sctp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nsis-ntlp-sctp.xml">
]>
<rfc category="info" docName="draft-ietf-nsis-ext-06.txt" ipr="trust200902">
<?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="KIT">Institute of Telematics, Karlsruhe Institute
of Technology (KIT)</organization>
<address>
<postal>
<street>Zirkel 2, Building 20.20</street>
<city>Karlsruhe</city>
<code>76131</code>
<country>Germany</country>
</postal>
<phone>+49 721 608 6413</phone>
<email>bless@kit.edu</email>
<uri>http://tm.kit.edu/~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>
<email>elwynd@folly.org.uk</email>
<uri>http://www.folly.org.uk</uri>
</address>
</author>
<date month="March" year="2010" />
<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-2009 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">
<t>The Next Steps in Signaling (NSIS) Working Group was formed in
November 2001 to develop an Internet signaling protocol suite that would
attempt to remedy some of the perceived shortcomings of solutions based
on the Resource ReSerVation Protocol (RSVP), e.g., with respect to
mobility and Quality of Service (QoS) interoperability. The initial
charter was focused on QoS signaling as the first use case, taking as
the background for the work RSVP. 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
application 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 the NSIS framework and protocol
suite is at the time of writing (2009), providing an introduction to the
use cases for which the current version of NSIS was designed, notes on
how to deploy NSIS in existing networks and summarizing 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 protocol 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 with transporting NSLP messages hop-by-hop
between pairs of signaling nodes, 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. The current protocols have features to
confine the signaling to a limited part of the path (such as the
interior of a domain). 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 specified: one concerning Quality
of Service signaling <xref target="I-D.ietf-nsis-qos-nslp"></xref>and
one to enable NAT/Firewall traversal <xref
target="I-D.ietf-nsis-nslp-natfw"></xref>.</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; the state installed should facilitate
or enhance some characteristic of the data flow. This is typically
achieved by routing signaling messages along the same path (known as
"path-coupled signaling") and intercepting the signaling message at NSIS
capable nodes. However, the NSIS architecture is designed to be
flexible, and the routing of signaling messages is controlled by the
Message Routing Method (MRM) that is applied to the signaling messages.
The initial specifications define two MRMs:<list style="symbols">
<t>the basic Path-Coupled MRM designed to drive signaling along the
path that will be followed by the data flow, and</t>
<t>an alternative Loose End MRM which is applicable for
preconditioning the state in firewalls and Network Address
Translation (NAT) middleboxes when data flow destinations lie behind
this sort of middlebox. Without preconditioning these middleboxes
will generally reject signaling messages originating outside the
region 'protected' by the middlebox and where the destination is
located.</t>
</list></t>
<t>Parameters carried by each 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 capable 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 in all
the NSLPs. 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 in the NSLP(s), especially the MRI.</t>
<t>At the NTLP (GIST) layer 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. Changes of routing or dynamic IP address
changes, e.g., due to mobility, will require GIST to modify the
Messaging Associations (MAs) that are used to channel NSLP messages
between adjacent GIST peers in order to satisfy the NSLP MRI for each
SID.</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>Initial focus on MRMs for path-coupled signaling: 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
or other off-path resource manager. 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, 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></t>
<t>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 transport attributes for the signaling flow, e.g.,
unreliable or reliable, and GIST then chooses the most appropriate
transport protocol(s) to achieve the goals of the flow. GIST will
normally use UDP if unreliable signaling is adequate, TCP if reliability
is required and TLS over TCP for secure (and reliable) signaling flows
but there extensibility provisions within GIST that will allow
alternatives to be specified in future. 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 | DTLS | Security Support*
+------------+-------------+
| TCP | SCTP | UDP | DCCP | Transport Protocol*
+--------------------------+
+--------------------------+
| IPsec |
+--------------------------+
+--------------------------+
| IPv4 | IPv6 |
+--------------------------+
]]></artwork>
<postamble>* The Security Support and Transport Protocol layers show
some possible protocols that could be used to transport NSIS messages.
To provide authentication and/or integrity protection support the
transport protocol has to be paired with a suitable security
mechanism, e.g., TCP with TLS or DCCP with DTLS.</postamble>
</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 towards a flow
endpoint, 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 for a potential 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. GIST places a
Router Alert Option (RAO) in Query message packets to ensure that they
are intercepted by relevant 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>. Additionally
evidence was discovered indicating that several existing implementations
of RAO were inconsistent with the (intention of 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. Eventually it was decided that NSIS would continue
to specify RAO as its primary means for triggering interception of
signaling messages in intermediate nodes on the data path, but the
protocol suite would be published with Experimental status rather than
on the Standards Track while deployment experience was gathered. More
information about the use of RAO in GIST can be found in <xref
target="I-D.hancock-nsis-gist-rao"></xref>. Also the deployment issues
that arise from the use of RAO are discussed in <xref
target="rao_deployment"></xref>.</t>
<t>Alternative mechanisms have been considered to allow nodes to
recognize NSIS signaling packets that should be intercepted. For example
NSIS nodes could recognize UDP packets directed to a specific
destination port as Query messages that need to be intercepted even
though they are not addressed to the intercepting node. GIST provides
for the use of such alternatives as a part of its extensibility design.
NSIS recognizes that the workload imposed by intercepting signaling
packets could be considerable relative to the work needed just to
forward such packets. To keep the necessary load to a minimum NSIS
provides mechanisms to limit the number of interceptions needed by
constraining the rate of generation and allowing for intentional
bypassing of signaling nodes that are not affected by particular
signaling requests. This 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 signaling transport layer, and is
maintained separately. NSLPs control the lifetime of the state in the
signaling 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 next hop peers if the
signaling flows require the same transport attributes.</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 when using UDP, and
especially for Query mode messages. 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 or other off-path resource managers 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) 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. A template for QSpec objects is defined
in <xref target="I-D.ietf-nsis-qspec"></xref>. This provides a number of
basic parameter objects that can be used as a common language to specify
components of concrete QoS models. The objects defined in <xref
target="I-D.ietf-nsis-qspec"></xref> provide the building blocks for
many existing QoS models such as those associated with RSVP and
Differentiated Services. The extensibility of the template allows new
QoS model specifications to extend the template language as necessary to
support these specifications.</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) that 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></t>
<t>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>
<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 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 signaled
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">
<t>The initial version of the NSIS protocol suite is being published
with the status of Experimental Protocols in order to gain deployment
experience. Concerns over the security, implementation and
administrative issues surrounding the use of RAO are likely to mean that
initial deployments occur in 'walled gardens' where the characteristics
of hardware in use are well known and there is a high level of trust and
control over the end nodes that use the protocols. This section
addresses issues that need to be considered in a deployment of the NSIS
protocol suite.</t>
<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>. There are a number of
obstacles that may be encountered due to broken implementations of RAO
(see <xref target="rao_deployment"></xref>) and firewalls or NATs
dropping NSIS signaling packets (see <xref
target="filtering"></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 anchor="rao_deployment"
title="Deployment Issues Due to Use of RAO">
<t>The standardized version of GIST depends on routers and other
middleboxes correctly recognizing and acting on packets containing
RAO. There are a number of problems related to RAO that can obstruct a
deployment of NSIS:<list style="symbols">
<t>Some implementations do not respond to RAO at all.</t>
<t>Some implementations respond but do not distinguish between the
RAO parameter values in IP version 4 (IPv4) packets or reject
anything except 0 (in which case only the value 0 can be used)</t>
<t>The response to RAO in a GIST Query mode packet, which is sent
using the UDP transport, is to dispatch the packet to the UDP
stack in the intercepting node rather than a function associated
with the RAO parameter. Since the node will not normally have a
normal UDP receiver for these packets they are dropped</t>
<t>The major security concern with RAO in NSIS is that it provides
a new vector for hosts to mount a (Distributed) Denial of Service
(DDOS) attack on the control plane of routers on the data path.
Such attacks have occurred and it is therefore normal for service
providers to prohibit "host-to-router" signaling packets such as
RSVP or NSIS from entering their networks from customer networks.
This will tend to limit the deployment of NSIS to "walled gardens"
unless a suitable mitigation of the DDOS threat can be found and
deployed.</t>
</list></t>
<t>In order to deploy NSIS effectively routers and other hardware
needs to be selected and correctly configured to respond to RAO and
dispatch intercepted packets to the NSIS function.</t>
<t>A further obstacle results from likelihood that IPv4 packets with
IP options of any kind will be filtered and dropped by firewalls and
NATs. In many cases this is the default behavior so that explicit
configuration is needed to allow packets carrying the RAO to pass
through. The general inclination of domain administrators is to deny
access to packets carrying IP options because of the security risks
and the additional load on the routers in the domain. The situation
with IPv6 may be easier as the RAO option in IPv6 is better defined
but the security concerns remain.</t>
<t>Deployment issues are discussed at more length in Appendix C of the
GIST specification <xref target="I-D.ietf-nsis-ntlp"></xref>.</t>
</section>
<section anchor="filtering"
title="Deployment Issues with NATs and Firewalls">
<t>NAT gateways and firewalls may also hinder initial deployment of
NSIS protocols for several reasons:<list style="symbols">
<t>They may filter and drop signaling traffic as described in
<xref target="rao_deployment"></xref> to deny access to packets
containing IP options.</t>
<t>They may not permit "unsolicited" incoming GIST Query mode
packets. This behavior has been anticipated in the design of the
protocols but requires additional support to ensure that the
middleboxes are primed to accept the incoming queries (see <xref
target="I-D.ietf-nsis-qos-nslp"></xref> and <xref
target="I-D.ietf-nsis-nslp-natfw"></xref>).</t>
<t>NATs that are not aware of the NSIS protocols will generally
perform address translations that are not coordinated with the
NSIS protocols. Since NSIS signaling messages may be carrying
embedded IP addresses affected by these translations, it may not
be possible to operate NSIS through such legacy NATs. The
situation and workarounds are discussed in Section 7.2.1 of <xref
target="I-D.ietf-nsis-ntlp"></xref>.</t>
</list></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 anchor="security" title="Security Features">
<t>Basic security functions are provided at the GIST layer, e.g.,
protection against some blind or denial-of-service attacks, but note
that introduction of alternative MRMs may provide attack avenues that
are not present with the current emphasis on the path-coupled MRM.
Conceptually it is difficult to protect against on-path attacker and
man-in-the-middle attacks when using path-coupled MRMs, 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 authorization 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"></xref> describes a two-layer framework for signaling
on the Internet, comprising a generic transport layer with specific
signaling layer protocols 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 its signaling
messages 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 <xref target="RFC5226"></xref>),
"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>In addition to registered code points, all NSIS protocols provide
code points that can be used for experimentation, usually within
closed networks, as explained in <xref target="RFC3692"></xref>. 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 covered in the subsections
below. In these subsections, references to document sections refer to
the GIST specification <xref target="I-D.ietf-nsis-ntlp"></xref>. The
bullet points at the end of each subsection specify the formal
administrative actions that would need to carried out when a new
extension is standardized.</t>
<t>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.
However 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 title="Use of Different Message Routing Methods">
<t>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><list style="symbols">
<t>New MRMs require allocation of a new MRM-ID either by IETF
review of a specification or expert review <xref
target="I-D.ietf-nsis-ntlp"></xref>.</t>
</list></t>
</section>
<section title="Use of Different Transport Protocols or Security Capabilities">
<t>The initial handshake between GIST peers allows a negotiation of
the transport protocols to be used. Currently, proposals exist to
add the Datagram Congestion Control Protocol (DCCP) <xref
target="I-D.manner-nsis-gist-dccp"></xref> and the Stream Control
Transport Protocol (SCTP) <xref
target="I-D.ietf-nsis-ntlp-sctp"></xref> transports to GIST, in each
case using Datagram TLS (DTLS) to provide security. 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><list style="symbols">
<t>Use of an alternative transport protocol or security
capability requires allocation of a new MA-Protocol-ID either by
IETF review of a specification or expert review <xref
target="I-D.ietf-nsis-ntlp"></xref>.</t>
</list></t>
</section>
<section title="Use of Alternative Security Services">
<t>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><list style="symbols">
<t>Use of an alternative security service requires allocation of
a new MA-Protocol-ID either by IETF review of a specification or
expert review <xref target="I-D.ietf-nsis-ntlp"></xref>.</t>
</list></t>
</section>
<section title="Query Mode Packet Interception Schemes">
<t>GIST has standardized a scheme using RAO mechanisms<xref
target="I-D.hancock-nsis-gist-rao"></xref> with UDP packets. If the
difficulties of deploying the RAO scheme prove insuperable in
particular circumstances, alternative interception schemes can be
specified. One proposal that was explored for GIST used UDP port
recognition in routers rather than RAO mechanisms to drive the
interception of packets. See Sections 5.3.2 and 5.3.2.5. Each NSLP
needs to specify membership of an "interception class" whenever it
sends a message through GIST. A packet interception scheme can
support one or more interception classes. In principle, a GIST
instance can support multiple packet interception schemes, but each
interception class needs to be associated with exactly one
interception scheme in a GIST instance and GIST instances that use
different packet interception schemes for the same interception
class will not be interoperable.</t>
<t>Defining an alternative interception class mechanism for
incorporation into GIST should be considered as a very radical step
and all alternatives should be considered before taking this path.
The main reason for this is that the mechanism will necessarily
require additional operations on every packet passing through the
affected router interfaces. A number of considerations should be
taken into account:<list style="symbols">
<t>Although the interception mechanism need only be deployed on
routers that actually need it (probably for a new NSLP),
deployment may be constrained if the mechanism requires
modification to the hardware of relevant routers and/or needs to
await modification of the software by the router vendor.</t>
<t>Any packet fields to be examined should be normally close to
the start of the packet so that additional memory accesses are
not needed to retrieve the values needed for examination.</t>
<t>The logic required to determine if a packet should be
intercepted needs to be kept simple to minimise the extra
per-packet processing.</t>
<t>The mechanism should be applicable to both IPv4 and IPv6
packets.</t>
<t>Packet interception mechanisms potentially provide an attack
path for Denial of Service attacks on routers, in that packets
are diverted into the "slow path" and hence can significantly
increase the load on the general processing capability of the
router. Any new interception mechanism needs to be carefully
designed to minimize the attack surface.</t>
</list></t>
<t>Packet interception mechanisms are identified by an "interception
class" which is supplied to GIST through the Application Programming
Interface for each message sent.</t>
<t><list style="symbols">
<t>New packet interception mechanisms will generally require
allocation of one or more new Interception-class-IDs. This does
not necessarily need to be placed in an IANA registry as it is
primarily used as a parameter in the API between the NSLPs and
GIST and may never appear on the wire, depending on the
mechanism employed; all that is required is consistent
interpretation between the NSLPs and GIST in each applicable
node. However, if, as is the case with the current RAO mechanism
<xref target="I-D.hancock-nsis-gist-rao"></xref>, the scheme
distinguishes between multiple packet interception classes by a
value carried on the wire (different values of RAO parameter for
the RAO mechanism in GIST), an IANA registry may be required to
provide a mapping between interception classes and on-the-wire
values as discussed in Section 6 of <xref
target="I-D.hancock-nsis-gist-rao"></xref>.</t>
</list></t>
</section>
<section title="Use of Alternative NAT Traversal Mechanisms">
<t>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. As discussed above, extension of NAT traversal may be
needed if a new MRM is deployed. 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>
</section>
<section title="Additional Error Identifiers">
<t>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><list style="symbols">
<t>Additional error identifiers require allocation of new error
code(s) and/or subcode(s), and may also require allocation of
Additional Information types. These are all allocated on a
first-come, first-served basis by IANA <xref
target="I-D.ietf-nsis-ntlp"></xref>.</t>
</list></t>
</section>
<section title="Defining New Objects to be Carried in GIST">
<t>The AB-flags in each signaling object carried in NSIS protocols
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>
<t><list style="symbols">
<t>New objects require allocation of a new Object Type ID either
by IETF review of a specification or through another acceptable
published specification <xref
target="I-D.ietf-nsis-ntlp"></xref>.</t>
</list></t>
</section>
<section title="Adding New Message Types">
<t>Major modifications could be made by adding additional GIST
message types and defining appropriate processing. It might be
necessary to define this as a new version of the protocol. A field
is provided in the GIST Common Header containing the version number.
GIST currently has no provision for version or capability
negotiation that might be needed if a new version was defined.</t>
<t><list style="symbols">
<t>New GIST Message Types require allocation of a new GIST
Message Type ID either by IETF review of a specification or
expert review <xref target="I-D.ietf-nsis-ntlp"></xref>.</t>
</list></t>
</section>
</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 a new QoS model involves defining a new QSpec. In
order to have a new QSpec allocated by IANA there must an acceptable
published specification that defines 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 consists of a QSpec version number, QSpec objects plus
specification of processing and procedures that can be used to build
many QoS models. The definition of a QSpec can be revised without
necessarily changing the version if the changes are functionally
backwards compatible. If changes are made that are not backwards
compatible then a new QSpec version number has to be assigned. Note
that a new QSpec version number is not needed just because new
additional QSpec parameters are specified; new versions will be needed
only if the existing functionality is modified. The template includes
version negotiation procedures that allow the originator of an NSLP
message to retry with a lower QSpec version if the receiver rejects a
message because it does not support the QSpec version signaled in the
message. See Section 3.2 of <xref
target="I-D.ietf-nsis-qspec"></xref>.</t>
<t><list style="symbols">
<t>Creation of a new, incompatible version of an existing QSpec
requires allocation of a new QSpec version number that is
documented in a permanent and readily available public
specification. See <xref
target="I-D.ietf-nsis-qspec"></xref>.<vspace blankLines="1" /></t>
<t>Completely new QSpecs can also be created. Such new QSpecs
require allocation of a QSpec type that is documented in a
permanent and readily available public specification. Values are
also available for local or experimental use during development.
See <xref target="I-D.ietf-nsis-qspec"></xref>.<vspace
blankLines="1" /></t>
<t>Additional QSpec procedures can be defined requiring allocation
of a new QSpec procedure number that is documented in a permanent
and readily available public specification. Values are also
available for local or experimental use during development. See
<xref target="I-D.ietf-nsis-qspec"></xref>.<vspace
blankLines="1" /></t>
<t>Additional QSpec parameters and associated error codes can be
defined requiring a permanent and readily available public
specification document. Values are also available for local or
experimental use during development. See <xref
target="I-D.ietf-nsis-qspec"></xref>.</t>
</list></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 the API that it exposes to the signaling application
layer code, 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.<vspace
blankLines="1" /></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. NSLP applications must also be able to handle these
events. 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 that can arrive from GIST
increases the implementation complexity of the NSLP.<vspace
blankLines="1" /></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.<vspace
blankLines="1" /></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. Note that
unlike GIST, the NSLPs do not provide a protocol versioning
mechanism. If the new NSLP is an upgraded version of an existing
NSLP, then it should be distinguished by a different
NSLPID.<vspace blankLines="1" /> <list style="symbols">
<t>A new generally available NSLP requires IESG approval for
the allocation of a new NSLP ID <xref
target="I-D.ietf-nsis-ntlp"></xref><vspace
blankLines="1" /></t>
</list></t>
<t>Incremental deployment: It would generally be unrealistic to
expect every node on the signaling path to have a new NSLP
implemented immediately. New NSLPs need to allow for this. The QoS
and NATFW NSLPs provide examples of techniques such as proxy modes
that cater for cases where the data flow originator and/or
receiver does not implement the NSLP.</t>
<t>Signaling Message Source IP Address: It is sometimes
challenging for an NSLP originating a signaling message to
determine the source IP address that should be used in the
signaling messages, which may be different from the data flow
source address used in the MRI. This challenge occurs either when
a node has multiple interfaces or is acting as a proxy for the
data flow originator (typically expected to occur during the
introduction of NSIS when not all nodes are NSIS enabled). A proxy
signaling flow originator generally needs to know and use the
correct data flow source IP address at least initially. As
discussed in Section 5.8.1.2 of <xref
target="I-D.ietf-nsis-ntlp"></xref>, the signaling flow originator
may choose to alter the source IP address after the initial Query
message has established the flow path in order that ICMP messages
are directed to the most appropriate node; in the proxy case, the
data flow originator would be unaware of the signaling flow and
ICMP messages relating to the signaling would be meaningless if
passed on to the data flow originator. Hence it is essential that
an NSLP is aware of the position and role of the node on which it
is instantiated, and has means of determining the appropriate
source address to be used and ensuring that this is used on
signaling packets. <vspace blankLines="0" /></t>
<t>New MRMs: GIST currently defines 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.<vspace blankLines="1" /></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>It is essential that the security considerations of a new NSLP are
carefully analyzed. NSIS NSLPs are deployed in routers as well as host
systems; a poorly designed NSLP could therefore provide an attack
vector for network resources as well as end systems. The NSLP must
also support authorization of users and must allow the use of the GIST
authentication and integrity protection mechanisms where users deem
them to be necessary.</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
itself raise new security concerns.</t>
<t>However, any extensions that are made to the NSIS protocol suite will
need to be carefully assessed for any security implications. This is
particularly important because NSIS messages are intended to be actively
processed by NSIS-capable routers that they pass through, rather than
simply forwarded as is the case with most IP packets. It is essential
that extensions provide means to authorize usage of capabilities that
might allocate resources and recommend the use of appropriate
authentication and integrity protection measures in order to exclude or
adequately mitigate any security issues that are identified.</t>
<t>GIST offers facilities to authenticate NSIS messages and to ensure
that they are delivered reliably. Extensions must allow these
capabilities to be used in an appropriate manner to minimize the risks
of NSIS messages being misused, and must recommend their appropriate
usage.</t>
<t>If additional transport protocols are proposed for use in association
with GIST, an appropriate set of compatible security functions must be
made available in conjunction with the transport protocol to support the
authentication and integrity functions expected to be available through
GIST.</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. Teemu Huovila also provided
valuable input on the later versions.</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;
&rfc5226;
&ntlp;
&qosnslp;
&natfwnslp;
<reference anchor="I-D.ietf-nsis-qspec">
<front>
<title>QoS NSLP QSPEC Template</title>
<author fullname="Gerry Ash" initials="G" surname="Ash">
<organization></organization>
</author>
<author fullname="Attila Bader" initials="A" surname="Bader">
<organization></organization>
</author>
<author fullname="Cornelia Kappler" initials="C" surname="Kappler">
<organization></organization>
</author>
<author fullname="David Oran" initials="D" surname="Oran">
<organization></organization>
</author>
<date day="29" month="November" year="2008" />
<abstract>
<t>The QoS NSLP protocol is used to signal QoS reservations and is
independent of a specific QoS model (QOSM) such as IntServ or
DiffServ. Rather, all information specific to a QOSM is
encapsulated in a separate object, the QSPEC. This document
defines a template for the QSPEC including a number of QSPEC
parameters. The QSPEC parameters provide a common language to be
re-used in several QOSMs and thereby aim to ensure the
extensibility and interoperability of QoS NSLP. The node
initiating the NSIS signaling adds an initiator QSPEC, which
indicates the QSPEC parameters that must be interpreted by the
downstream nodes less the reservation fails, thereby ensuring the
intention of the NSIS initiator is preserved along the signaling
path.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-nsis-qspec-21" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-21.txt"
type="TXT" />
</reference>
</references>
<references title="Informative References">
&twolevel;
&rfc1633;
&rfc2205;
&rfc4094;
&rfc3692;
&rfc3936;
&nsisauth;
&gistpio;
&gistdccp;
&cl;
&resvaggr;
&hypath;
&raobad;
&raouse;
&estmrm;
&sctp;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-22 19:51:40 |