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.