Subject: [nemo] commens on draft-jung-nemo-threat-analysis-01.txt

From: Vijay Devarapalli <[email-masked]>
Date: Sat, 08 Nov 2003 20:37:12 -0800

hi,

I just read through the threat analysis document and sorry to say
I was disappointed with the document.

many of the threats are not Nemo specific. for example it talks
about a compromised Access Router, an attacker injecting false
Router Advertisement information in the home link, a compromised
Home Agent, etc.... all these threats should be removed from the
document.

some of the threats are also not valid.

specific comments follow.

Vijay

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

remove this threat. it is not really Nemo specific. if the access
router is compromised, there isnt much you can do about it. the
access router could deny network connection to mobile nodes, fixed
nodes with wireless access, etc.

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

if an attacker gets into the home domain and sends "corrupted routing
information", you have a lot more serious problem at hand. remove this.

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

this didnt make a lot of sense.

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

again, nothing Nemo specific. this is applicable to any two nodes
(whether mobile or not). the best solution for this is to have
end-to-end security between MNN and CN.

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

not Nemo specific. please remove.

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

this is an IPv4 model. in Nemo, MR deals directly with the HA. it does
no registration with FA/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.

which "Cache"?

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

remove 4.2. I dont expect the HA to misbehave. there isnt much the
Nemo protocol basic/extended can do if the HA misbehaves.

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

Binding Updates are rate-limited. this maybe not be possible.

>     5.1 Corruption of Binding Cache by inside attacker

the entire section 5.1 needs to be re-written without assuming
NAT or NAT-PT on the mobile router.

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

how is the attacker on both path 2 and 3?

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

this is a really bad idea. the only thing the MR should be doing is
ingress filtering and access control check. it *should* not look into
the packet contents. and what if the MNN is using end-to-end ESP
encryption? the MR cant see the packet even if it wants to.

>         6.2 The IP-in-IP encapsulated packet SHOULD be authenticated 
>             between MR and HA, and per-packet authentication at MR 
>             SHOULD be enforced. 

authenticated? why? the HA already makes sure that the CoA (on the
outer header) is authorized to tunnel packets for MNN's address
(in the inner header). you dont need per-packet authentication.

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

when did location privacy become a strong requirement? if the MNN
is concerned about this, it should be using RFC 3041 addresses.

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 05 Jan 1980 16:56:18 +0100

Vijay Devarapalli wrote:
> hi,
> 
> I just read through the threat analysis document and sorry to say I 
> was disappointed with the document.
> 
> many of the threats are not Nemo specific.

Exactly, that is my reading too.

And since the agenda item describing this presentation invites to think
how to proceed with this WG item, I'd suggest to start with the Security
Considerations of draft-ietf-nemo-basic-support-01.txt and with section
5 of draft-petrescu-nemo-mrha-03.txt.

Starting point should be acknowledging that the only NEMO-specific
security risks are related to interactions between MR and HA.

Then the IPsec tool protecting this should be described in more detail,
more specifically that it protects against eavesdropping between the
two, and masquerading of an attacker between the two.

Then describe what that IPsec tool does _not_ protect against.

Then describe in detail the checks suggested by the basic support, like
the ingress filtering of draft-ietf-nemo-basic.

Then describe the threats appearing when MR and HA belong to different
admin domains.

Then describe the problem of the built-in authentication of dynamic
routing protocols not covering the relations between prefix being
advertised and having the right to advertise that prefix; the prefix
table of basic support might help with this; an alternative way of
dealing with this being  draft-ietf-ospf-ospfv3-auth-01.txt, in case of
OSPF.

So, that's my suggestion of how to proceed with this WG item.

[...]

> encryption? the MR cant see the packet even if it wants to.

I agree with the all the points you had down to the ellipsis.

The "ingress filtering" aspect you say seems also reasonable.

But, HA looking _inside_ the packet contents (beyond the headers
explicitely addressed to itself, and _if_ ESP is not present) might help
with solving the "cross-over" tunnels problem (see section B.6 of
draft-petrescu-nemo-mrha-03.txt for a description of this problem).

