NSIS
   Internet Draft Working Group                                         H. Tschofenig
Internet-Draft                                            D. Kroeselberg
                                                                 Siemens
   Document:
   draft-ietf-nsis-threats-04.txt
Expires: August December 21, 2004                                   February                                       Siemens
                                                           June 22, 2004

                       Security Threats for NSIS
                     <draft-ietf-nsis-threats-04.txt>
                     draft-ietf-nsis-threats-05.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of Section 10 which I am aware have been disclosed,
   and any of RFC2026. which I 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.

   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/1id-abstracts.html
   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
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 21, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

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

Table of Contents

   1. Introduction..................................................2   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2. Relevant   Communications Models................................3
      2.1 First-Peer Communications.................................5
      2.2 End-to-Middle Communications..............................6
      2.3 Intra-Domain Communications...............................6
      2.4 Inter-Domain Communications...............................6
      2.5 End-to-End Communications.................................7
      2.6 Middle-to-Middle Communications...........................8 Models  . . . . . . . . . . . . . . . . . . .   4
   3.   Generic Threats...............................................8 Threats  . . . . . . . . . . . . . . . . . . . . . .   9
     3.1  Man-in-the-Middle Attacks.................................8 Attacks  . . . . . . . . . . . . . . . .   9
     3.2  Replay of Signaling Messages.............................10 Messages . . . . . . . . . . . . . . .  13
     3.3  Injecting or Modifying Messages..........................11 Messages  . . . . . . . . . . . . .  13
     3.4  Insecure Parameter Exchange and Negotiation..............11 Negotiation  . . . . . . .  13
   4.   NSIS-Specific Threat Scenarios...............................11 Scenarios . . . . . . . . . . . . . . .  15
     4.1  Threats during NSIS SA Usage............................................12 Usage . . . . . . . . . . . . . . .  15
     4.2 Combining Signaling and SA Establishment.................12  Flooding . . . . . . . . . . . . . . . . . . . . . . . . .  15
     4.3  Eavesdropping and Traffic Analysis.......................13 Analysis . . . . . . . . . . . .  17
     4.4  Identity Spoofing........................................13 Spoofing  . . . . . . . . . . . . . . . . . . . .  17
     4.5  Unprotected Authorization Information....................15 Information  . . . . . . . . . .  19
     4.6  Missing Non-Repudiation..................................16 Non-Repudiation  . . . . . . . . . . . . . . . . .  20
     4.7  Malicious NSIS Entity....................................17 Entity  . . . . . . . . . . . . . . . . . .  21
     4.8  Denial of Service Attacks................................17 Attacks  . . . . . . . . . . . . . . . .  22
     4.9  Disclosing the Network Topology..........................18 Topology  . . . . . . . . . . . . .  23
     4.10   Unprotected Session or Reservation Ownership............19 Ownership . . . . . .  23
     4.11   Attacks against the Transport Mechanism.................20 NTLP . . . . . . . . . . . . . . . .  25
   5.   Security Considerations......................................21 Considerations  . . . . . . . . . . . . . . . . . .  26
   6. Normative References.........................................21   Contributors . . . . . . . . . . . . . . . . . . . . . . . .  27
   7.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  28
   8.   References . . . . . . . . . . . . . . . . . . . . . . . . .  29
   8.1  Normative References . . . . . . . . . . . . . . . . . . . .  29
   8.2  Informative References.......................................22
   Author's Addresses..............................................23
   Full References . . . . . . . . . . . . . . . . . . .  29
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  31
        Intellectual Property and Copyright Statement........................................23 Statements . . . . . . .  32

1.  Introduction

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

   -

      NSIS Analysis Activities (e.g., RSVP Security Properties)
   - (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 Proposals 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 signaling protocol design. 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 NSLPs. QoS,
   Signaling Layer Protocols (NSLPs).  QoS [I-D.ietf-nsis-qos-nslp],
   NAT/Firewall and other NSLPs NSLP documents need to provide a description
   of their trust models and a threat description assessment for their specific
   application domain. In addition, although the base protocol might be
   secure, certain extensions may cause problems when used in a
   particular environment. Furthermore, it is necessary  This document aims to investigate provide some help for the context
   subsequent design of the NSIS protocol suite.  Investigations of
   security threats in which a signaling protocol is used and the specifc architecture into which it is integrated. As an example of such
   interaction, accounting and charging or context are taken into account in this
   document, because without an appropriate integration of outside the two, it
   is difficult to deploy any NSIS solution. This interaction is also a
   subject
   scope of discussion within the NSIS Framework. this document.

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

2. Relevant  Communications Models

   Signaling messages traverse different parts

   The NSIS suite of a network, demand
   different security protection, and raise different security
   problems. The different needs for security protection are mainly due protocols is envisioned to the fact that NSIS support various
   signaling messages cross trust boundaries into
   domains where different trust relationships exist. Often, one may
   describe this by categorizing communications as first-peer, last-
   peer, intra-domain, or inter-domain (see Figure 1).

   The main properties of applications that need to install and/or manipulate state
   at nodes along the parts of a network listed here are
   briefly described in this section, and data flow path through the network.  As such, the threats against them in
   Sections 3 and 4 are classified as generic and
   NSIS specific. Figure
   1 depicts a typical end-to-end protocol suite involves the communication scenario including
   access parts between different
   entities.

   This section offers terminology for common communication models,
   which are relevant to securing the NSIS end-entities and their nearest NSIS
   hops. This "first-peer communications" commonly comes protocol suite.

   An abstract network topology with specific
   security requirements (as described below) that are especially
   important for properly addressing security its administrative domains is shown
   in mobile scenarios.
   Differences Figure 1 and in Figure 2 the trust relationship and the required security for
   first-peer communication, compared with other parts of between NSIS entities
   along the path is illustrated.  For illustrative reasons only
   end-to-end NSIS signaling
   path, is depicted but it might exist.

   To refine be used in other
   variations as well.  Signaling can start at any place and might
   terminate at any other place within the above differentiation based network.  Depending on the network parts that
   NSIS signaling may traverse, we consider
   trust relationships relationship between
   different network parts.

   Additional threats may apply to NSIS communications entities and the traversed network
   parts different security problems arise.

   The notion of trust and trust relationship used in which one
   entity involved this document is an end-entity (Initiator or Responder)
   informal and can be best captured by the
   other entity is any intermediate hop except definition provided in
   Section 1.1 of [RFC3756].  For completeness we include the immediately adjacent
   peer. This is typically called definition
   of a trust relationship which denotes a mutual a priori relationship
   between the end-to-middle scenario (see
   Figure 2 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 description 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 relevant trust relations). 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.

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

                Figure 1: Communication patterns in NSIS Network Parts

   First-Peer/Last-Peer Communication:

      The motivation for including this end-to-end communication scenario stems, for example, from depicted in Figure 1
      includes the SIP [RFC3261] protocol. To counter a number of specific security
   threats, any intermediate SIP hop may request a SIP end-entity (UA) communication between the end hosts and their nearest
      NSIS hops.  "First-peer communications" refers to authenticate. Such functionality seems generally useful for
   intermediaries at the borders of trust domains that peer-to-peer
      interaction between a signaling
   messages need to traverse.

   Intermediate NSIS hops may have to deal as well with specific
   security threats not (directly) involving any end-entities. This
   scenario is called middle-to-middle. A typical example of middle-to-
   middle communication is between two NSIS hops at the borders of
   their respective trust domains (i.e., inter-domain communications).
   NSIS messages may have to traverse one or more untrusted hops
   between these NSIS entities.

   Figure 2 illustrates these additional scenarios. The first-peer and
   last-peer cases discussed above are covered by the peer-to-peer
   trust relationships between end-entity and closest hop.

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

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

                    Figure 2: NSIS Trust Relationships

2.1 First-Peer Communications

   First-peer communications refers to the peer-to-peer interaction
   between a signaling message originator, the message originator, the NSIS
      Initiator (NI), and the first NSIS-aware entity along the path. Making assumptions about
   the threats,
      This "first-peer communications" commonly comes with specific
      security requirements that are especially important for addressing
      security requirements, issues between the end host (and a user) and available trust
   relationships may be difficult here. the network
      it is attached to.

      To illustrate this, in public mobile 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 between 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
      is often not required (which, in contrast, is required for the public mobile case).

   For first-peer communications, especially, threats related to
   initial security association setup, or threats due to replay
   attacks, lack of confidentiality, denial in a
      roaming environment).

      Last-Peer communication is a variation of service, integrity
   violation, or identity spoofing First-Peer communication
      where the roles are relevant, and potentially lead
   to theft of service,  fraud, or violations reversed.

   Intra-Domain Communication:

      After verification of privacy.

