Skip to main content

Security Threats for Next Steps in Signaling (NSIS)
draft-ietf-nsis-threats-06

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4081.
Authors Dirk Kroeselberg , Hannes Tschofenig
Last updated 2013-03-02 (Latest revision 2004-10-26)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 4081 (Informational)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Allison J. Mankin
Send notices to john.loughney@nokia.com
draft-ietf-nsis-threats-06
NSIS Working Group                                         H. Tschofenig
Internet-Draft                                            D. Kroeselberg
Expires: April 24, 2005                                          Siemens
                                                        October 24, 2004

                       Security Threats for NSIS
                     draft-ietf-nsis-threats-06.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 24, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This threats document provides a detailed analysis of the security
   threats relevant to the NSIS protocol suite.  It calls attention to,
   and helps with the understanding of, various security considerations
   in the NSIS Requirements, Framework, and Protocol proposals.  This
   document does not describe vulnerabilities of specific parts of the
   NSIS protocol suite.

Tschofenig & Kroeselberg    Expires April 24, 2005              [Page 1]
Internet-Draft         Security Threats for NSIS            October 2004

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Communications Models  . . . . . . . . . . . . . . . . . . .   4
   3.   Generic Threats  . . . . . . . . . . . . . . . . . . . . . .   9
     3.1  Man-in-the-Middle Attacks  . . . . . . . . . . . . . . . .   9
     3.2  Replay of Signaling Messages . . . . . . . . . . . . . . .  13
     3.3  Injecting or Modifying Messages  . . . . . . . . . . . . .  13
     3.4  Insecure Parameter Exchange and Negotiation  . . . . . . .  13
   4.   NSIS-Specific Threat Scenarios . . . . . . . . . . . . . . .  15
     4.1  Threats during NSIS SA Usage . . . . . . . . . . . . . . .  15
     4.2  Flooding . . . . . . . . . . . . . . . . . . . . . . . . .  15
     4.3  Eavesdropping and Traffic Analysis . . . . . . . . . . . .  17
     4.4  Identity Spoofing  . . . . . . . . . . . . . . . . . . . .  17
     4.5  Unprotected Authorization Information  . . . . . . . . . .  19
     4.6  Missing Non-Repudiation  . . . . . . . . . . . . . . . . .  20
     4.7  Malicious NSIS Entity  . . . . . . . . . . . . . . . . . .  21
     4.8  Denial of Service Attacks  . . . . . . . . . . . . . . . .  22
     4.9  Disclosing the Network Topology  . . . . . . . . . . . . .  23
     4.10   Unprotected Session or Reservation Ownership . . . . . .  23
     4.11   Attacks against the NTLP . . . . . . . . . . . . . . . .  25
   5.   Security Considerations  . . . . . . . . . . . . . . . . . .  26
   6.   Contributors . . . . . . . . . . . . . . . . . . . . . . . .  27
   7.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  28
   8.   References . . . . . . . . . . . . . . . . . . . . . . . . .  29
   8.1  Normative References . . . . . . . . . . . . . . . . . . . .  29
   8.2  Informative References . . . . . . . . . . . . . . . . . . .  29
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  30
        Intellectual Property and Copyright Statements . . . . . . .  32

Tschofenig & Kroeselberg    Expires April 24, 2005              [Page 2]
Internet-Draft         Security Threats for NSIS            October 2004

1.  Introduction

   Whenever a new protocol is developed or existing protocols are
   modified, threats to their security should be evaluated.  To address
   security in the NSIS working group, a number of steps have been
   taken:

      NSIS Analysis Activities (see [I-D.ietf-nsis-rsvp-sec-properties]
      and [I-D.ietf-nsis-signalling-analysis])

      Security Threats for NSIS

      NSIS Requirements (see [RFC3726])

      NSIS Framework (see [I-D.ietf-nsis-fw])

      NSIS Protocol Suite (see GIMPS [I-D.ietf-nsis-ntlp], NAT/Firewall
      NSLP [I-D.ietf-nsis-nslp-natfw] and QoS NSLP
      [I-D.ietf-nsis-qos-nslp])

   This document identifies the basic security threats that need to be
   addressed during the design of the NSIS protocol suite.  Even if the
   base protocol is secure, certain extensions may cause problems when
   used in a particular environment.

   This document cannot provide detailed threats for all possible NSIS
   Signaling Layer Protocols (NSLPs).  QoS [I-D.ietf-nsis-qos-nslp],
   NAT/Firewall and other NSLP documents need to provide a description
   of their trust models and a threat assessment for their specific
   application domain.  This document aims to provide some help for the
   subsequent design of the NSIS protocol suite.  Investigations of
   security threats in a specifc architecture or context are outside the
   scope of this document.

   We use the NSIS terms defined in [RFC3726] and in [I-D.ietf-nsis-fw].

Tschofenig & Kroeselberg    Expires April 24, 2005              [Page 3]
Internet-Draft         Security Threats for NSIS            October 2004