>> 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].
> 
> 
> when did location privacy become a strong requirement? if the MNN is
>  concerned about this, it should be using RFC 3041 addresses.

Yes I agree with this too.

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 05 Jan 1980 16:56:18 +0100

[...]

Alex
GBU

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 11 Nov 2003 04:40:52 +0900

Hi,

I definitely agree that the slot at the meeting should discuss about
threats specific to NEMO Basic Support.

However, while Vijay mentioned that some threats in
dtraft-jung-nemo-threat-analysis-01.txt are not specific to NEMO, I
still think it's useful to keep those in mind and the best way is a
written document. The non-NEMO issues may not be solved in NEMO WG, but
they need to be brought to the attention of the relevant people. We
should then use that kind of information as an input to the WG that is
in the best position to solve it.

Alex, what you wrote below is very interesting. Why don't you write a
short I-D and get help from other people ?  It's good to have a starting
document on the table. 

Thierry.

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 11 Nov 2003 04:40:52 +0900

Hi,

Thierry.

---

From: "Souhwan Jung" <[email-masked]>
Date: Tue, 11 Nov 2003 06:25:59 +0900

Hi, Vijay

First, I appreciate your comments on my draft, though they are pretty much against to our approach.

The major threats we have discovered so far, which are very specific to NEMO basic support protocol, are the threats from Section 5.1 and 5.2 in the draft. The other stuff may be kind of "generic" threats to any hosts or routers. But the reason to include those "generic" threats in the draft is to investigate all potential threats that are relevant to NEMO protocol, and to find threats more specific to NEMO protocol.

If you focus on the NEMO basic protocol only, then the scope is pretty narrow, and I am afraid you may miss some of the potential threats that should be considered in the near future, e.g. threats for extended NEMO protocols.

Anyway, you didn't tell much about the threats in Section 5.1 and 5.2 that could be very critical, we believe. Just doing ingress filtering in MR can not protect the attacks. Can you give some comments on those threats?

Thanks.

Souhwan

---

From: "Souhwan Jung" <[email-masked]>
Date: Tue, 11 Nov 2003 06:25:59 +0900

Hi, Vijay

Thanks.

Souhwan

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 11 Nov 2003 09:19:23 -0800

> Anyway, you didn't tell much about the threats in Section 5.1 and 5.2 that could be very critical, we believe. Just doing ingress filtering in MR can not protect the attacks. Can you give some comm…

I will. once you re-write the section eliminating NATs and NAT-PTs.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 11 Nov 2003 09:19:23 -0800

Vijay

---

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 11 Nov 2003 12:32:28 -0800

William D Ivancic wrote:

> So, the question I have is should the treat analysis only  apply to 
> those threats that are:
>
> 1) mobile network specific (ipv4 and ipv6)?   If so, where does this 
> document belong ( ipv4  or nemo ?)
>
> 2) nemo mobile network ipv6 specific?
>
> 3) nemo basic support specific?
>
> 4) should the IPv4 treats be sent to ipv4 WG? 

The document should demonstrate and document threats that are NEMO Basic 
Support-specific. Any work categorizing IPv4 threats belongs far outside 
this document, since we have not even had any work done on IPv4 NEMO 
networks yet.

As an aside, a few parties had made verbal commitments to work on 
IPv4-based Mobile Router solutions within the NEMO group. No one has 
submitted anything yet.

TJ

---

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 11 Nov 2003 12:32:28 -0800

TJ

---

From: William D Ivancic <[email-masked]>
Date: Tue, 11 Nov 2003 11:58:54 -0500

Vijay and Souhwanj,

When I read this document I had some of the thoughts that Vijay had.  In 
particular, much of the treats are not "nemo" specific if one assumes 
"nemo" means ipv6 basic support.   Many references are for IPv4 
issues.  However, these are mobile networks.     There are also some issues 
that are not necessarily mobile network specific; however, they may be more 
easily exploited in a mobile network.

