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 Approach 7.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: email@example.com URI: http://www.netlab.tkk.fi/~jmanner/ Georgios Karagiannis University of Twente/Ericsson P.O. Box 217 Enschede 7500 AE The Netherlands EMail: firstname.lastname@example.org Andrew McDonald Roke Manor Research Ltd Old Salisbury Lane Romsey, Hampshire S051 0ZN United Kingdom EMail: email@example.com