=========>| QNF |===========>| QNF |
+-----+ +-----+
--------------------------------------->
data path
Figure 7: Normal NSIS Protocol Operation
A route change can occur while such a reservation is in place. The
route change will be installed immediately, and any data will be
forwarded on the new path. This situation is depicted Figure 8.
Resource reservation on the new path will only be started once the
next control message is routed along the new path. This means that
there is a certain time interval during which resources are not
reserved on (part of) the data path, and certain delay or
drop-sensitive applications will require that this time interval be
minimized. Several techniques to achieve this could be considered.
As an example, RSVP [7] has the concept of local repair, whereby the
router may be triggered by a route change. In that case, the RSVP
node can start sending PATH messages directly after the route has
been changed. Note that this option may not be available if no
per-flow state is kept in the QNF. Another approach would be to
pre-install backup state, and it would be the responsibility of the
QoS-NSLP to do this. However, mechanisms for identifying backup
paths and routing the necessary signaling messages along them are not
currently considered in the NSIS requirements and framework.
Route update
|
v
reserved +-----+ reserved +-----+
=========>| QNF |===========>| QNF |
+-----+ +-----+
-------- ||
\ || +-----+
| ===========>| QNF |
| +-----+
+--------------------------->
data path
Figure 8: Route Change
The new path might not be able to provide the same guarantees that
were available on the old path. Therefore, it might be desirable for
the QNF to wait until resources have been reserved on the new path
before allowing the route change to be installed (unless, of course,
the old path no longer exists). However, delaying the route change
installation while waiting for reservation setup needs careful
analysis of the interaction with the routing protocol being used, in
order to avoid routing loops.
Another example related to route changes is denoted as severe
congestion and is explained in [31]. This solution adapts to a route
change when a route change creates congestion on the new routed path.
6.1.4. Resource Management Interactions
The QoS NSLP itself is not involved in any specific resource
allocation or management techniques. The definition of an NSLP for
resource reservation with Quality of Service, however, implies the
notion of admission control. For a QoS NSLP, the measure of
signaling success will be the ability to reserve resources from the
total resource pool that is provisioned in the network. We define
the function responsible for allocating this resource pool as the
Resource Management Function (RMF). The RMF is responsible for all
resource provisioning, monitoring, and assurance functions in the
network.
A QoS NSLP will rely on the RMF to do resource management and to
provide inputs for admission control. In this model, the RMF acts as
a server towards client NSLP(s). Note, however, that the RMF may in
turn use another NSLP instance to do the actual resource provisioning
in the network. In this case, the RMF acts as the initiator (client)
of an NSLP.
This essentially corresponds to a multi-level signaling paradigm,
with an ’upper’ level handling internetworking QoS signaling
(possibly running end-to-end), and a ’lower’ level handling the more
specialized intra-domain QoS signaling (running between just the
edges of the network). (See [10], [32], and [33] for a discussion of
similar architectures.) Given that NSIS signaling is already
supposed to be able to support multiple instances of NSLPs for a
given flow and limited scope (e.g., edge-to-edge) operation, it is
not currently clear that supporting the multi-level model leads to
any new protocol requirements for the QoS NSLP.
The RMF may or may not be co-located with a QNF (note that
co-location with a QNI/QNR can be handled logically as a combination
between QNF and QNI/QNR). To cater for both cases, we define a
(possibly logical) QNF-RMF interface. Over this interface,
information may be provided from the RMF about monitoring, resource
availability, topology, and configuration. In the other direction,
the interface may be used to trigger requests for resource
provisioning. One way to formalize the interface between the QNF and
the RMF is via a Service Level Agreement (SLA). The SLA may be
static or it may be dynamically updated by means of a negotiation
protocol. Such a protocol is outside the scope of NSIS.
There is no assumed restriction on the placement of the RMF. It may
be a centralized RMF per domain, several off-path distributed RMFs,
or an on-path RMF per router. The advantages and disadvantages of
both approaches are well-known. Centralization typically allows
decisions to be taken using more global information, with more
efficient resource utilization as a result. It also facilitates
deployment or upgrade of policies. Distribution allows local
decision processes and rapid response to data path changes.
6.2. Other Signaling Applications
As well as the use for ’traditional’ QoS signaling, it should be
possible to develop NSLPs for other signaling applications that
operate on different types of network control state. One specific
case is setting up flow-related state in middleboxes (firewalls,
NATs, and so on). Requirements for such communication are given in
[4]. Other examples include network monitoring and testing, and
tunnel endpoint discovery.
7. Security Considerations
This document describes a framework for signaling protocols that
assumes a two-layer decomposition, with a common lower layer (NTLP)
supporting a family of signaling-application-specific upper-layer
protocols (NSLPs). The overall security considerations for the
signaling therefore depend on the joint security properties assumed
or demanded for each layer.
Security for the NTLP is discussed in Section 4.7. We have assumed
that, apart from being resistant to denial of service attacks against
itself, the main role of the NTLP will be to provide message
protection over the scope of a single peer relationship, between
adjacent signaling application entities. (See Section 3.2.3 for a
discussion of the case where these entities are separated by more
than one NTLP hop.) These functions can ideally be provided by an
existing channel security mechanism, preferably using an external key
management mechanism based on mutual authentication. Examples of
possible mechanisms are TLS, IPsec and SSH. However, there are
interactions between the actual choice of security protocol and the
rest of the NTLP design. Primarily, most existing channel security
mechanisms require explicit identification of the peers involved at
the network and/or transport level. This conflicts with those
aspects of path-coupled signaling operation (e.g., discovery) where
this information is not even implicitly available because peer
identities are unknown; the impact of this ’next-hop problem’ on RSVP
design is discussed in the security properties document [6] and also
influences many parts of the threat analysis [2]. Therefore, this
framework does not mandate the use of any specific channel security
protocol; instead, this has to be integrated with the design of the
NTLP as a whole.
Security for the NSLPs is entirely dependent on signaling application
requirements. In some cases, no additional protection may be
required compared to what is provided by the NTLP. In other cases,
more sophisticated object-level protection and the use of public-
key-based solutions may be required. In addition, the NSLP needs to
consider the authorization requirements of the signaling application.
Authorization is a complex topic, for which a very brief overview is
provided in Section 3.3.7.
Another factor is that NTLP security mechanisms operate only locally,
whereas NSLP mechanisms may also need to operate over larger regions
(not just between adjacent peers), especially for authorization
aspects. This complicates the analysis of basing signaling
application security on NTLP protection.
An additional concern for signaling applications is the session
identifier security issue (Sections 4.6.2 and 5.2). The purpose of
this identifier is to decouple session identification (as a handle
for network control state) from session "location" (i.e., the data
flow endpoints). The identifier/locator distinction has been
extensively discussed in the user plane for end-to-end data flows,
and is known to lead to non-trivial security issues in binding the
two together again. Our problem is the analogue in the control
plane, and is at least similarly complex, because of the need to
involve nodes in the interior of the network as well.
Further work on this and other security design will depend on a
refinement of the NSIS threats work begun in [2].
8. References
8.1. Normative References
[1] Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
April 2004.
[2] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next
Steps in Signaling (NSIS)", RFC 4081, June 2005.
[3] Chaskar, H., "Requirements of a Quality of Service (QoS)
Solution for Mobile IP", RFC 3583, September 2003.
[4] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore,
"Middlebox Communications (midcom) Protocol Requirements",
RFC 3304, August 2002.
8.2. Informative References
[5] Manner, J. and X. Fu, "Analysis of Existing Quality of Service
Signaling Protocols", Work in Progress, December 2004.
[6] Tschofenig, H., "RSVP Security Properties", Work in Progress,
February 2005.
[7] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[9] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[10] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001.
[11] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", BCP 72, RFC 3552, July 2003.
[12] Tschofenig, H., "NSIS Authentication, Authorization and
Accounting Issues", Work in Progress, March 2003.
[13] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S.
Molendini, "RSVP Refresh Overhead Reduction Extensions",
RFC 2961, April 2001.
[14] Ji, P., Ge, Z., Kurose, J., and D. Townsley, "A Comparison of
Hard-State and Soft-State Signaling Protocols", Computer
Communication Review, Volume 33, Number 4, October 2003.
[15] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914,
September 2000.
[16] Apostolopoulos, G., Kamat, S., Williams, D., Guerin, R., Orda,
A., and T. Przygienda, "QoS Routing Mechanisms and OSPF
Extensions", RFC 2676, August 1999.
[17] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
Multicast Next-Hop Selection", RFC 2991, November 2000.
[18] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC
3768, April 2004.
[19] Heijenk, G., Karagiannis, G., Rexhepi, V., and L. Westberg,
"DiffServ Resource Management in IP-based Radio Access
Networks", Proceedings of 4th International Symposium on
Wireless Personal Multimedia Communications WPMC’01, September
9 - 12 2001.
[20] Manner, J., Lopez, A., Mihailovic, A., Velayos, H., Hepworth,
E., and Y. Khouaja, "Evaluation of Mobility and QoS
Interaction", Computer Networks Volume 38, Issue 2, p. 137-163,
5 February 2002.
[21] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[22] Liebsch, M., Ed., Singh, A., Ed., Chaskar, H., Funato, D., and
E. Shim, "Candidate Access Router Discovery (CARD)", Work in
Progress, May 2005.
[23] Kempf, J., "Problem Description: Reasons For Performing Context
Transfers Between Nodes in an IP Access Network", RFC 3374,
September 2002.
[24] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[25] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
RFC 2765, February 2000.
[26] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
- Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003.
[27] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
Operation Over IP Tunnels", RFC 2746, January 2000.
[28] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service signaling", Work in Progress, February 2005.
[29] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", Work in Progress, February 2005.
[30] Braden, R., Clark, D., and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[31] Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A.,
Partain, D., Pop, O., Rexhepi, V., Szabo, R., and A. Takacs,
"Resource Management in Diffserv (RMD): A Functionality and
Performance Behavior Overview", Seventh International Workshop
on Protocols for High-Speed networks PfHSN 2002, 22 - 24
April 2002.
[32] Ferrari, D., Banerjea, A., and H. Zhang, "Network Support for
Multimedia - A Discussion of the Tenet Approach",
Berkeley TR-92-072, November 1992.
[33] Nichols, K., Jacobson, V., and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet",
RFC 2638, July 1999.
Appendix A. Contributors
Several parts of the introductory sections of this document (in
particular, in Sections 3.1 and 3.3) are based on contributions from
Ilya Freytsis, then of Cetacean Networks, Inc.
Bob Braden originally proposed "A Two-Level Architecture for Internet
Signalling" as an Internet-Draft in November 2001. This document
served as an important starting point for the framework discussed
herein, and the authors owe a debt of gratitude to Bob for this
proposal.
Appendix B. Acknowledgements
The authors would like to thank Bob Braden, Maarten Buchli, Eleanor
Hepworth, Andrew McDonald, Melinda Shore, and Hannes Tschofenig for
significant contributions in particular areas of this document. In
addition, the authors would like to acknowledge Cedric Aoun, Attila
Bader, Anders Bergsten, Roland Bless, Marcus Brunner, Louise Burness,
Xiaoming Fu, Ruediger Geib, Danny Goderis, Kim Hui, Cornelia Kappler,
Sung Hycuk Lee, Thanh Tra Luu, Mac McTiffin, Paulo Mendes, Hans De
Neve, Ping Pan, David Partain, Vlora Rexhepi, Henning Schulzrinne,
Tom Taylor, Michael Thomas, Daniel Warren, Michael Welzl, Lars
Westberg, and Lixia Zhang for insights and inputs during this and
previous framework activities. Dave Oran, Michael Richardson, and
Alex Zinin provided valuable comments during the final review stages.
Authors’ Addresses
Robert Hancock
Siemens/Roke Manor Research
Old Salisbury Lane
Romsey, Hampshire SO51 0ZN
UK
EMail: robert.hancock@roke.co.uk
Georgios Karagiannis
University of Twente
P.O. BOX 217
7500 AE Enschede
The Netherlands
EMail: g.karagiannis@ewi.utwente.nl
John Loughney
Nokia Research Center
11-13 Itamerenkatu
Helsinki 00180
Finland
EMail: john.loughney@nokia.com
Sven Van den Bosch
Alcatel
Francis Wellesplein 1
B-2018 Antwerpen
Belgium
EMail: sven.van_den_bosch@alcatel.be
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.