2.  Communications Models

   The NSIS suite of protocols is envisioned to support various
   signaling applications that need to install and/or manipulate state
   at nodes along the data flow path through the network.  As such, the
   NSIS protocol suite involves the communication between different
   entities.

   This section offers terminology for common communication models,
   which are relevant to securing the NSIS protocol suite.

   An abstract network topology with its administrative domains is shown
   in Figure 1 and in Figure 2 the relationship between NSIS entities
   along the path is illustrated.  For illustrative reasons only
   end-to-end NSIS signaling is depicted but it might be used in other
   variations as well.  Signaling can start at any place and might
   terminate at any other place within the network.  Depending on the
   trust relationship between NSIS entities and the traversed network
   parts different security problems arise.

   The notion of trust and trust relationship used in this document is
   informal and can be best captured by the definition provided in
   Section 1.1 of [RFC3756].  For completeness we include the definition
   of a trust relationship which denotes a mutual a priori relationship
   between the involved organizations or parties where the parties
   believe that the other parties will behave correctly even in the
   future.

   An important observation for NSIS is that a certain degree of trust
   has to be placed into intermediate NSIS nodes along the path between
   an NSIS Initiator and an NSIS Responder, specifically that they
   perform message processing and take the necessary actions.  A
   complete lack of trust between any of the participating entities will
   cause NSIS signaling to fail.

   Please note that it is not possible to completely describe a trust
   model without considering the details and behavior of the NTLP, the
   NSLP (e.g., QoS NSLP) and the deployment environment.  For example,
   securing the communication between an end host (which acts as the
   NSIS Initiator) and the first NSIS node (which might be in the
   attached network or even a number of networks away) is impacted by
   the trust relationships between these entities.  In a corporate
   network environment a stronger degree of trust typically exists than
   in an unmanaged network.

   Figure 1 introduces convenient abbreviations for network parts with
   similar properties: first-peer, last-peer, intra-domain, or
   inter-domain.

Tschofenig & Kroeselberg    Expires April 24, 2005              [Page 4]
Internet-Draft         Security Threats for NSIS            October 2004

     +------------------+   +---------------+   +------------------+
     |                  |   |               |   |                  |
     |  Administrative  |   | Intermediate  |   |  Administrative  |
     |     Domain A     |   |   Domains     |   |     Domain B     |
     |                  |   |               |   |                  |
     |                 (Inter-domain Communication)                |
     |        +-------->+---+<------------->+---+<--------+        |
     |  (Intra-domain   |   |               |   | (Intra-domain    |
     |   Communication) |   |               |   |  Communication)  |
     |        |         |   |               |   |         |        |
     |        v         |   |               |   |         v        |
     +--------+---------+   +---------------+   +---------+--------+
              ^                                           ^
              |                                           |
     First Peer Communication               Last Peer Communication
              |                                           |
              v                                           v
        +-----+-----+                               +-----+-----+
        |   NSIS    |                               |   NSIS    |
        | Initiator |                               | Responder |
        +-----------+                               +-----------+

                Figure 1: Communication patterns in NSIS

   First-Peer/Last-Peer Communication:

      The end-to-end communication scenario depicted in Figure 1
      includes the communication between the end hosts and their nearest
      NSIS hops.  "First-peer communications" refers to the peer-to-peer
      interaction between a signaling message originator, the NSIS
      Initiator (NI), and the first NSIS-aware entity along the path.
      This "first-peer communications" commonly comes with specific
      security requirements that are especially important for addressing
      security issues between the end host (and a user) and the network
      it is attached to.

      To illustrate this, in roaming environments it is difficult to
      assume the existence of a pre-established security association
      directly available for NSIS peers involved in first-peer
      communications, because these peers cannot be assumed to have any
      pre-existing relationship with each other.  For enterprise
      networks, in contrast, the situation is different.  Usually there
      is a fairly strong (pre-established) trust relationship between
      the peers.  Enterprise network administrators usually have some
      degree of freedom to select the appropriate security protection
      and to enforce it.  The choice of selecting a security mechanism
      is therefore often influenced by the already available
      infrastructure, and per-session negotiation of security mechanisms

Tschofenig & Kroeselberg    Expires April 24, 2005              [Page 5]
Internet-Draft         Security Threats for NSIS            October 2004

      is often not required (which, in contrast, is required in a
      roaming environment).

      Last-Peer communication is a variation of First-Peer communication
      where the roles are reversed.

   Intra-Domain Communication:

      After verification of the NSIS signaling message at the border of
      an administrative domain, an NSIS signaling message traverses the
      network within the same administrative domain to which the first
      peer belongs.  It might not be necessary to repeat the
      authorization procedure of the NSIS initiator again at every NSIS
      node within this domain.  Key management within the administrative
      domain might also be simpler.

      Security protection is still required to prevent threats by
      non-NSIS nodes in this network.

   Inter-Domain Communication:

      Inter-Domain communication deals with the interaction between
      administrative domains.  For some NSLPs (for example QoS NSLP)
      this interaction is likely to take place between neighboring
      domains whereas in other NSLPs (such as the NAT/Firewall NSLP) the
      core network is usually not involved.

      If signaling messages are conveyed transparently in the core
      network (i.e., they are neither intercepted nor processed in the
      core network), then the signaling message communications
      effectively takes place between access networks.  This might place
      a burden on authorization handling and on the key management
      infrastructure required between these access networks, which might
      not know of each other in advance.

   To refine the above differentiation based on the network parts that
   NSIS signaling may traverse, we subsequently consider relationships
   between involved entities.  Since a number of NSIS nodes might
   actively participate in a specific protocol exchange, a larger number
   of possible relationships need to be analyzed than in other
   protocols.  Figure 2 illustrates possible relationships between the
   entities involved in the NSIS protocol suite.

