Internet Engineering Task Force
   NSIS
   Internet Draft                                         H. Tschofenig
                                                          D. Kroeselberg
                                                                 Siemens
   Document:
        draft-ietf-nsis-threats-03.txt
   draft-ietf-nsis-threats-04.txt
   Expires: April August 2004                                   February 2004                                     October 2003

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

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

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

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

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

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

Abstract

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

Table of Contents

   1. Introduction...................................................2 Introduction..................................................2
   2. Relevant communication models..................................3 Communications Models................................3
      2.1 First-Peer Communication...................................5 Communications.................................5
      2.2 End-to-Middle Communication................................6 Communications..............................6
      2.3 Intra-Domain Communication.................................6 Communications...............................6
      2.4 Inter-Domain Communication.................................6 Communications...............................6
      2.5 End-to-End Communication...................................7 Communications.................................7
      2.6 Middle-to-middle Communication.............................8 Middle-to-Middle Communications...........................8
   3. Generic Threats................................................8 Threats...............................................8
      3.1 Man-in-the-middle attacks..................................8 Man-in-the-Middle Attacks.................................8
      3.2 Adversary being able to replay signaling messages.........10 Replay of Signaling Messages.............................10
      3.3 Adversary being able to inject/modify messages............10 Injecting or Modifying Messages..........................11
      3.4 Insecure Parameter Exchange/Negotiation...................11 Exchange and Negotiation..............11
   4. Signaling specific Threats....................................11 NSIS-Specific Threat Scenarios...............................11
      4.1 Threats based on NSIS SA Usage............................11 Usage............................................12
      4.2 Threats based on combining Combining Signaling and SA Establishment.11 Establishment.................12
      4.3 Eavesdropping and Traffic Analysis........................12 Analysis.......................13
      4.4 Identity Spoofing.........................................13 Spoofing........................................13
      4.5 Missing Protection of Unprotected Authorization Information...........14 Information....................15
      4.6 Missing Non-Repudiation...................................15 Non-Repudiation..................................16
      4.7 Malicious NSIS Entity.....................................16 Entity....................................17
      4.8 Denial of Service Attacks.................................17 Attacks................................17
      4.9 Disclosing the network topology...........................18 Network Topology..........................18
      4.10 Missing protection of Session/Reservation Ownership......19 Unprotected Session or Reservation Ownership............19
      4.11 Attacks against the transport mechanism..................20 Transport Mechanism.................20
   5. Security Considerations.......................................20 Considerations......................................21
   6. Normative References..........................................20 References.........................................21
   7. Informative References........................................21
        Acknowledgments..................................................22 References.......................................22
   Author's Addresses...............................................22 Addresses..............................................23
   Full Copyright Statement.........................................22 Statement........................................23

