[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
NEMO Working Group                                          Souhwan Jung
Internet-Draft                                       Soongsil University
Expires: April, 2004                                            Fan Zhao
                                                                Felix Wu
                                                                UC Davis
                                                             HyunGon Kim
                                                            SungWon Sohn
                                                                    ETRI
                                                           October, 2003


                         Threat Analysis for NEMO
                     draft-jung-nemo-threat-analysis-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   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/ietf/1id-abstracts.txt.

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

   This Internet-Draft will expire on December 22, 2003.

Copyright Notice

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


Abstract

   This document describes possible security threats on mobile networks.
   Many different kinds of security threats exist on signaling and
   communication paths including mobile routers and home agents.
   It is also the goal of this draft to explain a three-layer threat
   model, to investigate vulnerabilities to the network entities in
   NEMO, and finally to propose security requirements for NEMO.


Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119.


S. Jung et. al.            Expires April, 2004                  [Page 1]


Internet-Draft            Threat Analysis for NEMO          October 2003


Table of Contents


   1.    Motivations

   2.    Three-Layer Threat Model

   3.    Generic Threats to Target Protocols/Services
         3.1 Threats to Signaling Paths
         3.2 Threats to Communication Paths

   4.    Generic Threats to Target Entities/Entry Points
         4.1 Misbehaviour of MR
         4.2 Misbehaviour of HA
         4.3 Traffic Analysis
         4.4 Denial of Service

   5.    Threats specific to NEMO basic support protocols
         5.1 Corruption of Binding Cache by inside attacker
         5.2 Attack using HA as a stepping stone
         5.3 Attack to Location Privacy by Traffic Analysis

   6.    Security Requirements

         References

         Authors' Addresses

         Intellectual Property and Copyright Statements


S. Jung et. al.            Expires April, 2004                  [Page 2]


Internet-Draft            Threat Analysis for NEMO          October 2003


1. Motivations

Networks in motion (NEMO) introduces a new network entity called Mobile
Router(MR)[2]. MR has different features from Mobile Host that is operated
based on Mobile IP technologies[4]. Since MR functions both as a mobile
node and a gateway to provide mobile network with Internet access to
outside world, it needs specific treatment for managing operations and
securities.

In real world, many different types of NEMO configurations are possible
including multi-homing, which means that new kind of threats specific to
NEMO SHOULD be taken care of. For example, MR can advertise its IP
prefix to the VMNs in its mobile network, and this RA message can be
intercepted and modified to advertise the prefix of malicious router.
This makes address spoofing attack possible: the packets that should be
delivered to the destination mobile router are redirected to the attack
router. Therefore, those messages like RA should be protected using
authentication.

This draft proposes a three-layer threat model for analyzing
vulnerabilities to NEMO protocols and entities. Based on the model, we
describe and classify all possible threats to NEMO, and analyze those
threats according to their properties and scopes. Finally, we describe
the security requirements for NEMO.


2. Three-Layer Threat Model

Many different threats to network entities in NEMO are possible and hard
to describe all of them in a row. Some of the threats can have multiple
paths to achieve their goals, which means that many different types of
attacks are possible to obtain the same objective that the attacker
tries to achieve. Therefore, it requires a hierarchical threat model to
describe and classify all different types of threats to NEMO.

This draft proposes a three-layer threat model to describe possible
threats to NEMO according to their objectives/properties, target
protocols/services, and target entities/entry points. This model is
composed of a three-layer stack; objectives/properties on the top layer,
target protocols/services for attack on the second layer, and finally
target entities or entry points for attack at the bottom layer.


S. Jung et. al.            Expires April, 2004                  [Page 3]


Internet-Draft            Threat Analysis for NEMO          October 2003



The objectives of threats are usually a limited number of goals that
attackers try to achieve in abstract level. They could be like
eavesdropping of data, impersonation, data corruption or modification,
unauthorized use of resources, repudiation, and blocking services to
clients. The generic goals of security mechanisms against those attacks
therefore are such as confidentiality, integrity, authentication,
authorization, non-repudiation, and service availability, which are
common to all of the security frameworks.

The second layer of the stack is composed of target protocols or services
for attack. Attackers always try to find vulnerabilities to network
protocols or services by monitoring protocol or service data specific to
the target. In NEMO, for example, binding update(BU) message or router
advertisement(RA) messages by MRs could be target data for attack. Most
of NEMO signaling protocols could be the target at the second layer.
Therefore, the vulnerabilities to the basic NEMO mechanism should be
scrutinized for the analysis. In the next section, this draft will
describe those vulnerabilities and possible threats related to them.

The bottom layer of the threat model is comprised of target entities or
entry points for attacks. NEMO includes many network entities called MR,
HA, CN, and MNN etc. Any of these entities could be a victim for attack,
and be compromised. All the possibilities of different types of attacks
should be investigated based on the assumption of these compromises.
For example, the compromise of MR can result in the data interception
of the MNNs inside or the deception of their connection to a fake HA
or FA. The MNNs have no knowledge of the compromised MR, since the NEMO
protocols are transparent to the MNNs. In section 4, those threats will
be analyzed and described.


3. Threats to Target Protocols and Services

This section describes threats to NEMO protocols and services. NEMO
operations are composed of two different planes; one is the signaling
plane for exchanging control or routing information, and the other is
the communication plane for exchanging data between nodes. The threats
specific to each plane will be investigated.

3.1 Threats to Signaling Paths
The basic NEMO operations have three different signaling paths between
entities; the first path is the signaling between MR and FA, the second
one is the signaling between MR and HA, and the final one is the
signaling between MNN and CN. Each signaling messages can be interrupted
and modified by attackers on the way of the signaling paths. The following
threats exist over signaling paths.


S. Jung et. al.            Expires April, 2004                  [Page 4]


Internet-Draft            Threat Analysis for NEMO          October 2003



     - Man-in-the-middle between MR and HA
       This threat means that an attacker resides between MR and HA, and
       intercepts the signaling messages such as CoA(Care-of-Address) in
       BU messages. The messages could be modified and transferred to the
       HA with corrupted information. For example, the attacker compromises
       the access router, and intercepts and modifies all the messages that
       goes through the access router. One of the attack results will be
       the registration of MR to HA with wrong binding information.
       Security mechanism for bi-directional tunneling like IPsec could
       prevent this threat.

     - Discard registration messages from MR to FA
       This threat is a sort of DoS attack to block network connectivity
       service to MR. The attacker compromises the FA, and keep discarding
       the registration message from MR. The result of the attack is no
       availability of network connection service to the mobile networks.

     - Spoofing MR
       Mobile network could have multiple MRs for the case of
       multi-homing. Assume that there is a mobile network with a single
       MR. The fake MR claims to be the second MR for multihoming the
       victim mobile network, and register to HA with another spoofed IP
       prefix. The fake MR advertises its spoofed IP prefix to the new
       VMNs that comes into play.
       Then the victim VMN gets the wrong IP address from the fake MR,
       and starts to communicate via the fake MR.

     - Corrupted routing information
       Attacker may send corrupted routing information to MR and cause
       network instability such as network congestion or looping. If the
       MR is in the visited domain, it will not respond to the unsolicited
       RA. But while the MR is in home domain, it still accepts the RA
       messages, and may get screwed up with wrong routing information.

3.2   Threats to Communication Paths
      - eavesdropping/replay of messages between MR and HA
         All the data packets between MR and HA have to go through the
         bi-directional tunnel. This tunnel should be secured by IPsec.
         But some of the routing information that may not go through
         this tunnel should be secured.

      - eavesdropping/replay of messages between MNN and CN
         The messages between MNN and CN are going through the
         bi-directional tunnel, but there is no protection against
         sniffing data between MR and MNN or between HA and CN. So
         security mechanisms should be applied on the part of the
         path uncovered.

      - location privacy
        Monitoring and analyzing the characteristics of data traffic
        along the communication paths reveals some information on routing
        and location privacy.


S. Jung et. al.            Expires April, 2004                  [Page 5]


Internet-Draft            Threat Analysis for NEMO          October 2003



4. Threats to Target Entities

The basic network entities in NEMO are MR, HA, FA, CN on the main network,
and LFN, LMN, and VMN in the mobile network. Any of these entities could
be the target for attack. We will investigate possible threats caused by
compromising the network entities like MR, HA, and FA. The compromise of
an entity means that attacker can access the entity, and change or modify
data inside the system. The following attacks are possible with the
compromise of each entity. The authentication mechanism for each entity
therefore should be applied.


   4.1 Misbehavior of MR
       MR is the most critical network component for the successful
       operations in NEMO, thserfore, the correct operation of MR SHOULD
       be assured. Most other routers have their own security functions
       which MAY not enough to protect MR. The following are the
       security threats which MAY be caused by misbehavior of MR. HA
       need to check whether MR works correct.

        - MR-HA spoofing
          MR-HA is the permanent address assigned statically or
          dynamically to the MR by HA. MR-HA should be used for
          identification of MR while it is in the visited domain.
          The compromised MR can register to FA with a spoofed MR-HA,
          and try to collect data destinated to the victim address.

        - MR-CoA spoofing
          MR-CoA is the Care-of-Address assigned to the egress interface
          of MR by AR. The compromised MR can send a BU message to HA
          with a spoofed CoA, and collect the data that were destinated
          to the victim AR.

        - Cache poisoning
          The cache data for routing table in MR can be corrupted to
          subvert routing path. The data packet could be redirected or
          looped causing network instability.

   4.2 Misbehavior of HA
        - sniffing of tunneled packet
          The IPsec transport mode should be used for securing the
          tunneled packets between MR and HA. With the compromise of
          the HA, the attacker can sniff the decrypted data packet
          in HA.

        - corruption of binding cache
          HA keeps managing the BU information on binding cache.
          With the corruption of binding information, the attacker
          can redirects packets to where he want to deliver them.

   4.3 Traffic Analysis
       The location of MR or MNN inside the subnet may be the privacy of
       the client, so the location information while network is in motion
       should be secured. Attacker can analyze the header information
       MR-CoA in the tunneled data packet and identify the location of
       the MR.
       Since all the data packets between MNN and CN are also tunneled
       using MR-CoA as a new source address, the location of the MNN can
       also be disclosed.

   4.4 Denial of Service
       Denial of Service attack is possible against MR and HA by flooding
       BU messages and bogus tunneled packets. The attack can be more
       effective with distributed fake MRs or HAs.



S. Jung et. al.            Expires April, 2004                  [Page 6]


Internet-Draft            Threat Analysis for NEMO          October 2003


5.      Threats specific to the NEMO basic support protocol

    5.1 Corruption of Binding Cache by inside attacker

        The network configuration vulnerable to this attack is as
        follows. A MR has the function of NAT server, and there is a
        malicious MNN inside the mobile network. The malicious
        MNN spoofs a BU message of the MR, and send it to the MR.


        Assumptions

        The following analysis assumes:
        1. The BU packet from MR is requird to be protected by ESP transport
           SA between MR and HA.
           For exmaple, SA: src=CoA and dst=HA -> ESP transport HMACMD5 3DES

        2. The packets from MMN are encapsulted by IP-in-IP tunnel or IPSec
           tunnel SA between MR and HA.
           For example, IP-in-IP: scr=MNP and dst=any ->
                        IP-in-IP tunnel, outer_src=CoA and outer_dst=HA

        3. We assume that IP-in-IP and IPSec tunnel SA are executed after
           NAT/NAPT. NAT after IPSec tunnel will violate the SA and NAPT
           doesn't have the port number to work with. The same thing to
           IP-in-IP.

        A list of all possible attacks and countermeasures without NAT:
          1. MMN spoofs the CoA of MR; MR will drop any packets received
             whose source IP address is CoA.
          2. MMN spoofs the CoA of nested MR; However, MMN can not forge
             the ESP authentication data. HA will drop it.



         |-----HA----|     |----------MR--------|  |---------MN----------|
         |           |     |                    |  |                     |
         |  |-----|  |     | |-----|    |-----| |  |     |--------|      |
         |  |IPSec|<===3===|-|IPSec|<=2=| NAT |-|<===1===|  MNN   |      |
         |  |-----|  |     | |-----|    |-----| |  |     |--------|      |
         |     |     |     |                    |  |                     |
         |-----|-----|     |--------------------|  |---------------------|
               4
               |
               V
        |---------------|
        | Binding Cache |
        |---------------|
        |1| MR-HA   CoA |
        |2| MR-HA   CoA |
        |    ......     |
        |---------------|


S. Jung et. al.            Expires April, 2004                  [Page 7]


Internet-Draft            Threat Analysis for NEMO          October 2003



        1. Malicious MNN makes the following packet and sends it to MR.

                   |------------------------------|
                   | source IP address = MNN      |
                   |------------------------------|
                   | destination IP address = HA  |
                   |------------------------------|
                   |            ......            |
                   |------------------------------|
                   | src port=any  |   dst port   |
                   |------------------------------|
                   |            ......            |
                   |------------------------------|
                   |    BU Options (MNP, CoA)     |
                   |------------------------------|

         2. Assume that NAPT is used...

                   |------------------------------|
                   | source IP address = CoA      |
                   |------------------------------|
                   | destination IP address = HA  |
                   |------------------------------|
                   |            ......            |
                   |------------------------------|
                   | src port=any* |   dst port   |
                   |------------------------------|
                   |            ......            |
                   |------------------------------|
                   |    BU Options (MNP, CoA)     |
                   |------------------------------|

        Since NATP changes the source IP address into one globally
        routable one, in this case, the only choice is CoA address of
        MR. If there are multiple globally routable IP addresses
        associated with MR and NAT is used, it may not cause problems
        as long as source IP address is not changed into CoA.

        3. If MR can't distinguish the NATed BU packets from those sent
           by itself (Assume that BU sent from MR itself uses CoA as
           the source IP address. It is a reasonable assumption since
           only ESP transport mode is used. ), MR will use ESP transport
           mode to process the NATed BU packets.

                   |------------------------------|
                   | source IP address = CoA      |
                   |------------------------------|
                   | destination IP address = HA  |
                   |------------------------------|
                   |             ESP              |
                   |------------------------------|
                   |            ......            |
                   |------------------------------|
                   | src port=any* |   dst port   |
                   |------------------------------|
                   |            ......            |
                   |------------------------------|
                   |    BU Options (MNP, CoA)     |
                   |------------------------------|


S. Jung et. al.            Expires April, 2004                  [Page 8]


Internet-Draft            Threat Analysis for NEMO          October 2003



        The solution to this attack is that MR will check the source port
        number in the BU packet with the NAPT mapping table where any used
        port number has an entry. If there is such entry, MR will know this
        packet is from MNN, thus MR will use IP-in-IP tunnel to encapsulate
        it. Otherwise MR will use ESP SA to process it.

        For the purpose of efficiency, it is better to resist the attack
        as early as possible. The list of other possible solutions:
        -  MR will check the type of packets from MMN. However, MR can't
           drop BU from MMN because MNN can be a nested MR.
        -  MR will check the type of packets from MMN and only allow BU
           transformed by ESP transport SA. However, MR can not verify such
           packets. Thus, attackers may still launch DoS attack to HA.
        -  MR may enforce the authentication in MN in order to make any
           attack accountable.


        4. HA will decapsulte and verify this incoming packet. If the
           verification is successful, HA believes that BU is from MR and
           updates the binding cache accordingly. Because HA can notice
           that it receives the BU from SA between CoA and itself but
           mobility option indicates a different CoA, HA will get confused.
           If HA accepts this BU, the binding cache will be polluted by
           attackers.

        The success of this attack depends on how the MR acts when it
        process the fake packet. The MR MAY just drop the packet because
        it has the same source address of itself, or process the packet
        using IPsec traport mode.

        We performed an experiment using Microsoft Window2000 as a NAT
        server configuring with IPsec transport mode, which shows that
        this threat is realistic. In the experiment, the fake packet from
        a node inside mobile network could go through the Window2000 NAT
        server (this could be a MR in NEMO case) to a machine in outside
        networks (this could be a HA in NEMO case) wrapped into the IPsec
        ESP encapsulation in transport mode.
        Since the current IPsec documents do not describe the details of
        specification for the case of NAT server configured with IPsec,
        the MR SHPULD take care of this potential vulnerability. For example,
        the MR SHOULD distinguish the data packet from itself or inside node.
        For MIP, this vulnerability doesn't exist, because there is no reason
        for a MN to forward a fake packet from the attacker using its own
        IPsec SA. Therfore, this attack is very specific to NEMO protocol.



S. Jung et. al.            Expires April, 2004                 [Page 9]


Internet-Draft            Threat Analysis for NEMO          October 2003



    5.2 Attack using HA as a stepping stone

        NEMO basic support draft suggests that the data packets from MMN
        SHOULD be encapsulted by IP-in-IP tunnel. However, HA may become
        the stepping stone to attackers. The following figure shows this
        threat. In the figure, malicious packets from MNN encapsulated
        in IP-in-IP tunnel can go through MR and HA to be deivered to
        the victim machine. The potential threats are IP spoofing, DoS
        attack etc.



               |-----|       |----|       |-----|
               |  HA |===2===| MR |===1===| MNN |
               |-----|       |----|       |-----|
                  |
                  3
                  |
               |------|
               |victim|
               |------|


        1. Src=spoofed IP address
           dst=victim
           data payload

        2. outer_src=CoA
           outer_dst=HA
           src=spoofed IP address
           dst=victim
           data payload

        3. src=spoofed IP address
           dst=victim
           data payload

        This threat MAY not only be specific to NEMO, but also to any
        routers configured with IP-in-IP tunnel without any associated
        security mechanisms. However, this threat could be more serious
        due to the heavy usage of IP-in-IP tunnel in NEMO.



    5.3 Attack to Location Privacy by Traffic Analysis

        In the basic NEMO configurations, all the traffic from mobile
        network are supposed to go through the bi-directional tunnel
        between MR and HA. The HA can collect all the packets in
        IP-in-IP tunne, decapsulates them, and forwards them to the CNs.


        |-----|         |----|   IP-in-IP tunnel  |----|         |----|
        | MNN |---------| MR | ================== | HA |---------| CN |
        |-----|    1    |----|          2         |----|    3    |----|


        The outside attacker can monitor the traffic in path 2 and 3.
        The time variations of traffic in a specific tunnel between a
        specific MR and HA may have a similar pattern to the time
        variation of traffic on a channel between HA and a specific CN.
        By the statistical analysis on the time interval of peak traffic,
        the attacker can find a correlation between incoming and outgoing
        traffic pattern of HA, and finally finds the same connection
        to extract the CoA information from the packet on path 2 and
        the HA of MN from packet on path 3. This means that the
        particular MN is located in the region of that particular CoA.
        This attack is not only specific to NEMO, but due to the
        mandatory use of bi-directional tunnel, this attack can be more
        serious in NEMO.


S. Jung et. al.            Expires April, 2004                 [Page 10]


Internet-Draft            Threat Analysis for NEMO          October 2003


6.      Security Requirements for NEMO

        The basic support protocol for NEMO is based on the MIPv6
        operations except the bi-directional tunnel operations between
        MR and HA. Therefore, most of the security requirements are
        already addressed in MIPv6 WG documents[4], so this draft describes
        the security requirements only against new threats in NEMO.
        The following security requirements SHOULD be addressed in NEMO
        basic and extended documents.

        6.1 MR SHOULD check the contents of the packet from MNN inside ,
            and assure that the packet does not include fake information
            in the critical messages such as BU, prefix discovery, or
            ICMP messages.
        6.2 The IP-in-IP encapsulated packet SHOULD be authenticated
            between MR and HA, and per-packet authentication at MR
            SHOULD be enforced.
        6.3 The amount of traffic from MNN through the IP-in-IP tunnel
            SHOULD be secured to protect the location privacy against
            traffic analysis. The amount of traffic through IP-in-IP
            tunnel MAY be secured using expanded field as in IPsec
            ESP[10].
        6.4 HA SHOULD make sure that the MR is working correctly.
            To check the right operation of MR, HA need to periodically
            send test messages, and get the responses from MNN or CN.
            A scheme similar to return routability MAY be used for
            this purposes.
        6.5 The threats to new messages related to RO for extended NEMO
            SHOULD be protected, but those threats will depends on what
            sort of RO mechanism is used. The right security mechanism
            for extended NEMO SHOULD be added later.



S. Jung et. al.            Expires April, 2004                 [Page 11]


Internet-Draft            Threat Analysis for NEMO          October 2003



References


   [1]   Ernst, T., et al, "Network Mobility Support Goals and
         Requirements",
         Internet Draft: draft-ietf-nemo-requirements-01.txt,
         Work In Progress, May  2003.

   [2]   Ernst, T. and H. Lach, "Network Mobility Support Terminology",
         Internet Draft: draft-ietf-nemo-terminology-00.txt, Work In
         Progress, May 2003.

   [3]   Wakikawa, R., et al, "Basic Network Mobility Support", Internet
         Draft: draft-wakikawa-nemo-basic-00.txt, Work In Progress,
         February 2003.

   [4]   Johnson, D. B., Perkins, C. E. and Arkko, J., "Mobility Support
         in IPv6",
         Internet Draft: draft-ietf-mobileip-ipv6-21.txt,
         Work In Progress, February 2003.

   [5]   Barbir, A. and et. Al, "Generic Threats to Routing Protocols",
         Internet Draft: draft-ietf-rpsec-routing-threats-01, April 2003.

   [6]   Kniveton, T. J., et al, "Mobile Router Tunneling Protocol",
         Internet Draft: draft-kniveton-mobrtr-03.txt, Work In Progress,
         November 2002.

   [7]   Petrescu, A., et al, "Issues in Designing Mobile IPv6 Network
         Mobility with the MR-HA Bidirectional Tunnel (MRHA)", Internet
         Draft: draft-petrescu-nemo-mrha-00.txt, Work In Progress,
         October 2002.


   [8]   Ng, C. W. and Tanaka, T., "Securing Nested Tunnels Optimization
         with Access Router Option", Internet Draft:
         draft-ng-nemo-access-router-option-00.txt, Work In Progress,
         October 2002.

   [9]   Arkko, J. et. al. ,Using IPsec to Protect Mobile IPv6 Signaling
         between Mobile Nodes and Home Agents,í˜
         Internet Draft: draft-ietf-mobileip-mipv6-ha-ipsec-04.txt,
         March 2003.

   [10]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
         (ESP)", RFC 2406, November 1998.

   [11]  Kent, S. and R. Atkinson, "Security Architecture for the
         Internet Protocol", RFC 2401, November 1998.

   [12]  Kent, S. and R. Atkinson, "IP Authentication Header",
         RFC 2402, November 1998.




S. Jung et. al.            Expires April, 2004                 [Page 12]


Internet-Draft            Threat Analysis for NEMO        September 2003



Authors' Addresses

   Souhwan Jung
   Soongsil University
   1-1, Sangdo-dong, Dongjak-ku
   Seoul 156-743
   KOREA

   Phone: +82-2-820-0714
   EMail: souhwanj@ssu.ac.kr


   Fan Zhao
   Department of Computer Science
   University of California, Davis
   One Shield Avenue
   Davis, CA 95616
   USA

   Phone: +1-530-752-3128
   EMail: fanzhao@ucdavis.edu

   Felix Wu
   Department of Computer Science
   University of California, Davis
   One Shield Avenue
   Davis, CA 95616
   USA

   Phone: +1-530-754-7070
   EMail: wu@cs.ucdavis.edu



   HyunGon Kim
   Network Security Department
   ETRI
   161 Kajong-Dong, Yusong-Gu
   Taejon 305-600
   KOREA

   Phone: +82-42-860-5428
   Email: hyungon@etri.re.kr



   SungWon Sohn
   Network Security Department
   ETRI
   161 Kajong-Dong, Yusong-Gu
   Taejon 305-600
   KOREA

   Phone: +82-42-860-5072
   Email: swsohn@etri.re.kr


S. Jung et. al.            Expires April, 2004                 [Page 13]


Internet-Draft            Threat Analysis for NEMO        September 2003




Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances
   of licenses to be made available, or the result of an attempt made
   to obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification
   can be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


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.


S. Jung et. al.            Expires April, 2004                 [Page 14]