Tschofenig & Kroeselberg    Expires April 24, 2005              [Page 6]
Internet-Draft         Security Threats for NSIS            October 2004

                 ****************************************
                 *                                      *
            +----+-----+       +----------+        +----+-----+
      +-----+  NSIS    +-------+  NSIS    +--------+  NSIS    +-----+
      |     |  Node 1  |       |  Node 2  |        |  Node 3  |     |
      |     +----------+       +----+-----+        +----------+     |
      |                             ~                               |
      |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~                               |
      |  ~                                                          |
   +--+--+-----+                                          +---------+-+
   |   NSIS    +//////////////////////////////////////////+   NSIS    |
   | Initiator |                                          | Responder |
   +-----------+                                          +-----------+

    Legend:
     -----: Peer-to-Peer Relationship
     /////: End-to-End Relationship
     *****: Middle-to-Middle Relationship
     ~~~~~: End-to-Middle Relationship

                 Figure 2: Possible NSIS Relationships

   End-to-Middle Communications:

      The scenario in which one NSIS entity involved is an end-entity
      (Initiator or Responder) and the other entity is any intermediate
      hop other than the immediately adjacent peer is typically called
      the end-to-middle scenario (see Figure 2).  A motivation for
      including this scenario can, for example, be found in SIP
      [RFC3261].

      An example of end-to-middle interaction might be an explicit
      authorization from the NSIS Initiator to some intermediate node.
      Threats specific to this scenario may be introduced by some
      intermediate NSIS hops which are not allowed to eavesdrop or
      modify certain objects.

   Middle-to-Middle Communications:

      Middle-to-middle communication refers to the exchange of
      information between two non-neighboring NSIS nodes along the path.
      Intermediate NSIS hops may have to deal with specific security
      threats, which do not directly involve the NSIS Initiator or the
      NSIS Responder.

Tschofenig & Kroeselberg    Expires April 24, 2005              [Page 7]
Internet-Draft         Security Threats for NSIS            October 2004

   End-to-End Communications:

      NSIS aims to signal information from an Initiator to some NSIS
      nodes along the path to a data receiver.  In case of end-to-end
      NSIS signaling the last node is the NSIS Responder as the data
      receiver.  The NSIS protocol suite is not an end-to-end protocol
      used to exchange information purely between end hosts.

      Typically, it is not required to cryptographically protect NSIS
      messages between the NSIS Initiator and the NSIS Responder.
      Protecting the entire signaling message end-to-end is not feasible
      since intermediate NSIS nodes need to add, inspect, modify or
      delete objects from the signaling message.

Tschofenig & Kroeselberg    Expires April 24, 2005              [Page 8]
Internet-Draft         Security Threats for NSIS            October 2004

3.  Generic Threats

   This section provides scenarios of threats that are applicable to
   signaling protocols in general.  Note that some of these scenarios
   use the term user instead of NSIS Initiator.  This is mainly because
   security protocols allow differentiation between entities as hosts
   and as users (based on the identifiers used).

   For the following subsections, we use the general distinction into
   two cases in which attacks may occur.  These are according to the
   separate steps, or phases, normally encountered when applying
   protocol security (with, e.g., IPsec, TLS, Kerberos, or SSH).
   Therefore, this section starts with a brief motivation for this
   separation.

   Security protection of protocols is often separated into two steps.
   The first step provides primarily entity authentication and key
   establishment (which result in a persistent state often called a
   security association), whereas the second step provides message
   protection (some combination of data origin authentication, data
   integrity, confidentiality, and replay protection) using the
   previously established security association.  The first step tends to
   be more expensive than the second, which is the main reason for the
   separation.  If messages are transmitted infrequently, then these two
   steps may be collapsed into a single and usually rather costly one.
   One such example is e-mail protection via S/MIME.  The two steps may
   be tightly bound into a single protocol, as in TLS, or defined in
   separate protocols, as with IKE and IPsec.  We use this separation to
   cover the different threats in more detail.

3.1  Man-in-the-Middle Attacks

   This section describes both security threats that exist if two peers
   do not already share a security association or do not use security
   mechanisms at all, and threats that are applicable when a security
   association is already established.

   Attacks during NSIS SA Establishment:

      While establishing a security association, an adversary fools the
      signaling message Initiator with respect to the entity to which it
      has to authenticate.  The Initiator authenticates to the
      man-in-the-middle adversary, who is then able to modify signaling
      messages to mount DoS attacks or steal services that get billed to
      the Initiator.  In addition, it may be able to terminate the
      Initiator's NSIS messages and inject messages to a peer itself,
      therefore acting as the peer to the Initiator and as the Initiator
      to the peer.  This results in the Initiator wrongly believing that