2.2 End-to-Middle Communications

   End-to-middle interaction in the NSIS signaling may be required, e.g., to
   grant end-entities access to specific services in trust domains
   different from the one to which the first peer belongs. Threats
   specific to this scenario may be introduced by untrusted
   intermediate NSIS hops that maliciously alter NSIS signaling. These
   threats are still relevant if security mechanisms are in place
   between the NSIS hops, but terminate at each hop (e.g., IPsec hop-
   by-hop protection).

2.3 Intra-Domain Communications

   After having been verified message at the first peer, border of
      an administrative domain, an NSIS signaling message traverses the
      network within the same administrative domain to which the first
      peer belongs. Because the request has already
   been authenticated and authorized, the threats are different from
   those described in the previous sections. To differentiate first-
   peer communications from intra-domain communications (i.e.,
   communications internally within one administrative domain) we
   assume that no external end hosts have direct access  It might not be necessary to repeat the internal
   network nodes, except to
      authorization procedure of the first peer. We furthermore assume that NSIS peers within the same administrative domain have initiator again at least some
   sort of trust relationship.

2.4 Inter-Domain Communications

   The threat assumptions between every NSIS
      node within this domain.  Key management within the borders of different administrative domains largely depend on the authorization
   procedures. If one domain forges QoS reservations, then this
      domain
   may might also have to pay for the reservation. Hence, in this case, there be simpler.

      Security protection is no real benefit for this domain still required to forge a QoS reservation. If an
   end host is directly charged by intermediate domains (i.e., prevent threats by a
   domain different from
      non-NSIS nodes in this network.

   Inter-Domain Communication:

      Inter-Domain communication deals with the malicious domain), such an attack may be a
   quite realistic threat.

   Security protection of messages transmitted interaction between different
      administrative domains domains.  For some NSLPs (for example QoS NSLP)
      this interaction is necessary likely to tackle attacks like spoofing,
   integrity violation, or denial of service take place between these domains,
   e.g., to allow proper accounting. The number of neighboring
      domains
   is usually rather limited (compared with first-peer communications),
   which substantially reduces the key management considerations for
   securing inter-domain NSIS signaling.

   Signaling information whereas in other than QoS service parameters, such NSLPs (such as
   policy rules in the case of middlebox communications, places
   different assumptions on inter-domain communications. Business
   relationships and trust assumptions are of particular importance as
   a basis for securing these communications. 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 potentially distant 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. This might lead to an inability to secure signaling
   messages for direct communications between

   To refine the above differentiation based on the access networks.
   Hence, this can be seen as a serious deployment problem, because it
   might be unacceptable for an access network service provider to
   perform processing (e.g., QoS reservations or policy rule
   installation at firewalls) triggered by unprotected,
   unauthenticated, and possibly unauthorized incoming signaling
   messages.

2.5 End-to-End Communications parts that
   NSIS aims to signal information between the Initiator and the
   Responder. This section refers to the trust signaling may traverse, we subsequently consider relationships required
   between the end points in cases where security protection is
   required. Note that this security protection is likely to be
   required only for certain objects such as those related to pricing
   and charging. Protecting the entire signaling message end to end is
   not normally regarded as feasible, because intermediate involved entities.  Since a number of NSIS nodes might
   actively participate in a specific protocol exchange, a larger number
   of possible relationships need (a) to inspect various objects and (b) to add, modify, or
   delete objects from the signaling message.

   The following example be analyzed than in other
   protocols.  Figure 2 illustrates a possible application of end-to-
   end protection for objects carried within the NSIS signaling
   protocol. Alice, the data sender, wants Bob, relationships between the data receiver, to
   pay for a QoS reservation (reverse charging). Bob wants to be
   assured that
   entities involved in the QoS signaling message he receives was indeed
   transmitted by Alice, because he NSIS protocol suite.

                 ****************************************
                 *                                      *
            +----+-----+       +----------+        +----+-----+
      +-----+  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 only willing to pay for
   particular users an end-entity
      (Initiator or Responder) and not for everyone. Hence, Bob wants to verify
   that the request came from Alice (authentication) and that other entity is any intermediate
      hop other than the
   included parameters are unmodified (integrity). Additionally it 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 necessary to secure a negotiation step and to deliver
   authorization information securely to the parties involved.
   Information required to render an explicit
      authorization decision (such as
   prices or QoS objects) also needs proper security protection.

   Typical threats in such a scenario range from modification of QoS
   objects or price information (i.e., making Bob pay too much), to
   fraud (i.e., forcing Bob always to pay for the reservations), NSIS Initiator to
   identity spoofing (i.e., an impostor claiming some intermediate node.
      Threats specific to this scenario may be Alice).

   Regarding end-to-end security, one additional issue needs introduced by some
      intermediate NSIS hops which are not allowed to be
   addressed: delegation. Whenever signaling is addressed end eavesdrop or
      modify certain objects.

   Middle-to-Middle Communications:

      Middle-to-middle communication refers to end
   and an arbitrary node along the path acts as a proxy on behalf exchange of
   the other endpoint, a delegation mechanism is required
      information between two non-neighboring NSIS nodes along the path.
      Intermediate NSIS hops may have to provide
   secure interaction. This might lead deal with specific security
      threats, which do not directly involve the NSIS Initiator or the
      NSIS Responder.

   End-to-End Communications:

      NSIS aims to additional complexity.

2.6 Middle-to-Middle Communications

   The middle-to-middle 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 explicitly considered here,
   although an end-to-end protocol
      used to exchange information purely between end hosts.

      Typically, it is important, because it not required to cryptographically protect NSIS
      messages between the NSIS Initiator and the NSIS Responder.
      Protecting the entire signaling message end-to-end is already covered by either
   intra- not feasible
      since intermediate NSIS nodes need to add, inspect, modify or inter-domain communications depending on the locations of
      delete objects from the entities involved. signaling message.

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 (1) security threats that exist if two peers
   do not already share a security association or do not use security
   mechanisms at all, and (2) threats that are applicable when a security
   association is already established. Note also that a
   denial of service attack on a signaling protocol exists when no
   separation between SA establishment and signaling protection takes
   place. The discovery procedure, in particular, is vulnerable to a
   number of such attacks.

   -

   Attacks during NSIS SA Establishment 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
      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 of 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
      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
      two cases:

   -

      Missing Authentication 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 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 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 certainly
         opens up many possibilities for man-in-the-
   middle 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. protocol
         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, whereby 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 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.

3.2 Replay

   Finally, we conclude a description of Signaling Messages a man-in-the-middle attack
   during the discovery phase.  This threat scenario covers attack benefits from the case in which fact that
   NSIS nodes are likely to be unaware of the network topology.
   Furthermore, an adversary
   eavesdrops and collects signaling messages and replays them at a
   later time (or at authorization problem might arise if an NSIS QoS NSLP
   node pretends to be a different place, NSIS NAT/Firewall specific node or uses parts of them at vice versa.

   An adversary might want to inject a
   different place or in bogus reply message forcing the
   discovery message initiator to start a different way, e.g., cut-and-paste attacks).
   Without proper replay protection, messaging association
   establishment with either 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 or with another NSIS node
   which is not along the path.  Figure 3 describes the adversary to crash an NSIS-aware
   node, cause 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 in more
   detail for peer-to-peer addressed messages (e.g., by acting as with a man-in-
   the-middle) to cause unexpected network behavior. Possible actions
   an adversary might consider for its discovery
   mechanism.  For end-to-end addressed messages the 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
   applicable particularly if the adversary is only feasible in located along the absence of authentication path
   and
   signaling able to intercept the discovery message protection.

   Some threats directly related which traverses the
   adversary.  The man-in-the-middle adversary might redirect to these are described in Sections
   4.4, 4.7, and 4.8.

3.4 Insecure Parameter Exchange and Negotiation

   First, protocols may another
   legimimate NSIS node.  A malicious NSIS can be useful in a variety of scenarios detected with
   different the
   corresponding 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, but a protocol legitimate NSIS node which is
   required to agree on certain security mechanisms and parameters. An
   insecure parameter exchange or security negotiation protocol can
   help an adversary mount a downgrading
   not the next NSIS node along the path cannot be detected without
   having topology knowledge.

                      +-----------+   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 force selection eavesdrop the
   initial discovery message sent by the sender of
   weaker mechanisms the discovery
   message.  Furthermore, we assume that the discovery reply message by
   the adversary returns to the discovery message initiator faster than mutually desired. Hence, without binding
   the
   negotiation process real response.  This represents some race condition
   characteristics if the next NSIS node is very close (in IP-hop terms)
   to the legitimate parties and protecting it, 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 protocol node along the
   path will be discovered again.  A ping-pong behavior 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.

4. NSIS-Specific Threat Scenarios

   This section describes 11 threat scenarios
   consequence.

   As shown in terms of attacks on
   and security deficiencies message step (2) in Figure 3 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, returns a
   discovery reply message with its own IP address as such, need
   to be addressed, but are often enabled by one or more deficiencies
   described under other scenarios.

4.1 the next NSIS SA Usage

   Once
   aware node along the path.  Without any additional information the
   discovery message initiator has to trust this information.  Then a security
   messaging association is established (and used) to protect
   signaling messages, many basic attacks are prevented. However, with an entity at a
   malicious NSIS node is still able to perform various attacks as
   described given IP
   address IPx (i.e., with the adversary) in Section 4.7. Replay attacks may be possible when an step (3).  The adversary
   then establishes a messaging association with a further NSIS node crashes, restarts, and performs state re-establishment.
   Proper re-synchronization of
   forwards the security mechanism must therefore
   be provided to address this problem.

4.2 Combining Signaling and SA Establishment

   This scenario describes attacks signaling message.  Note that allow an the adversary to flood an might just
   modify the Disovery Reply message to force NSIS node with bogus signaling messages Node A to cause a denial of service
   attack.

   When establish a signaling message arrives at an NSIS-aware network element,
   certain processing is required. If this message contains security
   objects such as digital signatures, and no security
   messaging association is
   already available, then some additional processing is required for
   the cryptographic verification. Because NSIS signaling should not
   require extra roundtrips between two with another NSIS peers, it node which is difficult to
   provide not along the DoS protection mechanisms commonly found in
   authentication and key agreement protocols. Signaling messages
   path.  This can then be idempotent, which means that they contain exploited by the same amount of
   information as adversary.  Particularly 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 new state along
   interworking with NSIS unaware NATs might cause additional unexpected
   problems.

   As a new path, although no
   previous state is available. For this to work, specific classes variant 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 attack an adversary not able to possible denial of service attacks.
   Problems eavesdrop
   transmitted discovery requests could flood a node with using these types bogus
   discovery reply messages.  If the discovery message sender
   accidentally accepts one of exchanges with public key based
   protection are those bogus messages then a MITM-attack
   as described in [AN97] and in [ALN00].

   In addition to the Figure 3 is possible.

3.2  Replay of Signaling Messages

   This threat scenario described above, covers the case in which an incoming adversary eavesdrops
   and collects signaling message might require time consuming processing
   (computations, state maintenance, timer setting, etc.) messages and
   communication with third-party nodes such as policy servers, LDAP
   servers, etc. If 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 is able to transmit a large number might mount man-in-the-middle, denial
   of
   signaling messages (for example, with QoS reservation requests) with
   invalid credentials, then the verifying node service, and theft of service attacks.

   A more difficult attack that may not 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
   process other reservation messages from legitimate users.

   Further attacks may be enabled by injecting error messages or
   forcing the creation replay old signaling
   messages.  This attack takes advantage of error messages to extract additional
   information.

4.3 Eavesdropping and Traffic Analysis re-synchronization
   deficiencies.

3.3  Injecting or Modifying Messages

   This section covers threats type of threat involves integrity violations, whereby an
   adversary is able to
   eavesdrop on signaling messages. The modifies signaling packets collected may
   allow traffic analysis or be used later to mount replay attacks, messages (e.g., by acting as
   described in Section 3.2. The eavesdropper a
   man-in-the-middle) to cause unexpected network behavior.  Possible
   actions an adversary might learn QoS
   parameters, communication patterns, policy rules consider for firewall
   traversal, policy information, application identifiers, user
   identities, NAT bindings, authorization objects, network
   configuration and performance information, its attack are reordering,
   delaying, dropping, injecting, truncating, and more. otherwise modifying
   messages.

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

   Note that this threat scenario is not mitigated by applying
   integrity protection to the messages, which is often considered
   sufficient for signaling protocols.

   Because the NSIS protocol signals messages through a number large amount
   of
   nodes, 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 differentiate between nodes actively
   participating carry out fraud.  This attack is
   only feasible in the NSIS protocol absence of authentication 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 signaling message
   protection.

   Some threats directly related to eavesdrop. On the other hand, it might be desirable
   that only the intended end points (NSIS Initiator and NSIS
   Responder) these are able to read certain other objects.

4.4 Identity Spoofing

   Identity spoofing relevant for NSIS occurs 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 two forms: first,
   identity spoofing can happen during the establishment of a variety of scenarios with
   different security
   association based on requirements.  Second, different users (e.g., a weak authentication mechanismn and, second,
   it can consist
   university, a hospital, a commercial enterprise, or a government
   ministry) have inherently different security requirements.  Third,
   different parts of spoofing data traffic.

   In the first case, Eve, acting as an adversary, may claim to be the
   registered user Alice by spoofing Alice's identity. Eve thereby
   causes the network to charge Alice for the a network resources
   consumed. This type (e.g., within a building, across a
   public carrier's network, or over a private microwave link) may need
   different levels of attack is possible if authentication protection.  It is based
   on often difficult to meet these
   (sometimes conflicting) requirements with a simple username identifier (i.e., in absence of cryptographic
   authentication), single security mechanism
   or if authentication is provided for hosts, fixed set of security parameters, so often a selection of
   mechanisms and
   multiple users have access parameters is offered.  Therefore, a protocol is
   required to agree on certain security mechanisms and parameters.  An
   insecure parameter exchange or security negotiation protocol can help
   an adversary mount a single host. This downgrading attack could also
   be classified as theft to force selection of service.

   In weaker
   mechanisms than mutually desired.  Hence, without binding the second case, an adversary may be able
   negotiation process to exploit the
   established flow identifiers (required for QoS legitimate parties and middlebox
   communication [Midcom] specific signaling protocols). Some
   identifiers, among others, IP addresses, transport protecting it, an
   NSIS protocol
   identifiers, port numbers, suite might be only as secure as the weakest mechanism
   provided (e.g., weak authentication), and flow labels (see [RFC1809] the benefits of defining
   configuration parameters and
   [RC+03]), a negotiation protocol are transported lost.

4.  NSIS-Specific Threat Scenarios

   This section describes 11 threat scenarios in these protocols. Modification of these
   flow identifiers allows adversaries to exploit or to render
   ineffective quality terms of service reservations or policy rules at
   middleboxes. An adversary could mount an attack by modifying attacks on and
   security deficiencies in the
   flow identifier of a signaling message. NSIS signaling messages contain some sort protocol.  A number 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.

   The following threat
   security deficiencies might enable an attack.  Fraud is carried out an example of
   an attack that might be enabled by spoofing the identity missing replay protection, missing
   protection of
   transmitted data traffic. The spoofed authorization tokens, identity is the IP source
   address. For this 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 successful, accounting records addressed, but are
   collected based on the IP source address and not on often enabled by one or more deficiencies
   described under other scenarios.

4.1  Threats during NSIS SA Usage

   Once a SPI due security association is established (and used) to
   IPsec protection. After the network receives a properly protected
   reservation request, transmitted by the legitimate user Alice,
   Traffic Selectors are installed at the corresponding devices (for
   example, the edge router). These Traffic Selectors protect
   signaling messages, many basic attacks are used for flow
   identification and allow data traffic originated from prevented.  However, a given source
   address
   malicious NSIS node is still able to perform various attacks as
   described in Section 4.7.  Replay attacks may be matched possible when an
   NSIS node crashes, restarts, and assigned to a particular QoS reservation.
   The adversary Eve now spoofs the IP address performs state re-establishment.
   Proper re-synchronization of the Alice. In
   addition, Alice's host may security mechanism must therefore be crashed by the
   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 or may lose connectivity, for example, because of
   mobility considerations. If both nodes are located at the same link
   and use the same IP address, then obviously a duplicate IP address
   attack.

   We will be detected. Assuming that only Eve is now present discuss this threat at different layers in the link,
   she is able NSIS protocol
   suite:

   Processing of Router Alert Options:

      The processing of Router Alert Option (RAO) requires a router to receive and transmit data (for example RTP data
   traffic) that receives preferential QoS treatment based on the
   previous reservation. Depending on the installed Traffic Selector
   granularity, Eve
      do some additional processing by intercepting packets with IP
      options, which might have more possibilities lead to exploit the QoS
   reservation additional delay for legitimate
      requests, or even to reject some of them.  A router being flooded
      with a pin-holed firewall. Assuming the soft state
   paradigm, whereby periodic refresh messages are required, the
   absence large number of Alice will not bogus messages requires resources before
      finding out that these messages have to be detected until dropped.

      If the next signaling protocol is based on using interception for message appears and forces Eve to respond with a protected signaling
   message. Again,
      delivery this attack is applicable not just to QoS traffic, threat cannot be completely eliminated, but the existence of a QoS reservation increases its impact, because
   this type of traffic is more expensive. The same attack
      protocol design should attempt to limit the processing that has to
      be done on the RAO-bearing packet so that it is also
   applicable as similar as
      possible to a Middlebox protocol.

   The ability that for an adversary arbitrary packet addressed directly to inject data traffic that matches a
   certain flow identifier established one
      of the router interfaces.

   Attacks against the Transport Layer protocol:

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

   Force NTLP to receive the data traffic. This is,
   however, true only if 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 identifier consists control or the congestion
      control procedure.  These types of values that
   contain addresses used for routing. If we imagine using attributes 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 a flow identifier that signaling messages.

      Furthermore, causing memory allocation and computational efforts
      might allow an adversary to do not require such harm to NSIS entities.  If a
      signaling message contains, for example, a property, digital signature then
   identity spoofing and injecting traffic are much easier.
      some additional processing is required for the cryptographic
      verification.  An adversary can use easily create a nearly arbitrary endpoint identifier random bit
      sequence instead of a digital signature to achieve
   the desired result. Obviously, though, the endpoint identifiers are
   not irrelevant, because the force an NSIS node into
      heavy computation.

      Idempotent signaling messages have are particularly vulnerable to this
      type of attack.  Idempotent refers to travel messages which contain the
      same path
   through amount of information as the network.

   Data traffic marking based on DiffServ original message.  An example
      would be a refresh message that 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 equivalent to a long
   time and have been documented in various DiffServ-related documents.
   The IPsec protection of DiffServ Code Points create message.
      This property allows a refresh message to create state along a new
      path, where no previous state is described in Section
   6.2 available.  For this to work,
      specific classes of [RFC2745]. Related security issues (for 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
      possible denial of service attacks) attacks.

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

      In addition to the same document.

4.5 Unprotected Authorization Information

   Authorization is threat scenario described above, an important criterion for providing resources incoming
      signaling message might trigger communication with third-party
      nodes such as QoS reservations, NAT bindings, and pin-holes through firewalls.
   Authorization information might be delivered policy servers, LDAP servers or AAA servers.  If an
      adversary is able to the NSIS
   participating entities in transmit a large number of ways.

   Typically signaling messages
      (for example, with QoS reservation requests) with invalid
      credentials, then the authenticated identifier 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 assist during the
   authorization procedure as, e.g., mount replay attacks, as
   described in [RFC3812]. Depending
   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 3.2.  The eavesdropper might learn QoS
   parameters, communication patterns, policy rules for signaling message protection.

   Another approach is to use some sort of firewall
   traversal, policy information, application identifiers, user
   identities, NAT bindings, authorization token. The
   functionality objects, network
   configuration and structure of such an authorization token for RSVP
   is described in [RFC3520] performance information, and [RFC3521].

   Achieving secure interaction between different protocols based more.

   An adversary's capability to eavesdrop on signaling messages might
   violate a user's preference for privacy, particularly if unprotected
   authentication or authorization tokens, however, requires some care. By using such an
   authorization token information (including policies and
   profile information) is exchanged.

   Because the NSIS protocol signals messages through a number of nodes,
   it is possible to link state information differentiate between
   different protocols. Returning an unprotected authorization token to nodes actively participating
   in the end host NSIS protocol and others that do not actively participate in
   the NSIS protocol.  For certain objects or messages it might allow an adversary (for example an eavesdropper) be
   desirable to steal resources. An adversary might also use the token permit actively participating intermediate NSIS nodes to monitor
   communication patterns. Finally, an untrustworthy end host might
   also modify
   eavesdrop.  On the token content.

   The Session/Reservation Ownership problem can also other hand, it might be regarded as an
   authorization problem. Details desirable that only the
   intended end points (NSIS Initiator and NSIS Responder) are described in Section 4.10. In
   enterprise networks, authorization is often coupled with membership able to
   read certain other objects.

4.4  Identity Spoofing

   Identity spoofing relevant for NSIS occurs in a particular class of users or groups. This type of information
   either three forms: first,
   identity spoofing can be delivered as part of 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 key
   agreement procedure or has third, it can spoof data traffic.

   In the first case, Eve, acting as an adversary, may claim to be retrieved via separate protocols
   from other entities. If an adversary manages the
   registered user Alice by spoofing Alice's identity.  Eve thereby
   causes the network to modify information
   relevant charge Alice for determining authorization or the outcome of the
   authorization process itself, then theft network resources
   consumed.  This type of service might be
   possible.

4.6 Missing Non-Repudiation

   Repudiation attack is possible if authentication is based
   on a simple username identifier (i.e., in this context refers absence of cryptographic
   authentication), or if authentication is provided for hosts, and
   multiple users have access to a problem where one party
   later denies having taken a certain action (such single host.  This attack could also
   be classified as requesting a QoS
   reservation). Problems stemming from a lack theft of non-repudiation
   appear in two forms:

   On the one hand, from a service provider's point-of-view, service.

   In the
   following threat may be worth investigation. A user may deny having
   issued a reservation request for which it was charged. The service
   provider second case, an adversary may then want to be able to prove that a particular user
   issued the reservation request in question.

   On exploit the other hand, the same threat can be interpreted from a user's
   point-of-view. A service provider may claim to have received a
   number of reservation requests. The user in question thinks that it
   never issued those requests
   established flow identifiers (required for QoS and wants 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 see a proof exploit or to render ineffective quality of correct
   service usage for a given set reservations or policy rules at middleboxes.  An adversary
   could mount an attack by modifying the flow identifier of QoS parameters. a signaling
   message.

   In today's telecommunication networks, non-repudiation the third case, an adversary may spoof data traffic.  NSIS
   signaling messages contain some sort of flow identifier, which is not
   provided. The user has
   associated with a specified behavior (e.g., a particular flow
   experiences QoS treatment or allows packets to trust the network operator traverse a firewall).
   An adversary might, therefore, use IP spoofing and inject data
   packets to meter benefit from previously installed flow identifiers.

   We will provide an example of the
   traffic correctly, collect and merge accounting data, latter threat.  After NSIS nodes
   along the path between the NSIS initiator and ensure
   that no unforeseen problems occur. If the NSIS receiver
   processes a signaling protocol with properly protected reservation request, transmitted by
   the
   non-repudiation property is desired for establishing legitimate user Alice, a QoS
   reservations for authorized resources, this impacts reservation is installed at the protocol
   design.

   Non-repudiation poses additional requirements on
   corresponding NSIS nodes (for example, the security
   mechanisms, because it public-key cryptography edge router).  The flow
   identifier is needed to provide
   it. Because this would normally increase the overall cost used for
   security, threats related to missing non-repudiation are only
   considered relevant in certain specific cases (e.g., specific
   authorization mechanisms) flow identification and not for general NSIS signaling.

4.7 Malicious NSIS Entity

   Network elements within a domain (intra-domain) experience allows data traffic
   originated from a
   different trust relationship with regard given source 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 be assigned to take over an edge router, then this QoS
   reservation.  The adversary Eve now spoofs the security IP address of Alice.
   In addition, Alice's host may be crashed by the entire network is compromised. An adversary is then able to
   launch with a number of attacks including
   denial of service; integrity
   violations; replay, reordering, and deletion service attack or may lose connectivity, for example,
   because 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 mobility.  If Eve is also able to
   get access perform address spoofing then
   she is able to security associations receive and transmit secured signaling
   messages. Note data (for example RTP data
   traffic) 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 receives preferential QoS treatment based 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
   edge does not imply that other routers within an intra-domain
   network do not need to verify signaling messages cryptographically.
   If
   previous reservation.  Depending on the chain-of-trust principle is deployed, then installed flow identifier
   granularity, Eve might have more possibilities to exploit the security
   protection of QoS
   reservation or a pin-holed firewall.  Assuming the entire path (in this case within soft state
   paradigm, whereby periodic refresh messages are required, the network absence
   of Alice will not be detected until a
   single administrative domain) is as strong as the weakest link. In
   the case under consideration, the edge router refresh message is the most critical
   component of this network, required and it may also act as
   forces Eve to respond with a security gateway
   or firewall for incoming and outgoing traffic. For outgoing traffic protected signaling message.  Again,
   this device has attack is applicable not just to implement the security policy of the local domain QoS traffic and apply the appropriate security protection.

   For same attack
   is also applicable to a Firewall control protocol, with a different
   consequence.

   The ability for an adversary to mount this attack, either an existing NSIS-aware
   node along 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 path has ability
   also to be attacked successfully, receive the data traffic or to have one's correspondent
   receive it.  For example, an adversary
   must succeed in convincing another NSIS node to be 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 an unmanaged network
   observes a NAT/Firewall signaling messages, etc., are mentioned throughout this document.

   - Path Finding

   This threat scenario includes potential DoS attacks that exist when
   the reservation setup is split into two phases, i.e., path and
   reservation (as used, for example, in receiver-based reservation
   setup). In this case, assuming that the node transmitting the path message is not charged for towards a corporate
   network.  After the path signaling message itself, it may be able
   to generate a large number of reservation requests (possibly in a
   distributed fashion). Charging is activated only after exchange was successful
   verification of the reservation request. The reservations are,
   however, never intended user
   Alice is allowed to be successful for various reasons: traverse the
   destination node cannot be reached; it is not responding; or it
   simply rejects company firewall based on the reservation. An
   establish packet filter to contact her internal mail server.  Now,
   adversary can succeed because
   state has already been allocated along Eve, which was monitoring the path for various
   processing tasks including path pinning.

   - Discovery Phase

   Conveying signaling information exchange is able to a large number of entities along
   build a data path requires packet towards this mail server which will pass the
   company firewall.  The packet will hit the mail server and cause some sort
   actions and the mail server will reply with some response messages.
   Depending on the exact location of discovery. This discovery process
   is vulnerable to a number the adversary and the degree of attacks, because it is difficult to
   secure. An
   routing asymmetry the adversary can use might even see the discovery mechanisms response messages.
   Note that for this attack to convince
   one entity work Alice does not need to signal information to another entity not along the
   data path or to cause the discovery process to fail. In the first
   case, participate
   in the exchange of 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 messages.

   If we imagine using attributes of a DoS attack. This flow identifier that is not
   related to source and destination addresses.  As an example, we could be either at the signaling
      message protocol layer (NTLP), at the layer
   think of each client layer
      protocol (NSLP: QoS, Midcom, etc.), or at a flow identifier where only the transport protocol
      layer. An 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 might cause unexpected protocol behavior or
      might succeed with can use a DoS attack. The discovery protocol,
      especially, exhibits vulnerabilities with regard nearly arbitrary endpoint
   identifier to this threat
      scenario (see achieve the above discussion on discovery). In desired result.  Obviously, though, the case
   endpoint identifiers are not irrelevant, because the messages have to
   hit some nodes in
      which no separate discovery protocol is used and the network where NSIS signaling messages are addressed to end hosts only (with a Router Alert
      Option installed
   state (e.g., in the above example they would have to intercept message as NSIS aware nodes), hit the same
   firewall.)

   Data traffic marking based on DiffServ is such an error
      message 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 used delivered to indicate a path change. Such a design
      combines a discovery protocol together with the NSIS
   participating entities in a signaling message
      exchange protocol.

4.9 Disclosing number of ways.

   Typically the Network Topology
   In some organizations or enterprises there authenticated identity is a desire not used to reveal
   internal network structure (or other related information) outside of assist during the
   authorization procedure as, e.g., described in [RFC3182].  Depending
   on the chosen authentication protocol, certain threats may exist.
   Section 3 discusses a closed community. An adversary might be able number of issues related to use NSIS messages this approach when
   the authentication and key exchange protocol is used to establish
   session keys for network mapping (e.g., discovering which nodes exist, which signaling message protection.

   Another approach is to 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 some sort of diagnostic
   message authorization token.  The
   functionality for RSVP), and query messages, in addition to
   record route structure of such an authorization token for RSVP
   is described in [RFC3520] and route objects, provide potential assistance [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
   adversary. Hence, unprotected authorization token to
   the requirement of not disclosing a network
   topology end host might conflict with other requirements allow an adversary (for example an eavesdropper)
   to provide means for
   automatically discovering NSIS-aware nodes or steal resources.  An adversary might also use the token to provide diagnostic
   facilities (used for network monitoring and administration).

4.10 Unprotected Session or Reservation monitor
   communication patterns.  Finally, an untrustworthy end host might
   also modify the token content.

   The Session/Reservation Ownership

   Figure 3 shows problem can also be regarded as an NSIS Initiator that has established state
   information at NSIS nodes along
   authorization problem.  Details are described in Section 4.10.  In
   enterprise networks, authorization is often coupled with membership
   in a path particular class of users or groups.  This type of information
   either can be delivered as part of the signaling
   procedure. As a result, Access Router 1, Router 3, authentication and Router 4 (and key
   agreement procedure or has to be retrieved via separate protocols
   from other nodes) have stored session state entities.  If an adversary manages to modify information including
   relevant for determining authorization or 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 3: Session or Reservation Ownership

   The Session Identifier is included outcome of the
   authorization process itself, then theft of service might be
   possible.

4.6  Missing Non-Repudiation

   Repudiation in signaling messages to
   reference this context refers to a problem where one party later
   denies having taken a certain action (such as requesting a QoS
   reservation).  Problems stemming from a lack of non-repudiation
   appear in two forms:

   On the established state.

   If an adversary were able to obtain one hand, from a service provider's point-of-view, the Session Identifier,
   following threat may be worth investigation.  A user may deny having
   issued a reservation request for
   example by eavesdropping on signaling messages, which it would was charged.  The service
   provider may then want to be able to
   add the same Session Identifier SID-x to prove that a new signaling message.
   When particular user
   issued the new signaling message hits Router 3 (as shown reservation request in Figure 3),
   existing state information question.

   On the other hand, the same threat can be modified. The adversary can then
   modify or delete the established interpreted from a user's
   point-of-view.  A service provider may claim to have received a
   number of reservation and cause unexpected
   behavior for the legitimate user. requests.  The source of the problem is user in question thinks that Router 3 (a cross-over router) is
   unable it
   never issued those requests and wants to decide whether the new signaling message was initiated
   from the owner see a proof of the session or reservation. correct
   service usage for a given set of QoS parameters.

   In addition, nodes other than the initial signaling message
   originator are allowed today's telecommunication networks, non-repudiation is not
   provided.  The user has to signal information during the lifetime of
   an established session. As part of the protocol, any NSIS-aware node
   along the path (and trust the path might change over time) could initiate
   a signaling message exchange. It might, for example, be necessary to
   provide mobility support or network operator to trigger a local repair procedure. If
   only meter 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,
   traffic correctly, collect and various other attacks.

4.11 Attacks against the Transport Mechanism

   In [BL01] a two-level architecture is proposed, which suggests
   splitting an NSIS protocol into layers: merge accounting data, and ensure that
   no unforeseen problems occur.  If a signaling message
   transport-specific layer and an application-specific layer. This
   architectural assumption protocol with the
   non-repudiation property is also considered within desired for establishing QoS reservations
   for authorized resources, this impacts the NSIS
   framework [HF+03]. Most of protocol design.

   Non-repudiation poses additional requirements on the threats described in this document
   are applicable security
   mechanisms, because public-key cryptography is needed to provide it.
   Because this would normally increase the application-specific part (i.e., signaling QoS
   or middlebox-specific information). There are, however, some overall cost for security,
   threats
   that are applicable related to the transport of signaling messages.

   Network or transport layer protocols lacking protection mechanisms missing non-repudiation are vulnerable to only considered
   relevant in certain attacks such as header manipulation, DoS,
   spoofing of identities, session hijacking, unexpected aborts, etc. specific cases (e.g., specific authorization
   mechanisms) and not for general NSIS signaling.

4.7  Malicious nodes can attack the congestion control mechanism to force NSIS nodes into Entity

   Network elements within a congestion avoidance state.

   In the case in which existing protocols are used for exchanging NSIS
   signaling messages, known threats scenarios applicable domain (intra-domain) experience a
   different trust relationship with regard to these
   protocols are relevant.

5. Security Considerations

   This entire memo discusses the security issues relevant for protection
   of signaling messages compared with edge NSIS
   protocol design. entities.  It begins by identifying the components of a
   network running is
   assumed that edge NSIS (Initiator, Responder, entities are responsible for performing
   cryptographic processing (authentication, integrity and different
   Administrative Domains between them). It then considers five cases
   in which communications take place between these components, replay
   protection, authorization, and it
   examines accounting) for signaling messages
   arriving from 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. outside.  This analysis helps determine prevents unprotected signaling
   messages from appearing within the security needs and internal network.  If, however, an
   adversary manages to take over an edge router, then the relative seriousness security 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 entire network is compromised.  An adversary is then able to
   launch a number of attacks including denial of service. The threats are subdivided into generic
   ones (e.g., man-in-the-middle attacks, replay attacks, tampering service; integrity
   violations; replay, reordering of objects and
   forgery, messages, bundling of
   messages, and attacks on security negotiation protocols) deletion of data packets; and 11
   threat scenarios particularly applicable 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 the a NSIS protocol.
   Denial of service, for example, router is covered in the NSIS-specific
   section, also able to get access to security
   associations and transmit secured signaling messages.  Note that even
   non-peer-to-peer security protection might not because it cannot be carried out against other
   protocols, but because the methods used able to carry out denial prevent
   this problem fully.  Because an NSIS node might issue signaling
   messages on behalf of
   service attacks tend someone else (by acting as a proxy), additional
   problems need to be protocol specific. Numerous illustrative
   examples provide insight into what can happen if these threats are
   not mitigated.

   This document points out repeatedly considered.

   An NSIS-aware edge router is a critical component that not all of requires
   strong security protection.  A strong security policy applied at the threats are
   equally serious in every context. It
   edge does attempt not imply that other routers within an intra-domain network
   do not need to identify verify signaling messages cryptographically.  If the
   chain-of-trust principle is deployed, then the
   scenarios in which security failures may have protection of
   the highest impact.
   However, it entire path (in this case within the network of a single
   administrative domain) is difficult for as strong as the protocol designer 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 foresee all implement the ways in which NSIS protocols will 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 used attacked successfully, or an adversary
   must succeed in convincing another NSIS node to anticipate make it the
   security concerns 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 wide variety number of likely users. Therefore, the
   protocol designer needs
      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 offer transmit a full range large number of security
   capabilities and ways for users
      signaling messages to negotiate allocate state at nodes along the path and select what they
   need, case by case. To counter these threats, security requirements
   have been listed in [Brun03]. Topics relevant
      to cause resource consumption.

      An NSIS responder might not be able to determine the NSIS Framework
   have been incorporated into [HF+03].

6. Normative References

   [Brun03] M. Brunner, "Requirements for QoS
      initiator and might even tend to respond to such a signaling protocols,"
   Internet Draft, Internet Engineering Task Force, August 2003.  Work
      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
      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.

                                             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.

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

7. Informative References

   [HF+03] R. Hancock, I. Freytsis, G. Karagiannis, J. Loughney, 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 S.
   V. den Bosch, "Next steps 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 signaling: Framework," Internet Draft,
   Internet Engineering Task Force, September 2003.  Work
   various sections throughout this document, such as in progress.

   [RFC1809] C. Partridge, "Using Section 4.2.

   In the flow label field case in IPv6," RFC
   1809, Internet Engineering Task Force, June 1995.

   [RFC2745] A. Terzis, B. Braden, S. Vincent, and L. Zhang, "RSVP
   Diagnostic Messages," RFC 2745, Internet Engineering Task Force,
   Jan. 2000.

   [RFC3182]   Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore,
   T., Herzog, S., Hess, R.: "Identity Representation which existing transport layer protocols are used for RSVP", RFC
   3182, October, 2001.

   [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston,
   J. Peterson, R. Sparks, M. Handley,
   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 E. Schooler, "SIP: session
   initiation protocol," RFC 3261, Internet Engineering Task Force,
   June 2002.

   [RFC3521]   L. Hamer, B. Gage, different Administrative Domains
   between them).  It then considers five cases in which communications
   take place between these components, and H. Shieh, "Framework 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 session
   set-up with media authorization," RFC 3521, Internet Engineering
   Task Force, April 2003.

   [RFC3520] L. Hamer, B. Gage, B. Kosinski, 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 H. Shieh, "Session
   Authorization Policy Element", RFC 3520, Internet Engineering Task
   Force, April 2003.

   [RC+03] J. Rajahalme, A. Conta, B. Carpenter,
   forgery, and S. Deering, "IPv6
   Flow Label Specification," Internet Draft, Internet Engineering Task
   Force, April 2003.  Work in progress.

   [BL01] B. Braden attacks on security negotiation protocols) and B. Lindell, "A two-level architecture 11 threat
   scenarios particularly applicable to the NSIS protocol.  Denial of
   service, for
   internet signaling," Internet Draft, Internet Engineering Task
   Force, Nov. 2001. (Expired).

   [AN97] T. Aura and P. Nikander: "Stateless Connections", In
   Proceedings 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 International Conference on Information and
   Communications Security (ICICS'97), Lecture Notes threats are
   equally serious in Computer
   Science 1334, Springer, 1997.

   [ALN00] T. Aura, J. Leiwo and P. Nikander: "Towards Network Denial 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 Service Resistant Protocols", In Proceedings a wide variety of likely users.  Therefore, the 15th
   International Information Security Conference (IFIP/SEC 2000),
   Beijing, China, August 2000.

Author's Addresses

   Hannes Tschofenig
   Siemens AG
   Corporate Technology
   CT IC 3
   Otto-Hahn-Ring 6
   81739 Munich
   Germany
   EMail: Hannes.Tschofenig@siemens.com

   Dirk Kroeselberg
   Siemens AG
   Otto-Hahn-Ring 6
   81739 Munich
   Germany
   EMail: Dirk.Kroeselberg@siemens.com

Appendix A.
   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, besides a detailed review of the
   document.

Appendix B.

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, and
   Ted Wiederhold, Vishal Sankhla, Mohan Parthasarathy and Andrew
   McDonald provided comments on a more recent
   version 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 the
   detailed comments.

Full Copyright his
   detailed comments.

8.  References

8.1  Normative References

   [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,
              <reference.I-D.braden-2level-signal-arch.xml>.

   [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, <reference.I-D.ietf-ipv6-flow-label.xml>.

   [I-D.ietf-nsis-fw]
              Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J.
              and S. Van den Bosch, "Next Steps in Signaling:
              Framework", draft-ietf-nsis-fw-05 (work in progress),
              October 2003.

   [I-D.ietf-nsis-nslp-natfw]
              Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun,
              "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
              draft-ietf-nsis-nslp-natfw-02 (work in progress), May
              2004.

   [I-D.ietf-nsis-ntlp]
              Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
              Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-02
              (work in progress), May 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-03
              (work in progress), May 2004.

   [I-D.ietf-nsis-rsvp-sec-properties]
              Tschofenig, H. and R. Graveman, "RSVP Security
              Properties", draft-ietf-nsis-rsvp-sec-properties-04 (work
              in progress), February 2004.

   [I-D.ietf-nsis-signalling-analysis]
              Manner, J., Fu, X. and P. Pan, "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

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

   EMail: Dirk.Kroeselberg@siemens.com

Intellectual Property Statement

   Copyright (C)

   The Internet Society (2003). All Rights Reserved.

   This document and translations IETF takes no position regarding the validity or scope of it may any
   Intellectual Property Rights or other rights that might be copied and furnished claimed to
   others, and derivative works that comment on or otherwise explain it
   or assist in its
   pertain to the implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction use of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, technology described in
   this document itself may or the extent to which any license under such rights
   might or might not be modified in available; nor does it represent that it has
   made any independent effort to identify any way, such as by removing rights.  Information
   on the copyright notice or references procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the Internet Society IETF Secretariat and any
   assurances of licenses to be made available, or other
   Internet organizations, except as needed for the purpose result of
   developing Internet standards in which case the procedures an
   attempt made to obtain a general license or permission for
   copyrights defined in the Internet Standards process must be
   followed, use of
   such proprietary rights by implementers or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not users of this
   specification can be
   revoked by obtained from the Internet Society or IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its successors attention any
   copyrights, patents or patent applications, or assignees. 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 is 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 DISCLAIMS 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.

Acknowledgement

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.