1. Introduction

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

   - NSIS Analysis Activities (e.g. (e.g., RSVP Security Properties)
   - Security Threats for NSIS
   - NSIS Requirements
   - NSIS Framework
   - NSIS Protocol Proposals
   This document identifies the basic security threats that need to be
   addressed by during the NSIS signaling protocol design. This document
   cannot provide detailed threats for all possible NSIS NSLPs. QoS,
   NAT/Firewall and other NSLPs documents need to provide a description
   of their trust models and a threat description for their specific
   application domain. In addition, although the base protocol might be
   secure, some certain extensions may cause problems when used in a
   particular environment. Furthermore Furthermore, it is necessary to investigate
   the context in which a signaling protocol is used and the
   architecture where into which it is integrated. As an example of such interaction
   interaction, accounting and charging are taken into account in this
   document, since because without an appropriate integration of the two two, it
   is difficult to deploy any NSIS solution. This interaction is also a
   subject to of discussion within the NSIS framework.

        This document uses Framework.

   We use the NSIS terms defined in [Bru03]. [Brun03].

2. Relevant communication models Communications Models

   Signaling messages traverse different network parts, which parts of a network, demand
   different security protection protection, and raise different security
   problems. The difference in different needs for security protection is are mainly caused by due
   to the fact that the NSIS signaling messages cross trust boundaries into
   domains where different trust relationships are prevalent. Often a categorization
        into first-peer/last-peer, intra-domain and exist. Often, one may
   describe this by categorizing communications as first-peer, last-
   peer, intra-domain, or inter-domain
        communication is applicable (see Figure 1).

   The main properties of the listed network parts of a network listed here are
   briefly described in this section section, and the threats of Section against them in
   Sections 3 and Section 4 classify
        them to are classified as generic threats and signaling specific threats. NSIS specific. Figure
   1 depicts a typical end-to-end communication scenario including an
   access part parts between the NSIS end entities end-entities and the their nearest NSIS hops,
        respectively.
   hops. This "first-peer communication" communications" commonly comes with specific
   security requirements (as described below), below) that are especially
   important for properly addressing security in mobile scenarios.
   Differences in the trust relationship and the required security for
   first-peer communication, compared to with other parts of the signaling
   path, might exist.

   To refine the above differentiation based on the network parts that
   NSIS signaling may traverse, we consider trust relationships between
   different network parts.

   Additional threats may apply to NSIS communications in which one
   entity involved is an end-entity (Initiator or Responder) and the
   other entity is any intermediate hop except the immediately adjacent
   peer. This is typically called the end-to-middle scenario (see
   Figure 2 for a description of relevant trust relations).

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

                       Figure 1: Involved NSIS Network Parts

        To further refine the above differentiation based on network parts
        that NSIS signaling may traverse, we consider trust relationships
        between NSIS hops.
        Additional threats may apply to NSIS communication where one entity
        involved is an end-entity (initiator or responder) and the other
        entity is any intermediate hop not being the first peer. This is
        typically called end-to-middle scenario.

   The motivation for including this configuration stems scenario stems, for example example, from
   the SIP [RFC3261] protocol. To counter a number of specific security
   threats, any intermediate SIP hop may request a SIP end entity end-entity (UA)
   to authenticate. Such functionality in general seems to be generally useful for
   intermediaries at the borders of trust domains that signaling
   messages need to traverse.

   Intermediate NSIS hops as well may have to deal as well with specific
   security threats that do not (directly) relate to 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 border borders of
   their respective trust domains (i.e. (i.e., inter-domain communication). 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 case and
   last-peer cases discussed further above is are covered by the peer-to-peer
   trust relationships between end entity end-entity and closest hop, respectively. 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 Communication

        First peer communication Communications

   First-peer communications refers to the peer-to-peer interaction
   between a signaling message originator, the NSIS Initiator (NI), and
   the first NSIS aware NSIS-aware entity along the path. Assumptions Making assumptions about
   the threats, security requirements requirements, and the available trust
   relationships may be difficult here.

   To illustrate this, in many mobility public mobile environments it is difficult to
   assume the existence of a pre-established security association
   directly available for NSIS peers involved in first-peer
        communication, as
   communications, because these peers cannot be assumed to have any relation
   pre-existing relationship between each other in advance. other. For enterprise
   networks, in contrast, the situation is different. Usually there is
   a fairly strong (pre-
        established) (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. Per-session infrastructure, and per-session
   negotiation of security mechanisms is therefore often not required (which, in
   contrast, is required for the mobility public mobile case).

   For first-peer communication, especially communications, especially, threats related to
   initial security association setup, or threats due to replay
   attacks, lack of confidentiality, denial of service, integrity violation
   violation, or identity spoofing are relevant, an and potentially lead
   to theft of service and
        fraud. service,  fraud, or violations of privacy.

2.2 End-to-Middle Communication Communications

   End-to-middle interaction in signaling may be required required, e.g., to e.g.
   grant end-entities access to specific services in trust domains
   different from the one to which the first peer belongs to. 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. (e.g., IPsec hop-by-hop hop-
   by-hop protection).

2.3 Intra-Domain Communication Communications

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

2.4 Inter-Domain Communication Communications

   The threat assumptions between the borders of different
   administrative domains largely depend on the authorization
   procedures. If one domain forges QoS reservations reservations, then this domain
   may also have to pay for the reservation. Hence Hence, in this case, there
   is no real benefit for this domain to forge a QoS reservation. If an
   end host is directly charged by intermediate domains (i.e. (i.e., by a
   domain different from the malicious domain) domain), such an attack may be
        quite a reasonable
   quite realistic threat.

        However, security

   Security protection of messages transmitted between different
   administrative domains is still necessary to tackle attacks like spoofing,
   integrity violation, or denial of service between these domains, e.g.
   e.g., to allow proper accounting. The number of neighboring domains
   is usually rather limited (compared to with first-peer
        communication) communications),
   which causes fewer problems for substantially reduces the key management
        required considerations for
   securing inter-domain NSIS signaling.

   Signaling information other than QoS service parameters parameters, such as
   policy rules in the case of middlebox communication demands communications, places
   different assumptions for on inter-domain communication. Trust assumptions and
        business communications. Business
   relationships and trust assumptions are of particular importance as
   a basis for their
        communication. securing these communications.

   If signaling messages are conveyed transparently in the core network
        (i.e.
   (i.e., they are not neither intercepted and nor processed in the core network)
   network), then the signaling message communication communications effectively
   takes place between potentially distant access networks. This might
   place a burden on the key management infrastructure required between
   these access networks networks, which might not know of each other in
   advance. This might lead to an inability to secure signaling
   messages for a direct communication communications between the access networks.
   Hence, this can be seen as a serious deployment problem since problem, because it
   might be unacceptable for an access network service provider to
   perform processing (QoS reservations, (e.g., QoS reservations or policy rule
   installation at firewalls) triggered by unprotected unprotected,
   unauthenticated, and possibly unauthorized incoming signaling
   messages.

2.5 End-to-End Communication Communications

   NSIS aims to signal information between the initiator Initiator and the
        responder.
   Responder. This section refers to the trust 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 related
        information. charging. Protecting the entire signaling message end to end is
   not possible
        since normally regarded as feasible, because intermediate NSIS nodes
   need to (a) to inspect various objects and (b) need to add, modify modify, or
   delete objects from the signaling message.

   The following example tries to illustrate illustrates a possible application of
        end-to-end end-to-
   end protection for objects carried within the NSIS signaling
   protocol. Alice, the data sender, wants Bob, the data receiver, to
   pay for a QoS reservation (reverse charging). Bob wants to be
   assured that the QoS signaling message he receives was indeed
   transmitted by
        Alice Alice, because he is only willing to pay for
   particular users and not for everyone. Hence Hence, Bob wants to verify
   that the request came from Alice (authentication) and that the
   included parameters are
        unmodified. unmodified (integrity). Additionally it
   might be necessary to secure a negotiation step and to secure deliver
   authorization information securely to the involved parties. parties involved.
   Information which is required to compute render an 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. (i.e., making Bob has to pay more), fraud (i.e. too much), to force
   fraud (i.e., forcing Bob always to pay for the reservations) reservations), to
   identity spoofing
        (i.e. the adversary claims (i.e., an impostor claiming to be Alice).

   Regarding end-to-end security security, one additional issue needs to be
        addressed -
   addressed: delegation. Whenever a signaling is addressed end-to-end end to end
   and an arbitrary node along the path acts as a proxy on behalf of
   the other endpoint endpoint, a delegation mechanism is required to provide
   secure interaction. This might lead to additional complexity.

2.6 Middle-to-middle Communication

        We do not explicitly consider the Middle-to-Middle Communications

   The middle-to-middle case is not explicitly considered here,
   although it is important, since because it is already covered by either
   intra- or inter-domain communication communications depending on the location locations of
   the
        involved entities. entities involved.

3. Generic Threats

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

     3.1 Man-in-the-middle

   For the following subsections, we use the general distinction into
   two cases in which attacks

        We differentiate this type of attack may occur. These are according to the separation of
        different
   separate steps, or phases, for securing protocols that is typically
        made. normally encountered when applying
   protocol security (with, e.g., IPsec, TLS, Kerberos, or SSH).
   Therefore, this section starts with a brief motivation of 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 usually tends to
   be more expensive than the second second, which is also the main reason for the
   separation. If messages are transmitted very infrequently infrequently, then these two
   steps are may be collapsed into a single and usually rather costly step. one.
   One such example is e-mail protection via S/MIME. An
        example for The two steps may
   be tightly bound into a two-step approach is provided by IKE/IPsec. 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.
        The first paragraph

3.1 Man-in-the-Middle Attacks

   This section describes both (1) security threats where that exist if two
   peers do not already share a security association, association or do not use
   security mechanisms at all. The next paragraph describes all, and (2) threats which that are applicable when
   a security association is already established.
        Finally Note also that a
   denial of service attack is described which is applicable
        to on a signaling message protocol exists when no
   separation between SA establishment and signaling protection takes
   place. Particularly the The discovery
        procedure procedure, in particular, is vulnerable against to a
   number of such attacks.

   - Attacks during NSIS SA Establishment

        During the process of

   While establishing a security association association, an adversary fools the
   signaling message initiator Initiator with respect to the entity to which it
   has to authenticate. The man-in-the-middle
        adversary Initiator authenticates to the man-in-the-
   middle adversary, who is then able to modify signaling messages to
   mount DoS attacks. attacks or steal services that get billed to the
   Initiator. In addition, it may be able to terminate the Initiator's
   NSIS messages of the
        Initiator and inject messages to a peer itself, therefore
   acting as the peer to the initiator Initiator and as the initiator Initiator to the
   peer. This results in the initiator Initiator wrongly believing that it talks is
   talking to the "real" network network, whereas it is actually attached to an
   adversary.
   For this attack to be successful, pre-conditions have to hold which
   are described with in the following two cases:

   - Missing Authentication

        The

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

   - Unilateral Authentication

   In the case of a unilateral authentication authentication, the NSIS entity that does
   not authenticate its peer is unable to discover the a man-in-the-middle
   adversary. Although mutual authentication of signaling messages
   should take place between each peer participating in the protocol operation
   operation, special attention is given here to first-peer communication.
   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 MITM 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, are is part of
   a general problem of network access without appropriate with inadequate authentication,
   and it should not be considered as  valid for something unique to the NSIS
   signaling
        protocol, only. Obviously protocol. Obviously, there is a strong need to correctly
   address
        them this in a future NSIS protocol. The signaling protocols
   addressed by NSIS are different to from other protocols, where in which only
   two entities are involved. Note, Note that especially first-peer authentication is
   especially important, as the impacts of because a security breach here could impact
   nodes beyond the entities directly involved entities (or even beyond a local
   network).

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

   - Weak Authentication

        This

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

3.2 Adversary being able to replay signaling messages Replay of Signaling Messages

   This threat scenario covers the case where in which an adversary
   eavesdrops and collects signaling messages and replays them at a
   later point in 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 way, e.g., cut-and-paste attacks).
   Without proper replay protection protection, an adversary might mount man-in-the-middle, man-in-
   the-middle, denial of service service, and theft of service attacks.

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

3.3 Adversary being able to inject/modify messages Injecting or Modifying Messages

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

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

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

3.4 Insecure Parameter Exchange/Negotiation

        Protocols, which should Exchange and Negotiation

   First, protocols may be useful for in a variety of scenarios, tend to scenarios with
   different security requirements. Second, different users (e.g., a
   university, a hospital, a commercial enterprise, or a government
   ministry) have inherently different security requirements. Third,
   different parts of a network (e.g., within a building, across a
   public carrier's network, or over a private microwave link) may need
   different levels of protection. It is often difficult to meet these
   (sometimes conflicting requirements) conflicting) requirements with a single security
   mechanism or fixed set of security parameters. Often parameters, so often a selection
   of mechanisms and parameters are is offered. Therefore Therefore, a protocol exchange is
   required to agree on some certain security mechanisms/parameters. mechanisms and parameters. An
   insecure parameter exchange/negotiation protocol exchange or security negotiation protocol can
   help an adversary to mount a downgrading attack by selecting to force selection of
   weaker mechanisms than mutually desired. Hence Hence, without protecting binding the
   negotiation process to the security of legitimate parties and protecting it, an
   NSIS protocol might be only as secure as the weakest mechanism if no
   provided (e.g., weak authentication), and the benefits of defining
   configuration parameters (for example and a
        security policy disallowing the weakest mechanism, etc.) negotiation protocol are used
        otherwise. lost.

4. Signaling specific Threats NSIS-Specific Threat Scenarios

   This section lists both threats and describes 11 threat scenarios in terms of attacks on
   and security deficiencies in the NSIS signaling protocol. A number
   of reasons security deficiencies might lead to enable an attack. Fraud is an example
   of an attack which that might be caused enabled by a number of reasons: missing replay protection,
   missing protection of authorization tokens, identity spoofing,
   missing authentication authentication, and many more might other deficiencies that help an
   adversary to steal resources. These reasons which Different threat scenarios based on
   deficiencies that could lead
        to enable an attack are primarily addressed in this
   section.

        In some cases we point to specific attacks which again might have a
        subsequent result since well-established security terms, such as

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

4.1 Threats based on NSIS SA Usage

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

4.2 Threats based on combining Combining Signaling and SA Establishment

        These threats may lead to

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

   When a signaling message arrives at an NSIS aware NSIS-aware network element
        some element,
   certain processing is required. If this message contains security
   objects such as digital signatures signatures, and no security association is
   already available available, then some additional processing is required for
   the cryptographic verification. Since Because NSIS signaling should not
   require
        several extra roundtrips between two NSIS peers peers, it is difficult to
   provide the DoS protection mechanisms commonly found in
   authentication and key agreement protocols. Signaling messages can
   be idempotent idempotent, which means that they contain the same amount of
   information as the original message. An example would be a 'refresh' refresh
   message which that is in this
        case equivalent to a create message. This property enables that allows
   a refresh message creates to create new state along a new path path, although no
   previous state is available. In order for For this to work it is
        necessary to use work, specific classes of
   cryptographic mechanisms supporting this behavior. behavior are needed. An
   example is a digital signature based scheme based on digital signatures, which, however,
   should be used with care due to possible denial of service attacks. The problems of
   Problems with using these types of message exchanges with public key based
   protection are described in [AN97] and in [ALN00].

        Additionally

   In addition to the threat scenario described above above, an incoming
   signaling message might require time consuming processing
   (computations, state maintenance, timer setting, etc) etc.) and
   communication with third-party nodes including such as policy servers, LDAP
   servers, etc. If an adversary is able to transmit a large number of
   signaling messages (for example example, with QoS reservation requests) with
   invalid credentials credentials, then the verifying node may not be able to
   process further other reservation messages by from legitimate users.

   Further threats could attacks may be introduced by allowing an adversary to gain
        additional information enabled by injecting error messages or by
   forcing the creation of error messages. messages to extract additional
   information.