Tschofenig & Kroeselberg    Expires April 24, 2005              [Page 9]
Internet-Draft         Security Threats for NSIS            October 2004

      it is talking to the "real" network, whereas it is actually
      attached to an adversary.  For this attack to be successful,
      pre-conditions have to hold which are described in the following
      three cases:

      Missing Authentication:

         In the first case, this threat can be carried out because of
         missing authentication between neighboring peers: without
         authentication a NI, NR, or NF is unable to detect an
         adversary.  However, in some practical cases authentication
         might be difficult to accomplish, either because the next peer
         is unknown, because of misbelieved trust relationships in parts
         of the network, or because of the inability to establish proper
         security protection (inter-domain signaling messages, dynamic
         establishment of a security association, etc.).  If one of the
         communicating endpoints is unknown, then for some security
         mechanisms it is either impossible, or impractical to apply
         appropriate security protection.  Sometimes network
         administrators use intra-domain signaling messages without
         proper security.  Such a configuration would then allow an
         adversary on a compromised non-NSIS-aware node to interfere
         with nodes running an NSIS signaling protocol.  Note that this
         type of threat goes beyond those caused by malicious NSIS nodes
         (described in Section 4.7).

      Unilateral Authentication:

         In the case of unilateral authentication, the NSIS entity that
         does not authenticate its peer is unable to discover a
         man-in-the-middle adversary.  Although mutual authentication of
         signaling messages should take place between each peer
         participating in the protocol operation, special attention is
         given here to first-peer communications.  Unilateral
         authentication between an end host and the first peer (just
         authenticating the end host) is still common today, but it
         opens up many possibilities for man-in-the-middle attackers
         impersonating either the end host or the (administrative domain
         represented by the) first peer.

         Missing or unilateral authentication, as described above, is
         part of a general problem of network access with inadequate
         authentication, and it should not be considered something
         unique to the NSIS signaling protocol.  Obviously, there is a
         strong need to correctly address this in a future NSIS protocol

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 10]
Internet-Draft         Security Threats for NSIS            October 2004

         suite.  The signaling protocols addressed by NSIS are different
         from other protocols, in which only two entities are involved.
         Note that first-peer authentication is especially important,
         because a security breach here could impact nodes beyond the
         entities directly involved (or even beyond a local network).

         Finally it should be noted that the signaling protocol should
         be considered as a peer-to-peer protocol, where the roles of
         Initiator and Responder can be reversed at any time.  Hence,
         unilateral authentication is not particularly useful for such a
         protocol.  However, there might be a need to have some form of
         asymmetry in the authentication process, whereby one entity
         uses a different authentication mechanism than the other one.
         As an example, the combination of symmetric and asymmetric
         cryptography should be mentioned.

      Weak Authentication:

         In this case, the threat can be carried out because of weak
         authentication mechanisms whereby information transmitted
         during the NSIS SA establishment process may leak passwords or
         allow offline dictionary attacks.  This threat is applicable to
         NSIS for the process of selecting certain security mechanisms.

   Finally, we conclude a description of a man-in-the-middle attack
   during the discovery phase.  This attack benefits from the fact that
   NSIS nodes are likely to be unaware of the network topology.
   Furthermore, an authorization problem might arise if an NSIS QoS NSLP
   node pretends to be a NSIS NAT/Firewall specific node or vice versa.

   An adversary might want to inject a bogus reply message forcing the
   discovery message initiator to start a messaging association
   establishment with either an adversary or with another NSIS node
   which is not along the path.  Figure 3 describes the attack in more
   detail for peer-to-peer addressed messages with a discovery
   mechanism.  For end-to-end addressed messages the attack is also
   applicable particularly if the adversary is located along the path
   and able to intercept the discovery message which traverses the
   adversary.  The man-in-the-middle adversary might redirect to another
   legimimate NSIS node.  A malicious NSIS node can be detected with the
   corresponding security mechanisms but a legitimate NSIS node which is
   not the next NSIS node along the path cannot be detected without
   having topology knowledge.

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 11]
Internet-Draft         Security Threats for NSIS            October 2004

                      +-----------+   Messaging Association
     Message          | Adversary |   Establishment
     Association +--->+           +<----------------+
     Establish-  |    +----+------+                 |(4)
      ment       |     IPx |                        |
              (3)|         |Discovery Reply         v
                 |         | (IPx)              +---+-------+
                 v         |  (2)               |  NSIS     |
          +------+-----+   |       /----------->+  Node B   +--------
          | NSIS       +<--+      / Discovery   +-----------+
          | Node A     +---------/  Request          IPr
          +------------+             (1)
              IPi

          Figure 3: MITM Attack during the Discovery Exchange

   This attack assumes that the adversary is able to eavesdrop the
   initial discovery message sent by the sender of the discovery
   message.  Furthermore, we assume that the discovery reply message by
   the adversary returns to the discovery message initiator faster than
   the real response.  This represents some race condition
   characteristics if the next NSIS node is very close (in IP-hop terms)
   to the initiator.  It should be noted that the process is
   self-healing since the discovery process is periodically
   retransmitted.  If an adversary is unable to mount this attack with
   every discovery message then the correct next NSIS node along the
   path will be discovered again.  A ping-pong behavior might be the
   consequence.

   As shown in message step (2) in Figure 3 the adversary returns a
   discovery reply message with its own IP address as the next NSIS
   aware node along the path.  Without any additional information the
   discovery message initiator has to trust this information.  Then a
   messaging association is established with an entity at a given IP
   address IPx (i.e., with the adversary) in step (3).  The adversary
   then establishes a messaging association with a further NSIS node and
   forwards the signaling message.  Note that the adversary might just
   modify the Disovery Reply message to force NSIS Node A to establish a
   messaging association with another NSIS node which is not along the
   path.  This can then be exploited by the adversary.  Particularly the
   interworking with NSIS unaware NATs might cause additional unexpected
   problems.

   As a variant of this attack an adversary not able to eavesdrop
   transmitted discovery requests could flood a node with bogus
   discovery reply messages.  If the discovery message sender
   accidentally accepts one of those bogus messages then a MITM-attack
   as described in Figure 3 is possible.

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 12]
Internet-Draft         Security Threats for NSIS            October 2004