So, the question I have is should the treat analysis only  apply to those 
threats that are:

My initial impression is to  propose 3 and 4.   If we don't bound the 
problem, it will be difficult to develop a complete document that is useful 
for development and deployment of basic nemo.    If we recharter to address 
RO later, than a revised or additional treat analysis document would be 
warranted.

Please note, I was not disappointed with the treat document, but though it 
may be to broad which may limit its usefulness rather than improve its 
usefulness.

Will

At 08:37 PM 11/8/2003 -0800, Vijay Devarapalli wrote:
>>        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.
>
>>        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.
>
>>          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.
>
>>          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.
>
>>         Monitoring and analyzing the characteristics of data 
>> traffic         along the communication paths reveals some information 
>> on routing         and location privacy.
>
>>           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.
>
>>         - 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.
>
>which "Cache"?
>
>
>>    4.2 Misbehavior of HA
>>           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.
>>           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.
>
>>        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.
>
>>         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.
>>
>>
>>         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].
>

---

From: William D Ivancic <[email-masked]>
Date: Tue, 11 Nov 2003 11:58:54 -0500

Vijay and Souhwanj,

Will

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 11 Nov 2003 21:50:52 +0100

Thierry Ernst wrote:
> written document.

Right.

>  short I-D and get help from other people ?  It's good to have a 
> starting document on the table.

Here's a document you ask.  I'm going to submit it formatted after the
IETF meeting.  So, I would like to ask help from other people to help
with threat analysis.  This document is really in its inceptive phase, I
just tried to make it very specific to NEMO.  Please remark on the
presented threats, or suggest new ones.  Or maybe you find the structure
is not right, maybe one can change that too.

Disclaimer to Souhwan: this is in no way competition, just my way of
seeing the threats, thanks for understanding.

Alex
GBU

Internet Draft                                              A. Petrescu
Document: draft-petrescu-nemo-threats-00.txt                   Motorola
Expires: May 2004                                         November 2003

       Threats for Basic Network Mobility Support (NEMO threats)
		 <draft-petrescu-nemo-threats-00.txt>

Status of this Nemo

    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.

Abstract

    This document describes security threats related to the network
    mobility base protocol (NEMO).  It does not present threats of
    Mobile IPv6.  The communication between MR and HA, as well as the
    forwarding information at HA and nested mobility configurations are
    considered to be the main sensitive points of the protocol.
    Existing tools of Mobile IPv6 protection between MN and HA (IPsec),
    dynamic routing protocol authentication, NEMO prefix table and
    ingress filtering checks at HA are presented as potential help
    defending against threats.

Table of Contents

    Status of this Memo................................................i
    Abstract...........................................................i
    Conventions Used in this Document..................................1
    1. Introduction and Overview.......................................1
    X. Interactions between MR and HA..................................
    X. Interactions between several MR's of same HA....................
    X. MR and HA in different administrative domains...................
    X. Forwarding Information Updates at HA............................
    X. Nested Mobility.................................................
    X. Other Threats...................................................
    Acknowledgements...................................................
    References.........................................................
    Changes............................................................
    Intellectual Property Rights Considerations........................
    Authors' Addresses.................................................
    Copyright Notice...................................................

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 [].