4.3 Eavesdropping and Traffic Analysis

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

        The

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

        Note, is exchanged.

   Note that the above threats are also applicable if the messages are this threat scenario is not mitigated by applying
   integrity protected protection to the messages, which is often considered
   sufficient for signaling protocols.

        Since

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

4.4 Identity Spoofing

   Identity spoofing relevant for NSIS, appears NSIS occurs in two flavors: First, forms: first,
   identity spoofing can appear happen during the establishment of a security
   association if based on a weak authentication mechanism. mechanismn and, second,
   it can consist of spoofing data traffic.

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

        An

   In the second case, an adversary is may be able to exploit the
   established flow identifiers (required for QoS and middlebox
   communication (Midcom) [Midcom] specific signaling protocols). Some identifiers such as
   identifiers, among others, IP addresses, transport protocol
   identifiers, port numbers, and flow labels (see [RFC1809] and [RC+03]) and others
   [RC+03]), are communicated transported in these protocols. Modification of these
   flow identifiers causes allows adversaries to exploit or to render
   ineffective quality of service reservations or policy rules at middleboxes to be either
        ineffective or exploitable by adversaries.
   middleboxes. An adversary could mount an attack by modifying the
   flow identifier of a signaling message.

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

   The following threat is caused carried out by identity spoofing the identity of
   transmitted data traffic. The spoofed identity is thereby the source IP
        addresses. source
   address. For this attack to be successful successful, accounting records are
   collected based on the source IP source address and not on a SPI due to
        IPSec
   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
   example, the edge router). These Traffic Selectors are used for flow
   identification and allow to match data traffic originated from a given source
   address to be matched and assigned to a particular QoS reservation.
   The adversary Eve now spoofs the IP address of the Alice.
        Additionally In
   addition, Alice's host may be crashed by the adversary as a result
        of with a denial
   of service attack or lost connectivity may lose connectivity, for example example, because of
   mobility reasons. considerations. If both nodes are located at the same link
   and use the same IP address address, then obviously a duplicate IP address
   will be detected. Assuming that only Eve is now present at the
        link then link,
   she is able to receive and transmit data (for example RTP data traffic), which
   traffic) that receives preferential QoS treatment based on the
   previous reservation. Depending on the installed Traffic Selector
        granularity
   granularity, Eve might have more possibilities to exploit the QoS
   reservation or a pin-holed firewall. Assuming the soft state
   paradigm, where periodical whereby periodic refresh messages are required, the
   absence of Alice will not be detected until the next signaling
   message appears and forces Eve to respond with a protected signaling
   message.
        Again Again, this issue attack is not only applicable not just to QoS traffic traffic,
   but the existence of a QoS reservation causes more difficulties since increases its impact, because
   this type of traffic is more expensive. The same procedure attack is also
   applicable to a Middlebox communication protocol.

   The ability for an adversary to inject data traffic which that matches a
   certain flow identifier established by a legitimate user often
   requires the ability to also to receive the data traffic. This is,
   however, only true only if the flow identifier consists of values which that
   contain addresses used for routing. If we imagine to use using attributes
        for
   of a flow identifier where that do not require such a property is not required property, then
   identity spoofing and injecting traffic is are much easier. An
   adversary can use a nearly arbitrary endpoint identifier to experience achieve
   the desired result. Obviously Obviously, though, the endpoint identifiers are still
   not
        irrelevant since irrelevant, because the messages have to travel the same path
   through the network.

   Data traffic marking based on DiffServ is such an example. Whenever
   an ingress router uses only marked incoming data traffic for
   admission control procedures procedures, then various attacks are possible.
   These problems are have been known in the DiffServ community for a long
   time and have been documented in various DiffServ related DiffServ-related documents.
   The IPSec 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 Missing Protection of Unprotected Authorization Information

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

   Typically the authenticated identity identifier is used to assist during the
   authorization procedure as e.g. as, e.g., described in [RFC3812]. Depending
   on the chosen authentication protocol protocol, certain threats may exist.
   Section 3 discusses a number of issues related to this approach when
   the authentication and key exchange protocol is used to establish
   session keys for signaling message protection.

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

        The

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

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