3.2  Replay of Signaling Messages

   This threat scenario covers the case in which an adversary eavesdrops
   and collects signaling messages and replays them at a later time (or
   at a different place, or uses parts of them at a different place or
   in a different way, e.g., cut-and-paste attacks).  Without proper
   replay protection, an adversary might mount man-in-the-middle, denial
   of service, and theft of service attacks.

   A more difficult attack that may cause problems even in case of
   replay protection requires the adversary to crash an NSIS-aware node,
   causing it to lose state information (sequence numbers, security
   associations, etc.), and then be able to replay old signaling
   messages.  This attack takes advantage of re-synchronization
   deficiencies.

3.3  Injecting or Modifying Messages

   This type of threat involves integrity violations, whereby an
   adversary modifies signaling messages (e.g., by acting as a
   man-in-the-middle) to cause unexpected network behavior.  Possible
   actions an adversary might consider for its attack are reordering,
   delaying, dropping, injecting, truncating, and otherwise modifying
   messages.

   An adversary may inject a signaling message requesting a large amount
   of resources (possibly using a different user's identity).  Other
   resource requests may then be rejected.  In combination with identity
   spoofing, it is also possible to carry out fraud.  This attack is
   only feasible in the absence of authentication and signaling message
   protection.

   Some threats directly related to these are described in Section 4.4,
   Section 4.7, and Section 4.8.

3.4  Insecure Parameter Exchange and Negotiation

   First, protocols may be useful in a variety of scenarios with
   different security requirements.  Second, different users (e.g., a
   university, a hospital, a commercial enterprise, or a government
   ministry) have inherently different security requirements.  Third,
   different parts of a network (e.g., within a building, across a
   public carrier's network, or over a private microwave link) may need
   different levels of protection.  It is often difficult to meet these
   (sometimes conflicting) requirements with a single security mechanism
   or fixed set of security parameters, so often a selection of
   mechanisms and parameters is offered.  Therefore, a protocol is
   required to agree on certain security mechanisms and parameters.  An

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 13]
Internet-Draft         Security Threats for NSIS            October 2004

   insecure parameter exchange or security negotiation protocol can help
   an adversary mount a downgrading attack to force selection of weaker
   mechanisms than mutually desired.  Hence, without binding the
   negotiation process to the legitimate parties and protecting it, an
   NSIS protocol suite might be only as secure as the weakest mechanism
   provided (e.g., weak authentication), and the benefits of defining
   configuration parameters and a negotiation protocol are lost.

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 14]
Internet-Draft         Security Threats for NSIS            October 2004

4.  NSIS-Specific Threat Scenarios

   This section describes 11 threat scenarios in terms of attacks on and
   security deficiencies in the NSIS signaling protocol.  A number of
   security deficiencies might enable an attack.  Fraud is an example of
   an attack that might be enabled by missing replay protection, missing
   protection of authorization tokens, identity spoofing, missing
   authentication, and other deficiencies that help an adversary steal
   resources.  Different threat scenarios based on deficiencies that
   could enable an attack are addressed in this section.

   The threat scenarios are not independent.  Some of them, e.g., denial
   of service, are well-established security terms and, as such, need to
   be addressed, but are often enabled by one or more deficiencies
   described under other scenarios.

4.1  Threats during NSIS SA Usage

   Once a security association is established (and used) to protect
   signaling messages, many basic attacks are prevented.  However, a
   malicious NSIS node is still able to perform various attacks as
   described in Section 4.7.  Replay attacks may be possible when an
   NSIS node crashes, restarts, and performs state re-establishment.
   Proper re-synchronization of the security mechanism must therefore be
   provided to address this problem.

4.2  Flooding

   This section describes attacks that allow an adversary to flood an
   NSIS node with bogus signaling messages to cause a denial of service
   attack.

   We will discuss this threat at different layers in the NSIS protocol
   suite:

   Processing of Router Alert Options:

      The processing of Router Alert Option (RAO) requires a router to
      do some additional processing by intercepting packets with IP
      options, which might lead to additional delay for legitimate
      requests, or even to reject some of them.  A router being flooded
      with a large number of bogus messages requires resources before
      finding out that these messages have to be dropped.

      If the protocol is based on using interception for message
      delivery this threat cannot be completely eliminated, but the
      protocol design should attempt to limit the processing that has to
      be done on the RAO-bearing packet so that it is as similar as

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 15]
Internet-Draft         Security Threats for NSIS            October 2004

      possible to that for an arbitrary packet addressed directly to one
      of the router interfaces.

   Attacks against the Transport Layer protocol:

      Certain attacks can be mounted against transport protocols by
      flooding a node with bogus requests or even to finish the
      handshake phase to establish a transport layer association.  These
      types of threats are also addressed in Section 4.11.

   Force NTLP to do more processing:

      Some protocol fields might allow an adversary to force an NTLP
      node to perform more processing.  Additionally it might be
      possible to interfere with the flow control or the congestion
      control procedure.  These types of threats are also addressed in
      Section 4.11.

      Furthermore, it might be possible to force the NTLP node to
      perform some computations or signaling message exchanges by
      injecting "trigger" events (which are unprotected).

   Force NSLP to-do more processing:

      An adversary might benefit from flooding an NSLP node with
      messages which must be stored (e.g., due to fragmentation
      handling) before verifying the correctness of signaling messages.

      Furthermore, causing memory allocation and computational efforts
      might allow an adversary to do harm to NSIS entities.  If a
      signaling message contains, for example, a digital signature then
      some additional processing is required for the cryptographic
      verification.  An adversary can easily create a random bit
      sequence instead of a digital signature to force an NSIS node into
      heavy computation.

      Idempotent signaling messages are particularly vulnerable to this
      type of attack.  Idempotent refers to messages which contain the
      same amount of information as the original message.  An example
      would be a refresh message that is equivalent to a create message.
      This property allows a refresh message to create state along a new
      path, where no previous state is available.  For this to work,
      specific classes of cryptographic mechanisms supporting this
      behavior are needed.  An example is a scheme based on digital
      signatures, which, however, should be used with care due to

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 16]
Internet-Draft         Security Threats for NSIS            October 2004

      possible denial of service attacks.

      Problems with the usage of public key based cryptosystems in
      protocols are described in [AN97] and in [ALN00].

      In addition to the threat scenario described above, an incoming
      signaling message might trigger communication with third-party
      nodes such as policy servers, LDAP servers or AAA servers.  If an
      adversary is able to transmit a large number of signaling messages
      (for example, with QoS reservation requests) with invalid
      credentials, then the verifying node may not be able to process
      other reservation messages from legitimate users.

