< draft-ietf-nsis-ext-06.txt   draft-ietf-nsis-ext-07.txt >
Network Working Group J. Manner Network Working Group J. Manner
Internet-Draft TKK Internet-Draft TKK
Intended status: Informational R. Bless Intended status: Informational R. Bless
Expires: September 9, 2010 KIT Expires: October 15, 2010 KIT
J. Loughney J. Loughney
Nokia Nokia
E B. Davies, Ed. E B. Davies, Ed.
Folly Consulting Folly Consulting
March 8, 2010 April 13, 2010
Using and Extending the NSIS Protocol Family Using and Extending the NSIS Protocol Family
draft-ietf-nsis-ext-06.txt draft-ietf-nsis-ext-07.txt
Abstract Abstract
This document gives an overview of the Next Steps in Signaling (NSIS) This document gives an overview of the Next Steps in Signaling (NSIS)
framework and protocol suite created by the NSIS working group during framework and protocol suite created by the NSIS working group during
the period 2001-2009 together with suggestions on how the industry the period 2001-2009 together with suggestions on how the industry
can make use of the new protocols, and how the community can exploit can make use of the new protocols, and how the community can exploit
the extensibility of both the framework and existing protocols to the extensibility of both the framework and existing protocols to
address future signaling needs. address future signaling needs.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 15, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The NSIS Architecture . . . . . . . . . . . . . . . . . . . . 4 2. The NSIS Architecture . . . . . . . . . . . . . . . . . . . . 3
3. The General Internet Signaling Transport . . . . . . . . . . . 7 3. The General Internet Signaling Transport . . . . . . . . . . . 6
4. Quality of Service NSLP . . . . . . . . . . . . . . . . . . . 11 4. Quality of Service NSLP . . . . . . . . . . . . . . . . . . . 10
5. NAT/Firewall Traversal NSLP . . . . . . . . . . . . . . . . . 13 5. NAT/Firewall Traversal NSLP . . . . . . . . . . . . . . . . . 12
6. Deploying the Protocols . . . . . . . . . . . . . . . . . . . 14 6. Deploying the Protocols . . . . . . . . . . . . . . . . . . . 13
6.1. Deployment Issues Due to Use of RAO . . . . . . . . . . . 15 6.1. Deployment Issues Due to Use of RAO . . . . . . . . . . . 14
6.2. Deployment Issues with NATs and Firewalls . . . . . . . . 15 6.2. Deployment Issues with NATs and Firewalls . . . . . . . . 15
6.3. Incremental Deployment and Workarounds . . . . . . . . . . 16 6.3. Incremental Deployment and Workarounds . . . . . . . . . . 15
7. Security Features . . . . . . . . . . . . . . . . . . . . . . 16 7. Security Features . . . . . . . . . . . . . . . . . . . . . . 15
8. Extending the Protocols . . . . . . . . . . . . . . . . . . . 17 8. Extending the Protocols . . . . . . . . . . . . . . . . . . . 16
8.1. Overview of Administrative Actions Needed When 8.1. Overview of Administrative Actions Needed When
Extending NSIS . . . . . . . . . . . . . . . . . . . . . . 18 Extending NSIS . . . . . . . . . . . . . . . . . . . . . . 17
8.2. GIST . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. GIST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2.1. Use of Different Message Routing Methods . . . . . . . 18 8.2.1. Use of Different Message Routing Methods . . . . . . . 17
8.2.2. Use of Different Transport Protocols or Security 8.2.2. Use of Different Transport Protocols or Security
Capabilities . . . . . . . . . . . . . . . . . . . . . 19 Capabilities . . . . . . . . . . . . . . . . . . . . . 18
8.2.3. Use of Alternative Security Services . . . . . . . . . 19 8.2.3. Use of Alternative Security Services . . . . . . . . . 18
8.2.4. Query Mode Packet Interception Schemes . . . . . . . . 19 8.2.4. Query Mode Packet Interception Schemes . . . . . . . . 18
8.2.5. Use of Alternative NAT Traversal Mechanisms . . . . . 21 8.2.5. Use of Alternative NAT Traversal Mechanisms . . . . . 20
8.2.6. Additional Error Identifiers . . . . . . . . . . . . . 21 8.2.6. Additional Error Identifiers . . . . . . . . . . . . . 20
8.2.7. Defining New Objects to be Carried in GIST . . . . . . 21 8.2.7. Defining New Objects to be Carried in GIST . . . . . . 20
8.2.8. Adding New Message Types . . . . . . . . . . . . . . . 21 8.2.8. Adding New Message Types . . . . . . . . . . . . . . . 21
8.3. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.3. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.4. QoS Specifications . . . . . . . . . . . . . . . . . . . . 22 8.4. QoS Specifications . . . . . . . . . . . . . . . . . . . . 21
8.5. NAT/Firewall NSLP . . . . . . . . . . . . . . . . . . . . 23 8.5. NAT/Firewall NSLP . . . . . . . . . . . . . . . . . . . . 23
8.6. New NSLP Protocols . . . . . . . . . . . . . . . . . . . . 24 8.6. New NSLP Protocols . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The Next Steps in Signaling (NSIS) Working Group was formed in The Next Steps in Signaling (NSIS) Working Group was formed in
November 2001 to develop an Internet signaling protocol suite that November 2001 to develop an Internet signaling protocol suite that
would attempt to remedy some of the perceived shortcomings of would attempt to remedy some of the perceived shortcomings of
solutions based on the Resource ReSerVation Protocol (RSVP), e.g., solutions based on the Resource ReSerVation Protocol (RSVP), e.g.,
with respect to mobility and Quality of Service (QoS) with respect to mobility and Quality of Service (QoS)
interoperability. The initial charter was focused on QoS signaling interoperability. The initial charter was focused on QoS signaling
as the first use case, taking as the background for the work RSVP. as the first use case, taking as the background for the work RSVP.
skipping to change at page 4, line 26 skipping to change at page 3, line 26
are documented in [RFC3726] and an analysis of existing signaling are documented in [RFC3726] and an analysis of existing signaling
protocols can be found in [RFC4094]. protocols can be found in [RFC4094].
The design of NSIS is based on a two-layer model, where a general The design of NSIS is based on a two-layer model, where a general
signaling transport layer provides services to an upper signaling signaling transport layer provides services to an upper signaling
application layer. The design was influenced by Bob Braden's application layer. The design was influenced by Bob Braden's
Internet Draft entitled "A Two-Level Architecture for Internet Internet Draft entitled "A Two-Level Architecture for Internet
Signaling" [I-D.braden-2level-signal-arch]. Signaling" [I-D.braden-2level-signal-arch].
This document gives an overview of the NSIS framework and protocol This document gives an overview of the NSIS framework and protocol
suite is at the time of writing (2009), providing an introduction to suite at the time of writing (2009), providing an introduction to the
the use cases for which the current version of NSIS was designed, use cases for which the current version of NSIS was designed, notes
notes on how to deploy NSIS in existing networks and summarizing how on how to deploy NSIS in existing networks and summarizing how the
the protocol suite can be enhanced to satisfy new use cases. protocol suite can be enhanced to satisfy new use cases.
2. The NSIS Architecture 2. The NSIS Architecture
The design of the NSIS protocol suite reuses ideas and concepts from The design of the NSIS protocol suite reuses ideas and concepts from
RSVP but essentially divides the functionality into two layers. The RSVP but essentially divides the functionality into two layers. The
lower layer, the NSIS Transport Layer Protocol (NTLP), is in charge lower layer, the NSIS Transport Layer Protocol (NTLP), is in charge
of transporting the higher layer protocol messages to the next of transporting the higher layer protocol messages to the next
signaling node on the path. This includes discovery of the next hop signaling node on the path. This includes discovery of the next hop
NSIS node, which may not be the next routing hop, and different NSIS node, which may not be the next routing hop, and different
transport and security services depending on the signaling transport and security services depending on the signaling
skipping to change at page 13, line 6 skipping to change at page 12, line 6
between different domains and QoS models. between different domains and QoS models.
In short, the functionality of the QoS NSLP includes: In short, the functionality of the QoS NSLP includes:
o Conveying resource requests for unicast flows o Conveying resource requests for unicast flows
o Resource requests (QSpec) that are decoupled from the signaling o Resource requests (QSpec) that are decoupled from the signaling
protocol (QoS NSLP) protocol (QoS NSLP)
o Sender- and receiver-initiated reservations, as well as, bi- o Sender- and receiver-initiated reservations, as well as, bi-
directional directional
o Soft-state and reduced refresh (keep-alive) signaling o Soft-state and reduced refresh (keep-alive) signaling
o Session binding, session X can be valid only if session Y is too o Session binding, session X can be valid only if session Y is also
valid
o Message scoping, end-to-end, edge-to-edge or end-to-edge (proxy o Message scoping, end-to-end, edge-to-edge or end-to-edge (proxy
mode) mode)
o Protection against message re-ordering and duplication o Protection against message re-ordering and duplication
o Group tear, tearing down several session with a single message o Group tear, tearing down several session with a single message
o Support for re-routing, e.g., due to mobility o Support for re-routing, e.g., due to mobility
o Support for request priorities and preemption o Support for request priorities and preemption
o Stateful and stateless nodes: stateless operation is particularly o Stateful and stateless nodes: stateless operation is particularly
relevant in core networks where large amounts of QoS state could relevant in core networks where large amounts of QoS state could
easily overwhelm a node easily overwhelm a node
o Reservation aggregation o Reservation aggregation
skipping to change at page 18, line 26 skipping to change at page 17, line 29
[I-D.ietf-nsis-ntlp]. [I-D.ietf-nsis-ntlp].
In addition to registered code points, all NSIS protocols provide In addition to registered code points, all NSIS protocols provide
code points that can be used for experimentation, usually within code points that can be used for experimentation, usually within
closed networks, as explained in [RFC3692]. There is no guarantee closed networks, as explained in [RFC3692]. There is no guarantee
that independent experiments will not be using the same code point! that independent experiments will not be using the same code point!
8.2. GIST 8.2. GIST
GIST is extensible in several aspects covered in the subsections GIST is extensible in several aspects covered in the subsections
below. In these subsections, references to document sections refer below. In these subsections, there are references to document
to the GIST specification [I-D.ietf-nsis-ntlp]. The bullet points at sections in the GIST specification [I-D.ietf-nsis-ntlp] where more
the end of each subsection specify the formal administrative actions information can be found. The bullet points at the end of each
that would need to carried out when a new extension is standardized. subsection specify the formal administrative actions that would need
to carried out when a new extension is standardized.
More generally, as asserted in Section 1 of the GIST specification, More generally, as asserted in Section 1 of the GIST specification,
the GIST design could be extended to cater for multicast flows and 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 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 flow. However it is not clear whether this could be done in a
totally backwards compatible way, and is not considered within the totally backwards compatible way, and is not considered within the
extensibility model of NSIS. extensibility model of NSIS.
8.2.1. Use of Different Message Routing Methods 8.2.1. Use of Different Message Routing Methods
Currently only two message routing methods are supported (Path- Currently only two message routing methods are supported (Path-
coupled MRM and Loose-End MRM), but further MRMs may be defined in coupled MRM and Loose-End MRM), but further MRMs may be defined in
the future. See Section 3.8. One possible additional MRM under the future. See Sections 3.3 and 5.8 of the GIST specification
development is documented in [I-D.bless-nsis-est-mrm]. This MRM [I-D.ietf-nsis-ntlp]. One possible additional MRM under development
would direct signaling towards an explicit target address other than is documented in [I-D.bless-nsis-est-mrm]. This MRM would direct
the (current) data flow destination and is intended to assist setting signaling towards an explicit target address other than the (current)
up of state on a new path during "make-before-break" handover data flow destination and is intended to assist setting up of state
sequences in mobile operations. Note that alternative routing on a new path during "make-before-break" handover sequences in mobile
methods may require modifications to the firewall traversal operations. Note that alternative routing methods may require
techniques used by GIST and NSLPs. modifications to the firewall traversal techniques used by GIST and
NSLPs.
o New MRMs require allocation of a new MRM-ID either by IETF review o New MRMs require allocation of a new MRM-ID either by IETF review
of a specification or expert review [I-D.ietf-nsis-ntlp]. of a specification or expert review [I-D.ietf-nsis-ntlp].
8.2.2. Use of Different Transport Protocols or Security Capabilities 8.2.2. Use of Different Transport Protocols or Security Capabilities
The initial handshake between GIST peers allows a negotiation of the The initial handshake between GIST peers allows a negotiation of the
transport protocols to be used. Currently, proposals exist to add transport protocols to be used. Currently, proposals exist to add
the Datagram Congestion Control Protocol (DCCP) the Datagram Congestion Control Protocol (DCCP)
[I-D.manner-nsis-gist-dccp] and the Stream Control Transport Protocol [I-D.manner-nsis-gist-dccp] and the Stream Control Transport Protocol
(SCTP) [I-D.ietf-nsis-ntlp-sctp] transports to GIST, in each case (SCTP) [I-D.ietf-nsis-ntlp-sctp] transports to GIST, in each case
using Datagram TLS (DTLS) to provide security. See Sections 3.2 and using Datagram TLS (DTLS) to provide security. See Sections 3.2 and
5.7. GIST expects alternative capabilities to be treated as 5.7 of the GIST specification [I-D.ietf-nsis-ntlp]. GIST expects
selection of an alternative protocol stack. Within the protocol alternative capabilities to be treated as selection of an alternative
stack, the individual protocols used are specified by MA Protocol IDs protocol stack. Within the protocol stack, the individual protocols
which are allocated from an IANA registry if new protocols are to be used are specified by MA Protocol IDs which are allocated from an
used. See Sections 5.7 and 9. IANA registry if new protocols are to be used. See Sections 5.7 and
9 of the GIST specification [I-D.ietf-nsis-ntlp].
o Use of an alternative transport protocol or security capability o Use of an alternative transport protocol or security capability
requires allocation of a new MA-Protocol-ID either by IETF review requires allocation of a new MA-Protocol-ID either by IETF review
of a specification or expert review [I-D.ietf-nsis-ntlp]. of a specification or expert review [I-D.ietf-nsis-ntlp].
8.2.3. Use of Alternative Security Services 8.2.3. Use of Alternative Security Services
Currently only TLS is specified for providing secure channels with Currently only TLS is specified for providing secure channels with
MAs. Section 3.9 suggests that alternative protocols could be used, MAs. Section 3.9 of the GIST specification
but the interactions with GIST functions would need to be carefully [I-D.ietf-nsis-ntlp]suggests that alternative protocols could be
specified. See also Section 4.4.2. used, but the interactions with GIST functions would need to be
carefully specified. See also Section 4.4.2 of the GIST
specification [I-D.ietf-nsis-ntlp].
o Use of an alternative security service requires allocation of a o Use of an alternative security service requires allocation of a
new MA-Protocol-ID either by IETF review of a specification or new MA-Protocol-ID either by IETF review of a specification or
expert review [I-D.ietf-nsis-ntlp]. expert review [I-D.ietf-nsis-ntlp].
8.2.4. Query Mode Packet Interception Schemes 8.2.4. Query Mode Packet Interception Schemes
GIST has standardized a scheme using RAO GIST has standardized a scheme using RAO
mechanisms[I-D.hancock-nsis-gist-rao] with UDP packets. If the mechanisms[I-D.hancock-nsis-gist-rao] with UDP packets. If the
difficulties of deploying the RAO scheme prove insuperable in difficulties of deploying the RAO scheme prove insuperable in
particular circumstances, alternative interception schemes can be particular circumstances, alternative interception schemes can be
specified. One proposal that was explored for GIST used UDP port specified. One proposal that was explored for GIST used UDP port
recognition in routers rather than RAO mechanisms to drive the 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 interception of packets. See Section 5.3.2 of the GIST specification
needs to specify membership of an "interception class" whenever it
sends a message through GIST. A packet interception scheme can [I-D.ietf-nsis-ntlp]. Each NSLP needs to specify membership of an
support one or more interception classes. In principle, a GIST "interception class" whenever it sends a message through GIST. A
instance can support multiple packet interception schemes, but each packet interception scheme can support one or more interception
interception class needs to be associated with exactly one classes. In principle, a GIST instance can support multiple packet
interception scheme in a GIST instance and GIST instances that use interception schemes, but each interception class needs to be
different packet interception schemes for the same interception class associated with exactly one interception scheme in a GIST instance
will not be interoperable. and GIST instances that use different packet interception schemes for
the same interception class will not be interoperable.
Defining an alternative interception class mechanism for Defining an alternative interception class mechanism for
incorporation into GIST should be considered as a very radical step incorporation into GIST should be considered as a very radical step
and all alternatives should be considered before taking this path. and all alternatives should be considered before taking this path.
The main reason for this is that the mechanism will necessarily The main reason for this is that the mechanism will necessarily
require additional operations on every packet passing through the require additional operations on every packet passing through the
affected router interfaces. A number of considerations should be affected router interfaces. A number of considerations should be
taken into account: taken into account:
o Although the interception mechanism need only be deployed on o Although the interception mechanism need only be deployed on
routers that actually need it (probably for a new NSLP), routers that actually need it (probably for a new NSLP),
skipping to change at page 21, line 7 skipping to change at page 20, line 12
as is the case with the current RAO mechanism as is the case with the current RAO mechanism
[I-D.hancock-nsis-gist-rao], the scheme distinguishes between [I-D.hancock-nsis-gist-rao], the scheme distinguishes between
multiple packet interception classes by a value carried on the multiple packet interception classes by a value carried on the
wire (different values of RAO parameter for the RAO mechanism in wire (different values of RAO parameter for the RAO mechanism in
GIST), an IANA registry may be required to provide a mapping GIST), an IANA registry may be required to provide a mapping
between interception classes and on-the-wire values as discussed between interception classes and on-the-wire values as discussed
in Section 6 of [I-D.hancock-nsis-gist-rao]. in Section 6 of [I-D.hancock-nsis-gist-rao].
8.2.5. Use of Alternative NAT Traversal Mechanisms 8.2.5. Use of Alternative NAT Traversal Mechanisms
The mechanisms proposed for both legacy NAT traversal (Section 7.2.1) 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 of the GIST specification [I-D.ietf-nsis-ntlp]) and GIST-aware NAT
replaced. As discussed above, extension of NAT traversal may be traversal (Section 7.2.2 of the GIST specification
needed if a new MRM is deployed. Note that there is extensive [I-D.ietf-nsis-ntlp]) can be extended or replaced. As discussed
discussion of NAT traversal in the NAT/Firewall NSLP specification above, extension of NAT traversal may be needed if a new MRM is
[I-D.ietf-nsis-nslp-natfw]. deployed. Note that there is extensive discussion of NAT traversal
in the NAT/Firewall NSLP specification [I-D.ietf-nsis-nslp-natfw].
8.2.6. Additional Error Identifiers 8.2.6. Additional Error Identifiers
Making extensions to any of the above items may result in new error 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 modes having to be catered for. See Section 9 and Appendix A
Sections A.4.1 - A.4.3. Sections A.4.1 - A.4.3 of the GIST specification
[I-D.ietf-nsis-ntlp].
o Additional error identifiers require allocation of new error o Additional error identifiers require allocation of new error
code(s) and/or subcode(s), and may also require allocation of code(s) and/or subcode(s), and may also require allocation of
Additional Information types. These are all allocated on a first- Additional Information types. These are all allocated on a first-
come, first-served basis by IANA [I-D.ietf-nsis-ntlp]. come, first-served basis by IANA [I-D.ietf-nsis-ntlp].
8.2.7. Defining New Objects to be Carried in GIST 8.2.7. Defining New Objects to be Carried in GIST
The AB-flags in each signaling object carried in NSIS protocols The AB-flags in each signaling object carried in NSIS protocols
enable the community to specify new objects applicable to GIST, that enable the community to specify new objects applicable to GIST, that
skipping to change at page 26, line 50 skipping to change at page 26, line 13
need to be carefully assessed for any security implications. This is need to be carefully assessed for any security implications. This is
particularly important because NSIS messages are intended to be particularly important because NSIS messages are intended to be
actively processed by NSIS-capable routers that they pass through, actively processed by NSIS-capable routers that they pass through,
rather than simply forwarded as is the case with most IP packets. It rather than simply forwarded as is the case with most IP packets. It
is essential that extensions provide means to authorize usage of is essential that extensions provide means to authorize usage of
capabilities that might allocate resources and recommend the use of capabilities that might allocate resources and recommend the use of
appropriate authentication and integrity protection measures in order appropriate authentication and integrity protection measures in order
to exclude or adequately mitigate any security issues that are to exclude or adequately mitigate any security issues that are
identified. identified.
Authors of new extensions for NSIS should review the analysis of
security threats to NSIS documented in [RFC4081] as well as
considering whether the new extension opens any new attack paths that
need to mitigated.
GIST offers facilities to authenticate NSIS messages and to ensure GIST offers facilities to authenticate NSIS messages and to ensure
that they are delivered reliably. Extensions must allow these that they are delivered reliably. Extensions must allow these
capabilities to be used in an appropriate manner to minimize the capabilities to be used in an appropriate manner to minimize the
risks of NSIS messages being misused, and must recommend their risks of NSIS messages being misused, and must recommend their
appropriate usage. appropriate usage.
If additional transport protocols are proposed for use in association If additional transport protocols are proposed for use in association
with GIST, an appropriate set of compatible security functions must with GIST, an appropriate set of compatible security functions must
be made available in conjunction with the transport protocol to be made available in conjunction with the transport protocol to
support the authentication and integrity functions expected to be support the authentication and integrity functions expected to be
skipping to change at page 27, line 43 skipping to change at page 27, line 13
feedback on this draft, while Allison Mankin and Bob Braden suggested feedback on this draft, while Allison Mankin and Bob Braden suggested
that this draft be worked on. that this draft be worked on.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-nsis-nslp-natfw] [I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies,
"NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
draft-ietf-nsis-nslp-natfw-23 (work in progress), draft-ietf-nsis-nslp-natfw-24 (work in progress),
February 2010. April 2010.
[I-D.ietf-nsis-ntlp] [I-D.ietf-nsis-ntlp]
Schulzrinne, H. and M. Stiemerling, "GIST: General Schulzrinne, H. and M. Stiemerling, "GIST: General
Internet Signalling Transport", draft-ietf-nsis-ntlp-20 Internet Signalling Transport", draft-ietf-nsis-ntlp-20
(work in progress), June 2009. (work in progress), June 2009.
[I-D.ietf-nsis-qos-nslp] [I-D.ietf-nsis-qos-nslp]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18
(work in progress), January 2010. (work in progress), January 2010.
skipping to change at page 29, line 21 skipping to change at page 28, line 37
[I-D.ietf-nsis-ntlp-sctp] [I-D.ietf-nsis-ntlp-sctp]
Fu, X., Dickmann, C., and J. Crowcroft, "General Internet Fu, X., Dickmann, C., and J. Crowcroft, "General Internet
Signaling Transport (GIST) over SCTP and Datagram TLS", Signaling Transport (GIST) over SCTP and Datagram TLS",
draft-ietf-nsis-ntlp-sctp-09 (work in progress), draft-ietf-nsis-ntlp-sctp-09 (work in progress),
February 2010. February 2010.
[I-D.kappler-nsis-qosmodel-controlledload] [I-D.kappler-nsis-qosmodel-controlledload]
Kappler, C., Fu, X., and B. Schloer, "A QoS Model for Kappler, C., Fu, X., and B. Schloer, "A QoS Model for
Signaling IntServ Controlled-Load Service with NSIS", Signaling IntServ Controlled-Load Service with NSIS",
draft-kappler-nsis-qosmodel-controlledload-10 (work in draft-kappler-nsis-qosmodel-controlledload-11 (work in
progress), October 2009. progress), April 2010.
[I-D.manner-nsis-gist-dccp] [I-D.manner-nsis-gist-dccp]
Manner, J., "Generic Internet Signaling Transport over Manner, J., "Generic Internet Signaling Transport over
DCCP and DTLS", draft-manner-nsis-gist-dccp-00 (work in DCCP and DTLS", draft-manner-nsis-gist-dccp-00 (work in
progress), June 2007. progress), June 2007.
[I-D.manner-nsis-nslp-auth] [I-D.manner-nsis-nslp-auth]
Manner, J., Stiemerling, M., Tschofenig, H., and R. Bless, Manner, J., Stiemerling, M., Tschofenig, H., and R. Bless,
"Authorization for NSIS Signaling Layer Protocols", "Authorization for NSIS Signaling Layer Protocols",
draft-manner-nsis-nslp-auth-04 (work in progress), draft-manner-nsis-nslp-auth-04 (work in progress),
 End of changes. 27 change blocks. 
87 lines changed or deleted 96 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/