RFC 5974
NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling
Pages: 102
Experimental
Experimental
Part 6 of 6 – Pages 83 to 102
7. Security Considerations
The security requirement for the QoS NSLP is to protect the signaling exchange for establishing QoS reservations against identified security threats. For the signaling problem as a whole, these threats have been outlined in NSIS threats [RFC4081]; the NSIS framework [RFC4080] assigns a subset of the responsibility to GIST, and the remaining threats need to be addressed by NSLPs. The main issues to be handled can be summarized as:
Authorization:
The QoS NSLP must assure that the network is protected against
theft-of-service by offering mechanisms to authorize the QoS
reservation requester. A user requesting a QoS reservation might
want proper resource accounting and protection against spoofing
and other security vulnerabilities that lead to denial of service
and financial loss. In many cases, authorization is based on the
authenticated identity. The authorization solution must provide
guarantees that replay attacks are either not possible or limited
to a certain extent. Authorization can also be based on traits
that enable the user to remain anonymous. Support for user
identity confidentiality can be accomplished.
Message Protection:
Signaling message content should be protected against
modification, replay, injection, and eavesdropping while in
transit. Authorization information, such as authorization tokens,
needs protection. This type of protection at the NSLP layer is
necessary to protect messages between NSLP nodes.
Rate Limitation:
QNEs should perform rate-limiting on the refresh messages that
they send. An attacker could send erroneous messages on purpose,
forcing the QNE to constantly reply with an error message.
Authentication mechanisms would help in figuring out if error
situations should be reported to the sender, or silently ignored.
If the sender is authenticated, the QNE should reply promptly.
Prevention of Denial-of-Service Attacks:
GIST and QoS NSLP nodes have finite resources (state storage,
processing power, bandwidth). The protocol mechanisms in this
document try to minimize exhaustion attacks against these
resources when performing authentication and authorization for QoS
resources.
To some extent, the QoS NSLP relies on the security mechanisms
provided by GIST, which by itself relies on existing authentication
and key exchange protocols. Some signaling messages cannot be
protected by GIST and hence should be used with care by the QoS NSLP.
An API must ensure that the QoS NSLP implementation is aware of the
underlying security mechanisms and must be able to indicate which
degree of security is provided between two GIST peers. If a level of
security protection for QoS NSLP messages that is required goes
beyond the security offered by GIST or underlying security
mechanisms, additional security mechanisms described in this document must be used. Due to the different usage environments and scenarios where NSIS is used, it is very difficult to make general statements without reducing its flexibility.7.1. Trust Relationship Model
This specification is based on a model that requires trust between neighboring NSLP nodes to establish a chain-of-trust along the QoS signaling path. The model is simple to deploy, was used in previous QoS authorization environments (such as RSVP), and seems to provide sufficiently strong security properties. We refer to this model as the New Jersey Turnpike. On the New Jersey Turnpike, motorists pick up a ticket at a toll booth when entering the highway. At the highway exit, the ticket is presented and payment is made at the toll booth for the distance driven. For QoS signaling in the Internet, this procedure is roughly similar. In most cases, the data sender is charged for transmitted data traffic where charging is provided only between neighboring entities.
+------------------+ +------------------+ +------------------+ | Network | | Network | | Network | | X | | Y | | Z | | | | | | | | -----------> -----------> | | | | | | | | | | | | | +--------^---------+ +------------------+ +-------+----------+ | . | . | v +--+---+ Data Data +--+---+ | Node | ==============================> | Node | | A | Sender Receiver | B | +------+ +------+ Legend: ----> Peering relationship that allows neighboring networks/entities to charge each other for the QoS reservation and data traffic ====> Data flow .... Communication to the end host Figure 16: New Jersey Turnpike Model The model shown in Figure 16 uses peer-to-peer relationships between different administrative domains as a basis for accounting and charging. As mentioned above, based on the peering relationship, a chain-of-trust is established. There are several issues that come to mind when considering this type of model: o The model allows authorization on a request basis or on a per- session basis. Authorization mechanisms are elaborated in Section 7.2. The duration for which the QoS authorization is valid needs to be controlled. Combining the interval with the soft-state interval is possible. Notifications from the networks also seem to be a viable approach. o The price for a QoS reservation needs to be determined somehow and communicated to the charged entity and to the network where the charged entity is attached. Protocols providing "Advice of Charge" functionality are out of scope.
o This architecture is simple enough to allow a scalable solution
(ignoring reverse charging, multicast issues, and price
distribution).
Charging the data sender as performed in the model simplifies
security handling by demanding only peer-to-peer security protection.
Node A would perform authentication and key establishment. The
established security association (together with the session key)
would allow the user to protect QoS signaling messages. The identity
used during the authentication and key establishment phase would be
used by Network X (see Figure 16) to perform the so-called policy-
based admission control procedure. In our context, this user
identifier would be used to establish the necessary infrastructure to
provide authorization and charging. Signaling messages later
exchanged between the different networks are then also subject to
authentication and authorization. However, the authenticated entity
is thereby the neighboring network and not the end host.
The New Jersey Turnpike model is attractive because of its
simplicity. S. Shenker, et al. [shenker] discuss various accounting
implications and introduced the edge pricing model. The edge pricing
model shows similarity to the model described in this section, with
the exception that mobility and the security implications are not
addressed.
7.2. Authorization Model Examples
Various authorization models can be used in conjunction with the QoS
NSLP.
7.2.1. Authorization for the Two-Party Approach
The two-party approach (Figure 17) is conceptually the simplest
authorization model.
+-------------+ QoS request +--------------+
| Entity |----------------->| Entity |
| requesting | | authorizing |
| resource |granted / rejected| resource |
| |<-----------------| request |
+-------------+ +--------------+
^ ^
+...........................+
compensation
Figure 17: Two-Party Approach
In this example, the authorization decision only involves the two entities, or makes use of previous authorization using an out-of-band mechanism to avoid the need for active participation of an external entity during the NSIS protocol execution. This type of model may be applicable, e.g., between two neighboring networks (inter-domain signaling) where a long-term contract (or other out-of-band mechanisms) exists to manage charging and provides sufficient information to authorize individual requests.7.2.2. Token-Based Three-Party Approach
An alternative approach makes use of tokens, such as those described in RFC 3520 [RFC3520] and RFC 3521 [RFC3521] or used as part of the Open Settlement Protocol [osp]. Authorization tokens are used to associate two different signaling protocols runs (e.g., SIP and NSIS) and their authorization decision with each other. The latter is a form of assertion or trait. As an example, with the authorization token mechanism, some form of authorization is provided by the SIP proxy, which acts as the resource-authorizing entity in Figure 18. If the request is authorized, then the SIP signaling returns an authorization token that can be included in the QoS signaling protocol messages to refer to the previous authorization decision. The tokens themselves may take a number of different forms, some of which may require the entity performing the QoS reservation to query the external state.
Authorization Token Request +--------------+ +-------------->| Entity C | financial settlement | | authorizing | <..................+ | | resource | . | +------+ request | . | | +--------------+ . | | . | |Authorization . | |Token . | | . | | . | | . | | QoS request . +-------------+ + Authz. Token +--------------+ . | Entity |----------------->| Entity B | . | requesting | | performing | . | resource |granted / rejected| QoS | <..+ | A |<-----------------| reservation | +-------------+ +--------------+ Figure 18: Token-Based Three-Party Approach For the digital money type of systems (e.g., OSP tokens), the token represents a limited amount of credit. So, new tokens must be sent with later refresh messages once the credit is exhausted.
7.2.3. Generic Three-Party Approach
Another method is for the node performing the QoS reservation to delegate the authorization decision to a third party, as illustrated in Figure 19. The authorization decision may be performed on a per- request basis, periodically, or on a per-session basis. +--------------+ | Entity C | | authorizing | | resource | | request | +-----------+--+ ^ | QoS | | QoS authz| |authz req.| | res. QoS | v +-------------+ request +--+-----------+ | Entity |----------------->| Entity B | | requesting | | performing | | resource |granted / rejected| QoS | | A |<-----------------| reservation | +-------------+ +--------------+ Figure 19: Three-Party Approach7.3. Computing the Authorization Decision
Whenever an authorization decision has to be made there is the question about which information serves as an input to the authorizing entity. The following information items have been mentioned in the past for computing the authorization decision (in addition to the authenticated identity): Price QoS objects Policy rules Policy rules take into consideration attributes like time of day, subscription to certain services, membership, etc., when computing an authorization decision. The policies used to make the authorization are outside the scope of this document and are implementation/deployment specific.
8. Acknowledgments
The authors would like to thank Eleanor Hepworth, Ruediger Geib, Roland Bless, Nemeth Krisztian, Markus Ott, Mayi Zoumaro-Djayoon, Martijn Swanink, and Ruud Klaver for their useful comments. Roland, especially, has done deep reviews of the document, making sure the protocol is well defined. Bob Braden provided helpful comments and guidance which were gratefully received.9. Contributors
This document combines work from three individual documents. The following authors from these documents also contributed to this document: Robert Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson), and Maarten Buechli (Dante) and Eric Waegeman (Alcatel). In addition, Roland Bless has contributed considerable amounts of text all along the writing of this specification. Sven Van den Bosch was the initial editor of earlier draft versions of this document. Since version 06 of the document, Jukka Manner has taken the editorship. Yacine El Mghazli (Alcatel) contributed text on AAA. Charles Shen and Henning Schulzrinne suggested the use of the reason field in the BOUND-SESSION-ID.10. References
10.1. Normative References
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010. [RFC5975] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October 2010.10.2. Informative References
[NSIS-AUTH] Manner, J., Stiemerling, M., Tschofenig, H., and R. Bless, Ed., "Authorization for NSIS Signaling Layer Protocols", Work in Progress, May 2010.
[NSIS-MOB] Sanda, T., Fu, X., Jeong, S., Manner, J., and H. Tschofenig, "NSIS Protocols operation in Mobile Environments", Work in Progress, May 2010. [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001. [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001. [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003. [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session Set-up with Media Authorization", RFC 3521, April 2003. [RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004. [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005. [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", RFC 5973, October 2010. [RFC5977] Bader, A., Westberg, L., Karagiannis, G., Kappler, C., Tschofenig, H., and T. Phelan, "RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv", RFC 5977, October 2010. [lrsvp] Manner, J. and K. Raatikainen, "Localized QoS Management for Multimedia Applications in Wireless Access Networks", IASTED IMSA, Technical Specification 101 321, p. 193-200, August 2004. [opwa95] Breslau, L., "Two Issues in Reservation Establishment", Proc. ACM SIGCOMM '95, Cambridge MA, August 1995. [osp] ETSI, "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Open Settlement Protocol (OSP) for Inter-Domain pricing, authorization, and usage exchange", Technical Specification 101 321, version 4.1.1. [qos-auth] Tschofenig, H., "QoS NSLP Authorization Issues", Work in Progress, June 2003. [shenker] Shenker, S., et al., "Pricing in computer networks: Reshaping the research agenda", Proc. of TPRC 1995, 1995.
Appendix A. Abstract NSLP-RMF API
This appendix is purely informational and provides an abstract API between the QoS NSLP and the RMF. It should not be taken as a strict rule for implementors, but rather it helps clarify the interface between the NSLP and RMF.A.1. Triggers from QOS-NSLP towards RMF
The QoS-NSLP triggers the RMF/QOSM functionality by using the sendrmf() primitive: int sendrmf(sid, nslp_req_type, qspec, authorization_info, NSLP_objects, filter, features_in, GIST_API_triggers, incoming_interface, outgoing_interface) o sid: SESSION-ID - The NSIS session identifier o nslp_req_type: indicates type of request: * RESERVE * QUERY * RESPONSE * NOTIFY o qspec: the QSPEC object, if present o authorization_info: the AUTH_SESSION object, if present o NSLP_objects: data structure that contains a list with received QoS-NSLP objects. This list can be used by, e.g., local applications, network management, or policy control modules: * RII * RSN * BOUND-SESSION-ID list * REFRESH-PERIOD * SESSION-ID-LIST * RSN-LIST
* INFO-SPEC
* MSG-ID
* BOUND-MSG-ID
o filter: the information for packet filtering, based on the MRI and
the PACKET-CLASSIFIER object.
o features_in: it represents the flags included in the common header
of the received QOS-NSLP message, but also additional triggers:
* BREAK
* REQUEST REDUCED REFRESHES
* RESERVE-INIT
* TEAR
* REPLACE
* ACK-REQ
* PROXY
* SCOPING
* synchronization_required: this attribute is set (see Sections
Section 4.6 and Section 4.7.1, for example) when the QoS-NSLP
functionality supported by a QNE Egress receives a non-tearing
RESERVE message that includes a MSG-ID or a BOUND-MSG-ID
object, and the BINDING_CODE value of the BOUND-SESSION-ID
object is equal to one of the following values:
+ Tunnel and end-to-end sessions
+ Aggregate sessions
* GIST_API_triggers: it represents the attributes that are
provided by GIST to QoS-NSLP via the GIST API:
+ NSLPID
+ Routing-State-Check
+ SII-Handle
+ Transfer-Attributes
+ GIST-Hop-Count
+ IP-TTL
+ IP-Distance
o incoming_interface: the ID of the incoming interface. Used only
when the QNE reserves resources on incoming interface. Default is
0 (no reservations on incoming interface)
o outgoing_interface: the ID of the outgoing interface. Used only
when the QNE reserves resources on outgoing interface. Default is
0 (no reservations on outgoing interface)
A.2. Triggers from RMF/QOSM towards QOS-NSLP
The RMF triggers the QoS-NSLP functionality using the "recvrmf()" and
"config()" primitives to perform either all or a subset of the
features listed below.
The recvrmf() primitive represents either a response to a request
that has been sent via the API by the QoS-NSLP or an asynchronous
notification. Note that when the RMF/QOSM receives a request via the
API from the QoS-NSLP function, one or more "recvrmf()" response
primitives can be sent via the API towards QoS-NSLP. In this way,
the QOS-NSLP can generate one or more QoS-NSLP messages that can be
used, for example, in the situation that the arrival of one end-to-
end RESERVE triggers the generation of two (or more) RESERVE
messages: an end-to-end RESERVE message and one (or more) intra-
domain (local) RESERVE message.
The config() primitive is used to configure certain features, such as
QNE type, stateful or stateless operation, or bypassing of end-to-end
messages.
Note that the selection of the subset of triggers is controlled by
the QoS Model.
int recvrmf(sid, nslp_resp_type, qspec, authorization_info, status,
NSLP_objects, filter, features_out, GIST_API_triggers
incoming_interface, outgoing_interface)
o sid: SESSION-ID - The NSIS session identifier
o nslp_resp_type: indicates type of response:
* RESERVE
* QUERY
* RESPONSE
* NOTIFY
o qspec: the QSPEC object, if present
o authorization_info: the AUTHO_SESSION object, if present
o status: boolean that notifies the status of the reservation and
can be used by QOS-NSLP to include in the INFO-SPEC object:
* RESERVATION_SUCCESSFUL
* TEAR_DOWN_SUCCESSFUL
* NO RESOURCES
* RESERVATION_FAILURE
* RESERVATION_PREEMPTED: reservation was preempted
* AUTHORIZATION_FAILED: authorizing the request failed
* MALFORMED_QSPEC: request failed due to malformed qspec
* SYNCHRONIZATION_FAILED: Mismatch synchronization between an
end-to-end RESERVE and an intra-domain RESERVE (see Sections
Section 4.6 and Section 4.7.1)
* CONGESTION_SITUATION: Possible congestion situation occurred on
downstream path
* QoS Model Error
o NSLP_objects: data structure that contains a list with QoS-NSLP
objects that can be used by QoS-NSLP when the QNE is a QNI, QNR,
QNI_Ingress, QNR_Ingress, QNI_Egress, or QNR_Egress:
* RII
* RSN
* BOUND-SESSION-ID list
* REFRESH-PERIOD
* SESSION-ID-LIST
* RSN-LIST
* MSG-ID
* BOUND-MSG-ID
o filter: it represents the MRM-related PACKET CLASSIFIER
o features_out: it represents (among others) the flags that can be
used by the QOS-NSLP for newly generated QoS-NSLP messages:
* BREAK
* REQUEST REDUCED REFRESHES
* RESERVE-INIT
* TEAR
* REPLACE
* ACK-REQ
* PROXY
* SCOPING
* BYPASSING - when the outgoing message should be bypassed, then
it includes the required bypassing level. Otherwise, it is
empty. It can be set only by QNI_Ingress, QNR_Ingress,
QNI_Egress, or QNR_Egress. It can be unset only by
QNI_Ingress, QNR_Ingress, QNI_Egress, or QNR_Egress.
* BINDING () - when BINDING is required, then it includes a
BOUND-SESSION-ID list. Otherwise, it is empty. It can only be
requested by the following QNE types: QNI, QNR, QNI_Ingress,
QNR_Ingress, QNI_Egress, or QNR_Egress.
* NEW_SID - it requests to generate a new session with a new
SESSION-ID. If the QoS-NSLP generates a new SESSION-ID, then
the QoS-NSLP has to return the value of this new SESSION-ID to
the RMF/QOSM. It can be requested by a QNI, QNR, QNI_Ingress,
QNI_Egress, QNR_Ingress, or QNR_Egress.
* NEW_RSN - it requests to generate a new RSN. If the QoS-NSLP
generates a new RSN, then the QoS-NSLP has to return the value
of this new RSN to the RMF/QOSM.
* NEW_RII - it requests to generate a new RII. If the QoS-NSLP
generates a new RII, then the QoS-NSLP has to return the value
of this new RII to the RMF/QOSM.
o GIST_API_triggers: it represents the attributes that are provided
to GIST via QoS-NSLP via the GIST API:
* NSLPID
* SII-Handle
* Transfer-Attributes
* GIST-Hop-Count
* IP-TTL
* ROUTING-STATE-CHECK (if set, it requires that GIST create a
routing state)
o incoming_interface: the ID of the incoming interface. Used only
when the QNE reserves resources on the incoming interface.
Default is 0 (no reservations on the incoming interface).
o outgoing_interface: the ID of the outgoing interface. Used only
when the QNE reserves resources on the outgoing interface.
Default is 0 (no reservations on the outgoing interface).
A.3. Configuration Interface
The config() function is meant for configuring per-session settings,
from the RMF towards the NSLP.
int config(sid, qne_type, state_type, bypassing_type)
o sid: SESSION-ID - The NSIS session identifier
o qne_type: it defines the type of a QNE
* QNI
* QNI_Ingress: the QNE is a QNI and an Ingress QNE
* QNE: the QNE is not a QNI or QNR
* QNE_Interior: the QNE is an Interior QNE, but it is not a QNI
or QNR
* QNI_Egress: the QNE is a QNI and an Egress QNE
* QNR
* QNR_Ingress: the QNE is a QNR and an Ingress QNE
* QNR_Egress: the QNE is a QNR and an Egress QNE
o state_type: it defines if the QNE keeps QoS-NSLP operational
states
* STATEFUL
* STATELESS
o bypassing_type: it defines if a QNE bypasses end-to-end messages
or not
Appendix B. Glossary
AAA: Authentication, Authorization, and Accounting
EAP: Extensible Authentication Protocol
MRI: Message Routing Information (see [RFC5971])
NAT: Network Address Translator
NSLP: NSIS Signaling Layer Protocol (see [RFC4080])
NTLP: NSIS Transport Layer Protocol (see [RFC4080])
OPWA: One Pass With Advertising
OSP: Open Settlement Protocol
PIN: Policy-Ignorant Node
QNE: an NSIS Entity (NE), which supports the QoS NSLP (see Section 2) QNI: the first node in the sequence of QNEs that issues a reservation request for a session (see Section 22) QNR: the last node in the sequence of QNEs that receives a reservation request for a session (see Section 22) QSPEC: Quality-of-Service Specification RII: Request Identification Information RMD: Resource Management for Diffserv RMF: Resource Management Function RSN: Reservation Sequence Number RSVP: Resource Reservation Protocol (see [RFC2205]) SII: Source Identification Information SIP: Session Initiation Protocol SLA: Service Level Agreement
Authors' Addresses
Jukka Manner Aalto University Department of Communications and Networking (Comnet) P.O. Box 13000 FIN-00076 Aalto Finland Phone: +358 9 470 22481 EMail: jukka.manner@tkk.fi URI: http://www.netlab.tkk.fi/~jmanner/ Georgios Karagiannis University of Twente/Ericsson P.O. Box 217 Enschede 7500 AE The Netherlands EMail: karagian@cs.utwente.nl Andrew McDonald Roke Manor Research Ltd Old Salisbury Lane Romsey, Hampshire S051 0ZN United Kingdom EMail: andrew.mcdonald@roke.co.uk