4.3  Eavesdropping and Traffic Analysis

   This section covers threats whereby an adversary is able to eavesdrop
   on signaling messages.  The signaling packets collected may allow
   traffic analysis or be used later to mount replay attacks, as
   described in Section 3.2.  The eavesdropper might learn QoS
   parameters, communication patterns, policy rules for firewall
   traversal, policy information, application identifiers, user
   identities, NAT bindings, authorization objects, network
   configuration and performance information, and more.

   An adversary's capability to eavesdrop on signaling messages might
   violate a user's preference for privacy, particularly if unprotected
   authentication or authorization information (including policies and
   profile information) is exchanged.

   Because the NSIS protocol signals messages through a number of nodes,
   it is possible to differentiate between nodes actively participating
   in the NSIS protocol and others that do not actively participate in
   the NSIS protocol.  For certain objects or messages it might be
   desirable to permit actively participating intermediate NSIS nodes to
   eavesdrop.  On the other hand, it might be desirable that only the
   intended end points (NSIS Initiator and NSIS Responder) are able to
   read certain other objects.

4.4  Identity Spoofing

   Identity spoofing relevant for NSIS occurs in three forms: first,
   identity spoofing can happen during the establishment of a security
   association based on a weak authentication mechanism.  Second, an
   adversary can modify the flow identifier carried within a signaling
   message and third, it can spoof data traffic.

   In the first case, Eve, acting as an adversary, may claim to be the

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 17]
Internet-Draft         Security Threats for NSIS            October 2004

   registered user Alice by spoofing Alice's identity.  Eve thereby
   causes the network to charge Alice for the network resources
   consumed.  This type of attack is possible if authentication is based
   on a simple username identifier (i.e., in absence of cryptographic
   authentication), or if authentication is provided for hosts, and
   multiple users have access to a single host.  This attack could also
   be classified as theft of service.

   In the second case, an adversary may be able to exploit the
   established flow identifiers (required for QoS and NAT/FW NSLP).
   These identifiers are, among others, IP addresses, transport protocol
   type (UDP, TCP), port numbers, and flow labels (see [RFC1809] and
   [I-D.ietf-ipv6-flow-label]).  Modification of these flow identifiers
   allows adversaries to exploit or to render ineffective quality of
   service reservations or policy rules at middleboxes.  An adversary
   could mount an attack by modifying the flow identifier of a signaling
   message.

   In the third case, an adversary may spoof data traffic.  NSIS
   signaling messages contain some sort of flow identifier, which is
   associated with a specified behavior (e.g., a particular flow
   experiences QoS treatment or allows packets to traverse a firewall).
   An adversary might, therefore, use IP spoofing and inject data
   packets to benefit from previously installed flow identifiers.

   We will provide an example of the latter threat.  After NSIS nodes
   along the path between the NSIS initiator and the NSIS receiver
   processes a properly protected reservation request, transmitted by
   the legitimate user Alice, a QoS reservation is installed at the
   corresponding NSIS nodes (for example, the edge router).  The flow
   identifier is used for flow identification and allows data traffic
   originated from a given source to be assigned to this QoS
   reservation.  The adversary Eve now spoofs the IP address of Alice.
   In addition, Alice's host may be crashed by the adversary with a
   denial of service attack or may lose connectivity, for example,
   because of mobility.  If Eve is able to perform address spoofing then
   she is able to receive and transmit data (for example RTP data
   traffic) that receives preferential QoS treatment based on the
   previous reservation.  Depending on the installed flow identifier
   granularity, Eve might have more possibilities to exploit the QoS
   reservation or a pin-holed firewall.  Assuming the soft state
   paradigm, whereby periodic refresh messages are required, the absence
   of Alice will not be detected until a refresh message is required and
   forces Eve to respond with a protected signaling message.  Again,
   this attack is applicable not just to QoS traffic and the same attack
   is also applicable to a Firewall control protocol, with a different
   consequence.

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 18]
Internet-Draft         Security Threats for NSIS            October 2004

   The ability for an adversary to inject data traffic that matches a
   certain flow identifier established by a legitimate user and to get
   some benefit from injecting that traffic often requires the ability
   also to receive the data traffic or to have one's correspondent
   receive it.  For example, an adversary in an unmanaged network
   observes a NAT/Firewall signaling message towards a corporate
   network.  After the signaling message exchange was successful user
   Alice is allowed to traverse the company firewall based on the
   establish packet filter to contact her internal mail server.  Now,
   adversary Eve, which was monitoring the signaling exchange is able to
   build a data packet towards this mail server which will pass the
   company firewall.  The packet will hit the mail server and cause some
   actions and the mail server will reply with some response messages.
   Depending on the exact location of the adversary and the degree of
   routing asymmetry the adversary might even see the response messages.
   Note that for this attack to work Alice does not need to participate
   in the exchange of signaling messages.

   If we imagine using attributes of a flow identifier that is not
   related to source and destination addresses.  As an example, we could
   think of a flow identifier where only the 21-bit Flow ID is used
   (without source and destination IP address).  Identity spoofing and
   injecting traffic is much easier since a packet only needs to be
   marked and an adversary can use a nearly arbitrary endpoint
   identifier to achieve the desired result.  Obviously, though, the
   endpoint identifiers are not irrelevant, because the messages have to
   hit some nodes in the network where NSIS signaling messages installed
   state (e.g., in the above example they would have to hit the same
   firewall.)

   Data traffic marking based on DiffServ is such an example.  Whenever
   an ingress router uses only marked incoming data traffic for
   admission control procedures, then various attacks are possible.
   These problems have been known in the DiffServ community for a long
   time and have been documented in various DiffServ-related documents.
   The IPsec protection of DiffServ Code Points is described in Section
   6.2 of [RFC2745].  Related security issues (for example denial of
   service attacks) are described in Section 6.1 of the same document.