X. Introduction and Overview

    The Network Mobility base protocol [] describes means for a Mobile
    Router using Mobile IPv6 [] to offer continuous connectivity for a
    set of hosts and routers inside a moving network, to the Internet.
    A moving network has a relatively stable internal IP structure and
    will usually not transit traffic.

    A Mobile Router implements most functionalities of a Mobile IPv6
    Mobile Host with the notable additions of the BU R-bit management
    and NEMO-specific modes (implicit, explicit network , explicit
    prefix len).  A NEMO Home Agent implements most functionalities of
    a Mobile IPv6 HA with the notable additions of BU R-bit management,
    the three previously mentioned modes and, additionally,
    interactions with its forwarding information (routing table)
    management.

    A new mobility behaviour introduced by NEMO with respect to Mobile
    IPv6 mobility is the "nested" configuration, in which two moving
    networks served by different Mobile Routers (each with its own Home
    Agent) attach one under the other.  A simpler case of nested
    mobility appears when one Mobile Host visits a moving network (MH
    and MR having different Home Agents).

    While Route Optimization is currently an integral part of the
    Mobile IPv6 specification for Mobile Hosts, it is not a part of the
    behaviour of a Mobile Router or of that of a NEMO Home Agent.

    Thus, this document describes security threats that pertain to: (1)
    interactions between MR and its HA, (2) interactions between
    several MR's served by same HA, (3) interactions between MR and HA
    when they belong to different administrative domain, (4) threats
    relating to forwarding information updates at HA and, finally, (5)
    threats related to nested mobility.  For the described threats,
    suggestions are given for possible tools.

    This document does not describe threats relating to Route
    Optimization for moving networks, nor threats relating to Mobile
    IPv6 for hosts, nor other mobility-related threats whose solutions
    are described by PANA, EAP, AAA and SEND Working Groups.  For
    threats relating to Mobile IPv6 for Mobile Hosts, reader is kindly
    referred to [], [].  For threats relating to access granting and
    control, or threats of IPv6 behaviour on same-link, please see the
    above mentioned Working Groups documents.

    A similar document attempting to describe threats in the NEMO
    context is [].

    The current network mobility base specification specifies that all
    signaling messages between the Mobile Router and the Home Agent
    MUST be authenticated by IPsec.  The use of IPsec to protect Mobile
    IPv6 signaling messages is described in detail in the HA-MN IPsec
    specification.  Using AH and/or ESP between MR and HA is of
    paramount importance in order to protect against a wide range of
    threats.  However, other means of protecting communication between
    MR and HA might be useful in certain cases.  A good overview of
    authentication mechanisms in the Internet can be found in [].

X. Interactions between MR and HA

    Threat on switching between modes: MR sends BU in implicit mode to
    HA, HA replies back positively, using MNP from external means (not
    from BU).  During this time, the attacker gained knowledge of the
    MR's Home Addres, sends BU to HA in explicit mode for the same Home
    Address but a MNP specified in the BU, different than what HA
    already has.  HA replies back positively to MR and switches to
    explicit mode and a different MNP.  Threat is DoS: tunneling data
    between MR and HA stops, MR is in implicit mode while HA in
    explicit mode.  IPsec protects against this behaviour in that HA
    will drop the attacker's BU because can't decrypt the received ESP
    (attacker does not have the keys shared between MR and HA).

    Threat on location privacy: Location privacy is the desire of a
    Mobile Host to not reveal, or hide, its current association Care-of
    Address (its location) - Home Address (its permanent identifier)
    from an attacker listening on the path between MH and HA.  It is
    not a desire to hide only one address, but the association.  It is
    a problem in that attacker A may have visibility over the Home
    Address and the Care-of Address of a Binding Update or Binding
    Acknowledgement between MR and HA even if ESP is used (ESP does not
    cover the base IPv6 header of the BU whose src field contains the
    CoA, neither the DO1 header containing the Home Address).  It is
    also a temporality problem for MH in that an attacker on the same
    visited link as MH may intercept the Binding Request Refresh
    messages from HA towards MH after the MH has left that visited
    link, thus deducing that that MH was "located" on that link at a
    certain point in time.  This is not a location privacy problem for
    LFN behind MR, because all traffic from LFN is encapsulated inside
    the ESP tunnel between MR and HA; moreover, since LFN only has a
    Home Address (no CoA) there is actually no association to hide from
    wily attackers.

    Masquerading for Denial-of-Service: when attacker needs to send an
    unreasonably large amount of IP packets to a target without risk of
    his current address being identified, it could do so by two means.
    First, it would set the src address of the packets to another
    address, at random (thus "spoofing" a legitimate address, or
    "masquerading" as that address).  However, the first-hop router
    might forbid forwarding packets whose source address are not
    topologically correct at that particular router (ingress
    filtering).  Second, if ingress filtering at the access router is
    in place, the MH might first encapsulate towards HA, thus tricking
    the access router; HA decapsulates and "bombs" the actual target by
    using MH's Home Address as source address.  However, the ingress
    filtering technique is used at the HA as well; Mobile IPv6 requires
    HA of MH to only forward those packets from MH if the src address
    of the outer header to match a Care-of Address entry in the BC and
    the src address in the inner header to match the home address field
    of the same entry.  The NEMO spec goes further in the ingress
    filtering detail by requiring the Home Address to match a Mobile
    Network Prefix owned by the Mobile Router.

    Confidentiality threat: the payload of all IPv6 packets between LFN
    and CN is encapsulated inside the bidirectional tunnel between MR
    and HA.  An attacker placed in the path between LFN and CN might
    have visibility over all this traffic.  But, if the encapsulating
    tunnel uses ESP tunnel mode, payload is encrypted, thus hidden.  In
    this respect, MR acts exactly as MH.

    Authentication threat: the same attacker might modify the payload
    of data between LFN and CN.  But if AH is used, payload is
    authenticated, thus impossible to modify without LFN and CN
    noticing it.  In this respect too, MR acts as MH.

    Using AH and/or ESP between MR and HA is of paramount importance in
    order to protect against a wide range of threats.