4.6 Missing Non-Repudiation

   Repudiation in this context refers to a problem where one party
   later denies to have requested having taken a certain action (such as requesting a QoS
   reservation). The problem of Problems stemming from a missing lack of non-repudiation property
        appears
   appear in two flavors:

        From forms:

   On the one hand, from a service provider point-of-view provider's point-of-view, the
   following threat may be worth an investigation. A user may deny to have having
   issued a reservation request for which it was charged. A The service
   provider may then like want to be able to prove that a particular user
   issued the reservation requests.

        The request in question.

   On the other hand, the same threat can be interpreted from the a user's
   point-of-view. A service provider claims may claim to have received a
   number of reservation requests. The user in question thinks that he it
   never issued those requests and wants to have see a proof for of correct
   service usage for a given set of QoS parameters.

   In today's telecommunication networks networks, non-repudiation is not
   provided. The user has to trust the network operator to correctly meter the traffic,
   traffic correctly, collect and merge accounting data data, and ensure
   that no unforeseen problems occur. If a signaling protocol is used to
        establish QoS reservations with the
   non-repudiation property is desired for establishing QoS
   reservations for the authorized resources then it has an impact on resources, this impacts the protocol
   design.

   Non-repudiation poses additional requirements on the security
        mechanisms as
   mechanisms, because it can only be provided through public-key
        cryptography. As cryptography is needed to provide
   it. Because this would often normally increase the overall cost for
   security, threats related to missing non-repudiation are only
   considered relevant for in certain specific scenarios (e.g. cases (e.g., specific
   authorization mechanisms) and not for general NSIS signaling.

4.7 Malicious NSIS Entity

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

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

   For an adversary to mount this attack attack, either an existing NSIS aware NSIS-aware
   node along the path has to be successfully attacked successfully, or an adversary
        succeeds to convince
   must succeed in convincing another NSIS node to be the next NSIS
   peer (man-
        in-the-middle (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 messages, etc., are mentioned throughout this document.

   - Path Finding

   This threat tries to address scenario includes potential denial of service DoS attacks that exist when
   the reservation setup is split into two phases i.e. phases, i.e., path and
   reservation (as used, for example used example, in receiver based receiver-based reservation
   setup). For In this example we assume case, assuming that the node transmitting the path
   message is not charged for the path message itself and is itself, it may be able
   to issue generate a high large number of reservation requests (possibly in a
   distributed fashion). Charging is activated only after successful
   verification of the reservation request. The reservations are however are,
   however, never intended to be successful because of for various reasons: the
   destination node cannot be reached; it is not responding responding; or it
   simply rejects the reservation. An adversary can benefit from the fact that succeed because
   state has already been allocated along the path for various
   processing tasks including path pinning.

   - Discovery Phase

        Signaling

   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 since attacks, because it is difficult to
   secure. An adversary can use the discovery mechanisms to convince an
   one entity to signal information to another entity which is not along the
   data path or to cause the discovery process to fail. In the first case
   case, the signaling protocol could be correctly continued with the problem 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 host, this means that the protocol failed for unknown reasons.

   - Faked Error/Response messages Error or Response Messages

   An adversary may be able to inject false error/response error or response messages
      as part of a denial of service DoS attack. This could be either at the
        message signaling
      message protocol level layer (NTLP), at the level layer of each client layer
      protocol (NSLP: QoS, Midcom, etc.) etc.), or at the transport level
        protocol. protocol
      layer. An adversary might cause unexpected protocol behavior, behavior or
      might succeed with denial of service attacks. Especially the a DoS attack. The discovery protocol shows protocol,
      especially, exhibits vulnerabilities with regard to this threat
      scenario (see the above discussion on discovery). In the case that in
      which no separate discovery protocol is used by addressing and signaling
      messages are addressed to end hosts only (with a Router Alert
      Option to intercept message as NSIS aware nodes) then nodes), an error
      message might be used to indicate a path change. Such a design is a combination of
      combines a discovery protocol together with a signaling message
      exchange protocol.

4.9 Disclosing the network topology Network Topology
   In some architectures organizations or enterprises there is a desire not to reveal the
   internal network structure (or other related information) to the outside
        world. of
   a closed community. An adversary might be able to use NSIS messages
   for network mapping (e.g. (e.g., discovering which nodes exist, which use
   NSIS, what version, what resources are allocated, what capabilities of
   nodes along a
        paths path have, etc.). Discovery messages, traceroute,
   diagnostic messages (see [RFC2745] for a description of diagnostic
   message functionality for RSVP), and query messages messages, in addition to
   record route and route objects objects, provide the potential assistance to assist an
   adversary. Hence Hence, the requirement of not disclosing a network
   topology might conflict with another
        requirement other requirements to provide means for
   automatically discovering NSIS aware NSIS-aware nodes or to provide diagnostic
   facilities (used for network monitoring and administration).

4.10 Missing protection of Session/Reservation Unprotected Session or Reservation Ownership

   Figure 3 shows an NSIS Initiator which that has established state
   information at NSIS nodes along the a path as part of the signaling
   procedure. As a
        result the result, Access Router1 Router 3 1, Router 3, and Router 4 (and
   other nodes)
        store have stored session state information including the
   Session Identifier SID-
        x. 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/Reservation Session or Reservation Ownership

   The Session Identifier is included in signaling messages to
   reference to the established state.

   If an adversary was were able to obtain the Session Identifier Identifier, for
   example by eavesdropping on signaling messages messages, it is would be able to
   add the same Session Identifier SID-x to a new signaling message.
   When the new signaling message hits Router3 Router 3 (as shown in Figure 3) then 3),
   existing state information can be modified. The adversary can then
   modify or delete the established reservation causing and cause unexpected
   behavior for the legitimate user.

   The source of the problem is that Router3 (cross-over Router 3 (a cross-over router) is
   unable to decide whether the new signaling message was initiated
   from the owner of the session/reservation. session or reservation.

   In addition, not only nodes other than the initial signaling message
   originator is are allowed to signal information during the lifetime of
   an established session. As part of the protocol protocol, any NSIS aware 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 is were allowed to
   trigger signaling message exchanges exchanges, some protocol behavior would
   not be possible.

        In case that

   If this threat scenario is not addressed addressed, an adversary can launch
        denial of service,
   DoS, theft of service, and various other attacks.

4.11 Attacks against the transport mechanism Transport Mechanism

   In [BL01] a two-level architecture is proposed proposed, which suggests to
        split
   splitting an NSIS protocol into layers: a signaling message transport
        specific
   transport-specific layer and an application specific application-specific layer. This
   architectural assumption is also considered within the NSIS
   framework [HF+03]. Most of the threats described in this document
   are applicable to the
        application specific application-specific part for (i.e., signaling QoS
   or middlebox specific
        information. middlebox-specific information). There are, however, some threats which
   that are applicable to the transport of signaling messages.

   Network or transport layer protocols lacking protection mechanisms
   are vulnerable to certain attacks such as header manipulation, DoS,
   spoofing of identities, session hijacking, unexpected aborts aborts, etc.

   Malicious nodes can attack the congestion control mechanism to force
   NSIS nodes into a congestion avoidance state.

   In the case that an in which existing protocol is protocols are used for exchanging NSIS
   signaling messages then threats messages, known from threats scenarios applicable to these
   protocols are relevant.

5. Security Considerations

   This entire memo discusses security issues relevant for NSIS. NSIS
   protocol design. It begins by identifying the components of a
   network running NSIS (Initiator, Responder, and different
   Administrative Domains between them). It then considers five cases
   in which communications take place between these components, and it
   examines the trust relationships presumed to exist in each case:
   First-Peer Communications, End-to-Middle Communications, Intra-
   Domain Communications, Inter-Domain Communications, and End-to-End
   Communications. This analysis helps determine the security needs and
   the relative seriousness of different threats in the different
   cases.

   The document points out the need for different protocol security
   measures: authentication, key exchange, message integrity, replay
   protection, confidentiality, authorization, and some precautions
   against denial of service. The threats are subdivided into generic
   ones (e.g., man-in-the-middle attacks, replay attacks, tampering and
   forgery, and attacks on security negotiation protocols) and 11
   threat scenarios particularly applicable to the NSIS protocol.
   Denial of service, for example, is covered in the NSIS-specific
   section, not because it cannot be carried out against other
   protocols, but because the methods used to carry out denial of
   service attacks tend to be protocol specific. Numerous illustrative
   examples provide insight into what can happen if these threats are
   not mitigated.

   This document points out repeatedly that not all of the threats are
   equally serious in every context. It does attempt to identify the
   scenarios in which security failures may have the highest impact.
   However, it is difficult for the protocol designer to foresee all
   the ways in which NSIS protocols will be used or to anticipate the
   security concerns of a wide variety of likely users. Therefore, the
   protocol designer needs to offer a full range of security
   capabilities and ways for users to negotiate and select what they
   need, case by case. To counter these threats threats, security requirements
   have been listed in [Brun03]. Framework Topics relevant topics to the NSIS Framework
   have been incorporated into [HF+03].

6. Normative References

   [Brun03] M. Brunner, "Requirements for QoS signaling protocols,"
   Internet Draft, Internet Engineering Task Force, August 2003.  Work
   in progress.

7. Informative References

   [HF+03] R. Hancock, I. Freytsis, G. Karagiannis, J. Loughney, and S.
   V. den Bosch, "Next steps in signaling: Framework," Internet Draft,
   Internet Engineering Task Force, September 2003.  Work in progress.

   [RFC1809] C. Partridge, "Using the flow label field 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 for RSVP", RFC
   3182, October, 2001.

   [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston,
   J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
   initiation protocol," RFC 3261, Internet Engineering Task Force,
   June 2002.

   [RFC3521]   L. Hamer, B. Gage, and H. Shieh, "Framework for session
   set-up with media authorization," RFC 3521, Internet Engineering
   Task Force, April 2003.

   [RFC3520] L. Hamer, B. Gage, B. Kosinski, and H. Shieh, "Session
   Authorization Policy Element", RFC 3520, Internet Engineering Task
   Force, April 2003.

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

   [BL01] B. Braden and B. Lindell, "A two-level architecture for
   internet signaling," Internet Draft, Internet Engineering Task
   Force, Nov. 2001. (Expired).

   [AN97] T. Aura and P. Nikander: "Stateless Connections", In
   Proceedings of the International Conference on Information and
   Communications Security (ICICSĂ97), (ICICS'97), Lecture Notes in Computer
   Science 1334, Springer, 1997.

   [ALN00] T. Aura, J. Leiwo 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.

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

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

Appendix B. Acknowledgments

   We would like to thank (in alphabetical order) Marcus Brunner, Jorge
   Cuellar, Mehmet Ersue, Xiaoming Fu Fu, and Robert Hancock for their
   comments to 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 Solwitsch, Soltwisch, Cornelia
   Kappler, and Mohan Parthasarathy provided comments to on a recent
   version of this draft. Their input helped to improve the content of
   this document. Particularly Roland Bless, Michael Thomas Thomas, and Cornelia Kappler Kappler,
   in particular, provided good proposals for regrouping and
        restructuring.

     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
   restructuring the material.

   A final review was given by Michael Richardson. We thank him for the
   detailed comments.

Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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

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