4.5  Unprotected Authorization Information

   Authorization is an important criterion for providing resources such
   as QoS reservations, NAT bindings, and pinholes through firewalls.
   Authorization information might be delivered to the NSIS
   participating entities in a number of ways.

   Typically the authenticated identity is used to assist during the
   authorization procedure as, e.g., described in [RFC3182].  Depending

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 19]
Internet-Draft         Security Threats for NSIS            October 2004

   on the chosen authentication protocol, certain threats may exist.
   Section 3 discusses a number of issues related to this approach when
   the authentication and key exchange protocol is used to establish
   session keys for signaling message protection.

   Another approach is to use some sort of authorization token.  The
   functionality and structure of such an authorization token for RSVP
   is described in [RFC3520] and [RFC3521].

   Achieving secure interaction between different protocols based on
   authorization tokens, however, requires some care.  By using such an
   authorization token it is possible to link state information between
   different protocols.  Returning an unprotected authorization token to
   the end host might allow an adversary (for example an eavesdropper)
   to steal resources.  An adversary might also use the token to monitor
   communication patterns.  Finally, an untrustworthy end host might
   also modify the token content.

   The Session/Reservation Ownership problem can also be regarded as an
   authorization problem.  Details are described in Section 4.10.  In
   enterprise networks, authorization is often coupled with membership
   in a particular class of users or groups.  This type of information
   either can be delivered as part of the authentication and key
   agreement procedure or has to be retrieved via separate protocols
   from other entities.  If an adversary manages to modify information
   relevant for determining authorization or the outcome of the
   authorization process itself, then theft of service might be
   possible.

4.6  Missing Non-Repudiation

   Signaling for QoS often involves three parties: the user, a network
   that offer QoS reservations (referred as service provider) and a
   third party which guarantees that the party making the reservation
   actually receives a financial compensation (referred as trusted third
   party).

   Repudiation in this context refers to a problem where either the user
   or the service provider later deny about the existence or some
   parameters (e.g., volume or price) of a QoS reservation towards the
   trusted third party.  Problems stemming from a lack of
   non-repudiation appear in two forms:

   Service providers point-of-view:
      A user may deny having issued a reservation request for which it
      was charged.  The service provider may then want to be able to
      prove that a particular user issued the reservation request in
      question.

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 20]
Internet-Draft         Security Threats for NSIS            October 2004

   Users point-of-view:
      A service provider may claim to have received a number of
      reservation requests from a particular user.  The user in question
      may want to show that such a reservation requests have never been
      issued and may want to see correct service usage records for a
      given set of QoS parameters.

   In today's networks, non-repudiation is not provided.  As such, it
   might be difficult to introduce with NSIS signaling.  The user has to
   trust the network operator to meter the traffic correctly, collect
   and merge accounting data, and ensure that no unforeseen problems
   occur.  If a signaling protocol with the non-repudiation property is
   desired for establishing QoS reservations then it certainly impacts
   the protocol design.

   Non-repudiation functionality additional places requirements on the
   security mechanisms.  Hence, a solution would normally increase the
   overhead of a security solution.  Threats related to missing
   non-repudiation are only considered relevant in certain specific
   scenarios and for specific NSLPs.