X. Interactions between several MR's of same HA

    DoS threat on peer MR: consider a legitimate MR with prefix MNP and
    an attacker MR with a different prefix, both served by the same HA.
    Each MR shares a set of keys with HA, and SA's linking the
    respective Home Addresses and the HA address.  The attacker MR
    could instruct the HA to to add MNP in the binding cache, relating
    it to its own Home Address (instead of to the legitimate MR's Home
    Address), thus effectively denying service to the legitimate MR and
    redirecting the entire traffic to MNP towards the attacker MR.
    Even if HA uses IPsec, it could not protect against attacker MR's
    claiming the legitimate MR's MNP.  However, the prefix table
    specified by NEMO associates a MR's Home Address to the MNP that it
    owns, thus constituting a means for MR to check against attacker MR
    claiming a prefix it does not actually own.

    This particular threat applies equally well to Mobile IPv6 for
    hosts: an attacker MH may demand the HA (with which it holds an SA)
    to insert a BC entry of its CoA towards the Home Address of a
    legitimate MH, even if both MH's have respective SA's with that HA.
    If the threat is solved by Mobile IPv6 for hosts, the method
    specified by Mobile IPv6 should naturally be reused by NEMO base
    support too.

X. MR and HA in different administrative domains

    [This is rather tough for me to understand.]

    It is possible that HA and MR belong to a same administrative
    domain.  It is also possible that HA and MR belong to different
    administrative domains.  In the latter case, there might be
    important security risks, and routing instability risks.  For one,
    if MR advertises a prefix towards HA, HA accepts it and propagates
    it upper stream then an important instability in the Internet at
    large might appear (because MR's prefix is administratively
    assigned somewhere else, in MR's administrative domain).  Second,
    if HA advertises prefixes towards the mobile network, then routing
    instability in the mobile network might appear.  Because of those
    two reasons, it might be recommended for MR and HA to forbid the
    exchange of any routing information (other than Mobile IPv6) when
    MR and HA belong to different administrative domains.

X. Forwarding Information Updates at HA

    How current routing protocols routers authentify each other, how
    they lack a concept of "prefix ownership" (see the "address
    ownership problem" []).  How the prefix table might help with this.
    How routing protocols authentication could be interpreted to solve
    the potential "prefix ownership" problem.

    The current base NEMO specification reads:

       When the Mobile Router is running a dynamic routing protocol as
       described in section 7, it injects routing update messages into
       the Home Link.  The Home Agent MUST verify that the Mobile
       Router is allowed to send routing updates before processing the
       messages and propagating the routing information.

X. Nested Mobility

    DoS threat on TLMR due to too many nested networks: several moving
    networks may attach one under the other forming a nested
    aggregation of moving networks.  Naturally, the top-level MR will
    forward traffic of all moving networks attached under it.  When the
    number of levels is large, this may become an overload on the
    initial expectations of the capabilities of this Mobile Router,
    thus becoming a DoS attack.  It is possible that a MR has a desire
    to limit the number of moving networks that nest under it; it could
    use the Tunnel Encapsulation option by setting a limit on the
    number of levels of mobile networks below it.

X. Other Threats

    Other threats might exist.

X. Acknowledgements

   Threats related to network mobility have been discussed on the NEMO
   list, whose members are acknowledged here.  Particularly relevant
   threats woven in the threading of this document have been described
   by (in random order): V. Devarapalli, E. Nordmark, T. Ernst,
   S. Jung.  Authentication mechanisms of routing protocols mentioned
   by S. M. Corson. More, etc.

X. References

    []  Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

    [] Devarapalli, V., Wakikawa, R., Petrescu, A. and Thubert, P.,
         "Nemo Basic Support Protocol" (work in progress).  Internet
         Draft, IETF. draft-ietf-nemo-basic-support-01.txt.  September
         2003.

    [] Johnson, D., Perkins, C. and Arkko, J., "Mobility Support in
         IPv6" (work in progress).  Internet Draft,
         IETF. draft-ietf-mobileip-ipv6-24.txt.  June 2003.

    [] Arkko, J., Devarapalli, V. and Dupont, F., "Using IPsec to
         Protect Mobile IPv6 Signaling between Mobile Nodes and Home
         Agents" (work in progress).  Internet Draft, IETF.
         draft-ietf-mobileip-mipv6-ha-ipsec-06.txt. June 2003.

    [] Nikander, P., Harkins, D., Patil, B., Roberts, P., Nordmark,
         E. and Makin, A., "Threat Models introduced by Mobile IPv6 and
         Requirements for Security in Mobile IPv6" (work in progress).
         Internet Draft, IETF.
         draft-team-mobileip-mipv6-sec-reqts-00.txt.  December 2001.

    [] Jung, S., Zhao, F., Wu, F., Kim, H., Sohn, S., "Threat Analysis
         for NEMO" (work in progress).  Internet Draft, IETF.
         draft-jung-nemo-threat-analysis-01.txt.  October 2003.

    [] Rescorla, E., "A Survey of Authentication Mechanisms" (work in
         progress).  Internet Draft, IETF.
         draft-rescorla-auth-mech-01.txt.  March 2003.

    [] Nikander, P., "An Address Ownership Problem in IPv6" (work in
         progress).  Internet Draft, IETF.
         draft-nikander-ipng-address-ownership-00.txt.  February 2001.

Changes

    November 2002:  revision 00 submitted.

Author's Addresses

   Alexandru Petrescu
   Motorola Labs
   Parc les Algorithmes St Aubin
   Gif-sur-Yvette 91193
   France
   Phone:  +33 1 69354827
   [email-masked]

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

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.

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 11 Nov 2003 21:50:52 +0100

Right.

Alex
GBU

Status of this Nemo

Abstract

Table of Contents

X. Nested Mobility

X. Other Threats

X. Acknowledgements

X. References

Changes

Author's Addresses

   Alexandru Petrescu
   Motorola Labs

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 11 Nov 2003 22:09:19 +0100

T.J. Kniveton wrote:
> The document should demonstrate and document threats that are NEMO 
> Basic Support-specific. Any work categorizing IPv4 threats belongs 
> far outside this document, since we have not even had any work done 
> on IPv4 NEMO networks yet.
> 

Commitments to develop an IPv4-based Mobile Router solutions have been
made and at least one has been fulfilled.

Submitting a description to the IETF is subject to this WG's interest in
having one and subject to committers' needs to satisfy other urgent
emergencies.

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 11 Nov 2003 22:09:19 +0100

Alex
GBU