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