4.7  Malicious NSIS Entity

   Network elements within a domain (intra-domain) experience a
   different trust relationship with regard to the security protection
   of signaling messages compared with edge NSIS entities.  It is
   assumed that edge NSIS entities are responsible for performing
   cryptographic processing (authentication, integrity and replay
   protection, authorization, and accounting) for signaling messages
   arriving from the outside.  This prevents unprotected signaling
   messages from appearing within the internal network.  If, however, an
   adversary manages to take over an edge router, then the security of
   the entire network is compromised.  An adversary is then able to
   launch a number of attacks including denial of service; integrity
   violations; replay, reordering of objects and messages, bundling of
   messages, and deletion of data packets; and various others.  A rogue
   firewall can harm other firewalls by modifying policy rules.  The
   chain-of-trust principle applied in peer-to-peer security protection
   cannot protect against a malicious NSIS node.  An adversary with
   access to a NSIS router is also able to get access to security
   associations and transmit secured signaling messages.  Note that even
   non-peer-to-peer security protection might not be able to prevent
   this problem fully.  Because an NSIS node might issue signaling
   messages on behalf of someone else (by acting as a proxy), additional
   problems need to be considered.

   An NSIS-aware edge router is a critical component that requires
   strong security protection.  A strong security policy applied at the

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 21]
Internet-Draft         Security Threats for NSIS            October 2004

   edge does not imply that other routers within an intra-domain network
   do not need to verify signaling messages cryptographically.  If the
   chain-of-trust principle is deployed, then the security protection of
   the entire path (in this case within the network of a single
   administrative domain) is as strong as the weakest link.  In the case
   under consideration, the edge router is the most critical component
   of this network, and it may also act as a security gateway or
   firewall for incoming and outgoing traffic.  For outgoing traffic
   this device has to implement the security policy of the local domain
   and apply the appropriate security protection.

   For an adversary to mount this attack, either an existing NSIS-aware
   node along the path has to be attacked successfully, or an adversary
   must succeed in convincing another NSIS node to make it the next NSIS
   peer (man-in-the-middle attack).

4.8  Denial of Service Attacks

   A number of denial of service (DoS) attacks can cause NSIS nodes to
   malfunction.  Other attacks that could lead to DoS, such as
   man-in-the-middle attacks, replay attacks, 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 not along the data path or to cause the discovery process

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 22]
Internet-Draft         Security Threats for NSIS            October 2004

      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 either at the
      signaling message protocol layer (NTLP), at the layer of each
      client layer protocol (e.g., QoS NSLP or NAT/Firewall NSLP), or at
      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).  In the case in which 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 together 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.  Hence, the requirement of not disclosing a network
   topology might conflict with other requirements to provide means for
   automatically discovering NSIS-aware nodes 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.

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 23]
Internet-Draft         Security Threats for NSIS            October 2004

                                             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 3),
   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.

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 24]
Internet-Draft         Security Threats for NSIS            October 2004

   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 [I-D.braden-2level-signal-arch] a two-level architecture is
   proposed, which suggests splitting an NSIS protocol into layers: a
   signaling message transport-specific layer and an
   application-specific layer.  This is further developed in the NSIS
   Framework [I-D.ietf-nsis-fw].  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 which address parts of the NTLP which are not related to
   attacks against the use of transport layer protocols are covered in
   various sections throughout this document, such as in Section 4.2.

   In the case in which 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.

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 25]
Internet-Draft         Security Threats for NSIS            October 2004

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 11 threat
   scenarios 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 points out repeatedly 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].

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 26]
Internet-Draft         Security Threats for NSIS            October 2004

6.  Contributors

   We especially thank Richard Graveman, who provided text for the
   security considerations section, besides a detailed review of the
   document.

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 27]
Internet-Draft         Security Threats for NSIS            October 2004

7.  Acknowledgments

   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 draft.  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 draft.
   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.

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 28]
Internet-Draft         Security Threats for NSIS            October 2004

8.  References

8.1  Normative References

   [I-D.ietf-nsis-fw]
              Hancock, R., "Next Steps in Signaling: Framework",
              draft-ietf-nsis-fw-06 (work in progress), July 2004.

   [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, <ALN00>.

   [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, <AN97>.

   [I-D.braden-2level-signal-arch]
              Braden, R. and B. Lindell, "A Two-Level Architecture for
              Internet Signaling", draft-braden-2level-signal-arch-01
              (work in progress), November 2002.

   [I-D.ietf-ipv6-flow-label]
              Rajahalme, J., Conta, A., Carpenter, B. and S. Deering,
              "IPv6 Flow Label Specification",
              draft-ietf-ipv6-flow-label-09 (work in progress), December
              2003.

   [I-D.ietf-nsis-nslp-natfw]
              Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer
              Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-03 (work in
              progress), July 2004.

   [I-D.ietf-nsis-ntlp]
              Schulzrinne, H., "GIMPS: General Internet Messaging
              Protocol for Signaling", draft-ietf-nsis-ntlp-03 (work in
              progress), July 2004.

   [I-D.ietf-nsis-qos-nslp]
              Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
              Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-04
              (work in progress), July 2004.

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 29]
Internet-Draft         Security Threats for NSIS            October 2004

   [I-D.ietf-nsis-rsvp-sec-properties]
              Tschofenig, H., "RSVP Security Properties",
              draft-ietf-nsis-rsvp-sec-properties-05 (work in progress),
              September 2004.

   [I-D.ietf-nsis-signalling-analysis]
              Manner, J., "Analysis of Existing Quality of Service
              Signaling Protocols",
              draft-ietf-nsis-signalling-analysis-04 (work in progress),
              May 2004.

   [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, Bayern  81739
   Germany

   EMail: Hannes.Tschofenig@siemens.com

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 30]
Internet-Draft         Security Threats for NSIS            October 2004

   Dirk Kroeselberg
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bayern  81739
   Germany

   EMail: Dirk.Kroeselberg@siemens.com

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 31]
Internet-Draft         Security Threats for NSIS            October 2004

Intellectual Property Statement

   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.

Disclaimer of Validity

   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.

Copyright Statement

   Copyright (C) The Internet Society (2004).  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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Tschofenig & Kroeselberg    Expires April 24, 2005             [Page 32]