the-middle attacks, replay attacks, and injection or modification of
signaling messages, etc., are mentioned throughout this document.
Path Finding:
Some signaling protocols establish state (e.g., routing state) and
perform some actions (e.g., querying resources) at a number of
NSIS nodes without requiring authorization (or even proper
authentication) based on a single message (e.g., PATH message in
RSVP).
An adversary can utilize this fact to transmit a large number of
signaling messages to allocate state at nodes along the path and
to cause resource consumption.
An NSIS responder might not be able to determine the NSIS
initiator and might even tend to respond to such a signaling
message with a corresponding reservation message.
Discovery Phase:
Conveying signaling information to a large number of entities
along a data path requires some sort of discovery. This discovery
process is vulnerable to a number of attacks because it is
difficult to secure. An adversary can use the discovery
mechanisms to convince one entity to signal information to another
entity that is not along the data path, or to cause the discovery
process to fail. In the first case, the signaling protocol could
appear to continue correctly, except that policy rules are
installed at the incorrect firewalls or QoS resource reservations
take place at the wrong entities. For an end host, this means
that the protocol failed for unknown reasons.
Faked Error or Response Messages:
An adversary may be able to inject false error or response
messages as part of a DoS attack. This could be at the signaling
message protocol layer (NTLP), the layer of each client layer
protocol (e.g., QoS NSLP or NAT/Firewall NSLP), or the transport
protocol layer. An adversary might cause unexpected protocol
behavior or might succeed with a DoS attack. The discovery
protocol, especially, exhibits vulnerabilities with regard to this
threat scenario (see the above discussion on discovery). If no
separate discovery protocol is used and signaling messages are
addressed to end hosts only (with a Router Alert Option to
intercept message as NSIS aware nodes), an error message might be
used to indicate a path change. Such a design combines a
discovery protocol with a signaling message exchange protocol.
4.9. Disclosing the Network Topology
In some organizations or enterprises there is a desire not to reveal
internal network structure (or other related information) outside of
a closed community. An adversary might be able to use NSIS messages
for network mapping (e.g., discovering which nodes exist, which use
NSIS, what version, what resources are allocated, what capabilities
nodes along a path have, etc.). Discovery messages, traceroute,
diagnostic messages (see [RFC2745] for a description of diagnostic
message functionality for RSVP), and query messages, in addition to
record route and route objects, provide potential assistance to an
adversary. Thus, the requirement of not disclosing a network
topology might conflict with other requirements to provide means for
discovering NSIS-aware nodes automatically or to provide diagnostic
facilities (used for network monitoring and administration).
4.10. Unprotected Session or Reservation Ownership
Figure 4 shows an NSIS Initiator that has established state
information at NSIS nodes along a path as part of the signaling
procedure. As a result, Access Router 1, Router 3, and Router 4 (and
other nodes) have stored session-state information, including the
Session Identifier SID-x.
Session ID(SID-x)
+--------+
+-----------------+ Router +------------>
Session ID(SID-x)| | 4 |
+---+----+ +--------+
| Router |
+------+ 3 +*******
| +---+----+ *
| *
| Session ID(SID-x) * Session ID(SID-x)
+---+----+ +---+----+
| Access | | Access |
| Router | | Router |
| 1 | | 2 |
+---+----+ +---+----+
| *
| Session ID(SID-x) * Session ID(SID-x)
+----+------+ +----+------+
| NSIS | | Adversary |
| Initiator | | |
+-----------+ +-----------+
Figure 4: Session or Reservation Ownership
The Session Identifier is included in signaling messages to reference
to the established state.
If an adversary were able to obtain the Session Identifier (for
example, by eavesdropping on signaling messages), it would be able to
add the same Session Identifier SID-x to a new signaling message.
When the new signaling message hits Router 3 (as shown in Figure 4),
existing state information can be modified. The adversary can then
modify or delete the established reservation and cause unexpected
behavior for the legitimate user.
The source of the problem is that Router 3 (a cross-over router) is
unable to decide whether the new signaling message was initiated from
the owner of the session or reservation.
In addition, nodes other than the initial signaling message
originator are allowed to signal information during the lifetime of
an established session. As part of the protocol, any NSIS-aware node
along the path (and the path might change over time) could initiate a
signaling message exchange. It might, for example, be necessary to
provide mobility support or to trigger a local repair procedure. If
only the initial signaling message originator were allowed to trigger
signaling message exchanges, some protocol behavior would not be
possible.
If this threat scenario is not addressed, an adversary can launch
DoS, theft of service, and various other attacks.
4.11. Attacks against the NTLP
In [2LEVEL], a two-level architecture is proposed, that would split
an NSIS protocol into layers: a signaling message transport-specific
layer and an application-specific layer. This is further developed
in the NSIS Framework [RFC4080]. Most of the threats described in
this threat analysis are applicable to the NSLP application-specific
part (e.g., QoS NSLP). There are, however, some threats that are
applicable to the NTLP.
Network and transport layer protocols lacking protection mechanisms
are vulnerable to certain attacks, such as header manipulation, DoS,
spoofing of identities, session hijacking, unexpected aborts, etc.
Malicious nodes can attack the congestion control mechanism to force
NSIS nodes into a congestion avoidance state.
Threats that address parts of the NTLP that are not related to
attacks against the use of transport layer protocols are covered in
various sections throughout this document, such as Section 4.2.
If existing transport layer protocols are used for exchanging NSIS
signaling messages, security vulnerabilities known for these
protocols need to be considered. A detailed threat description of
these protocols is outside the scope of this document.
5. Security Considerations
This entire memo discusses security issues relevant for NSIS protocol
design. It begins by identifying the components of a network running
NSIS (Initiator, Responder, and different Administrative Domains
between them). It then considers five cases in which communications
take place between these components, and it examines the trust
relationships presumed to exist in each case: First-Peer
Communications, End-to-Middle Communications, Intra-Domain
Communications, Inter-Domain Communications, and End-to-End
Communications. This analysis helps determine the security needs and
the relative seriousness of different threats in the different cases.
The document points out the need for different protocol security
measures: authentication, key exchange, message integrity, replay
protection, confidentiality, authorization, and some precautions
against denial of service. The threats are subdivided into generic
ones (e.g., man-in-the-middle attacks, replay attacks, tampering and
forgery, and attacks on security negotiation protocols) and eleven
threat scenarios that are particularly applicable to the NSIS
protocol. Denial of service, for example, is covered in the
NSIS-specific section, not because it cannot be carried out against
other protocols, but because the methods used to carry out denial of
service attacks tend to be protocol specific. Numerous illustrative
examples provide insight into what can happen if these threats are
not mitigated.
This document repeatedly points out that not all of the threats are
equally serious in every context. It does attempt to identify the
scenarios in which security failures may have the highest impact.
However, it is difficult for the protocol designer to foresee all the
ways in which NSIS protocols will be used or to anticipate the
security concerns of a wide variety of likely users. Therefore, the
protocol designer needs to offer a full range of security
capabilities and ways for users to negotiate and select what they
need, on a case-by-case basis. To counter these threats, security
requirements have been listed in [RFC3726].
6. Contributors
We especially thank Richard Graveman, who provided text for the
security considerations section, as well as a detailed review of the
document.
7. Acknowledgements
We would like to thank (in alphabetical order) Marcus Brunner, Jorge
Cuellar, Mehmet Ersue, Xiaoming Fu, and Robert Hancock for their
comments on an initial version of this document. Jorge and Robert
gave us an extensive list of comments and provided information on
additional threats.
Jukka Manner, Martin Buechli, Roland Bless, Marcus Brunner, Michael
Thomas, Cedric Aoun, John Loughney, Rene Soltwisch, Cornelia Kappler,
Ted Wiederhold, Vishal Sankhla, Mohan Parthasarathy, and Andrew
McDonald provided comments on more recent versions of this document.
Their input helped improve the content of this document. Roland
Bless, Michael Thomas, Joachim Kross, and Cornelia Kappler, in
particular, provided good proposals for regrouping and restructuring
the material.
A final review was given by Michael Richardson. We thank him for his
detailed comments.
8. References
8.1. Normative References
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. van
den Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005.
[RFC3726] Brunner, M., "Requirements for Signaling Protocols",
RFC 3726, April 2004.
8.2. Informative References
[ALN00] Aura, T., Leiwo, J., and P. Nikander, "Towards Network
Denial of Service Resistant Protocols, In Proceedings
of the 15th International Information Security
Conference (IFIP/SEC 2000), Beijing, China",
August 2000.
[AN97] Aura, T. and P. Nikander, "Stateless Connections", In
Proceedings of the International Conference on
Information and Communications Security (ICICS’97),
Lecture Notes in Computer Science 1334, Springer",
1997.
[2LEVEL] Braden, R. and B. Lindell, "A Two-Level Architecture
for Internet Signaling", Work in Progress,
November 2002.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S.
Deering, "IPv6 Flow Label Specification", RFC 3697,
March 2004.
[NATFW-NSLP] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer
Protocol (NSLP)", Work in Progress, February 2005.
[GIMPS] Schulzrinne, H., "GIMPS: General Internet Messaging
Protocol for Signaling", Work in Progress,
February 2005.
[QOS-NSLP] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service signaling", Work in Progress,
February 2005.
[RSVP-SEC] Tschofenig, H., "RSVP Security Properties", Work in
Progress, February 2005.
[SIG-ANAL] Manner, J. and X. Fu, "Analysis of Existing Quality-
of-Service Signaling Protocols", RFC 4094, May 2005.
[RFC1809] Partridge, C., "Using the Flow Label Field in IPv6",
RFC 1809, June 1995.
[RFC2745] Terzis, A., Braden, B., Vincent, S., and L. Zhang,
"RSVP Diagnostic Messages", RFC 2745, January 2000.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore,
T., Herzog, S., and R. Hess, "Identity Representation
for RSVP", RFC 3182, October 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[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.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats",
RFC 3756, May 2004.
Authors’ Addresses
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Dirk Kroeselberg
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Dirk.Kroeselberg@siemens.com
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.