Re: [nemo] comments on new threats

[Thierry Ernst <[e-mail]>]

Dear Souhwan,


> The new threat analysis draft is available at the following location.
> 
> http://www.ietf.org/internet-drafts/draft-jung-nemo-threat-analysis-01.txt
> 
> Some new threats specific to NEMO basic support protocol were included at the draft. Any comments on them will be greatly appreciated.

Here are some comments to your draft.


General Comments:
~~~~~~~~~~~~~~~~~

- I think it would be useful to explain what is new in the -01 version of
your draft, so that people who already read version -00 can rapidly
check what is important.

- Does your new version catch the conversion we had on security at IETF Wien
?

- I think the nested case and the multihoming cases require a
more-in-depth analysis. It could an interesting future contribution of
your work.

- could you make the disctinction between potential threat, the ones
peculiar to NEMO Basic Support, the one that generally apply to the
concept of network mobility (taken in general, with no specific protocol
in mind (i.e. without NEMO Basic Support, MIPv6, etc)



1. Motivations
~~~~~~~~~~~~~~
   It would be useful to say there that the protocol to manage the
mobility of the mobile network, i.e. network mobility support, is NEMO
Basic Support, itself based on Mobile IPv6. Then you can say it
introduces a new entity, the MR.

   You don't state explicitly if your draft address vulnerabilities
specific to NEMO Basic Support, or network mobility in general, as a
concept. When you speak about the general concept, you should also deal
with the authorization for the sending node to fill up the BU with
information that can be proven (e.g. the prefix actually belongs to the
MR). 

Section 2
~~~~~~~~~

You use the acronym "FA". You could get rid of it, there are no FA in
NEMO. You probably mean the access router the MR is connected to, so
would better replace FA with AR.

Section 3.1
~~~~~~~~~~~

Same remark, no FA. In addition, if you meant AR, you should clarify
which signaling is under threat.  RAs ? Is there any issue peculiar to
NEMO right here ? 

Section 4.1
~~~~~~~~~~~~
   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-HA does not registered with the AR. MR's egress iface gets a CoA
     on AR's link, that's all.


4.3 Traffic Analysis
~~~~~~~~~~~~~~~~~~~~

Between MR and HA: Here, you are assuming the attacker is somewhere
between the MR and HA.

Between MR and MNN: you are assuming some sort of Route Optimization
which doesn't yet exist. Of course this is a problem RO will have to
face, but I would suggest to emphasize your assumptions. If that is the
case you should clarify that section 3 is a conceptual analysis and that
it does focus on NEMO Basic Support.

5.Threats specific to the NEMO basic support protocol
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please give a ref to the appropriate draft.


5.3 Attack to Location Privacy by Traffic Analysis
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Where do you assume the attacker is located in order to monitor both
path 2 and 3 ? 

Besides this, packets on path 2 (MR<->HA) will have all have same
<src/dst>; i.e. one packet may actually be sent by MNN1, and the next
one by MNN2, so how can you conclude on path <HA,CN> based on packet
interleaving ?

6.4
~~~
I'm curious how this could be done. But if such a solution exists, it
would give the HA the right to check what are the MNNs behind the MR, so
it turns to be  a privacy concern.

6.5 
~~~
The important point is what are the potential threats. Privacy is one of
them, so any solution should make sure that MNNs can keep their location
at least as secrete has if there were located in a fixed network.


Reference
~~~~~~~~~
- you missed to list NEMO Basic Support.

- on the other hand, you cite 2 expired drafts: this is missleading for
  new reader. I think you should remove.


 [3]   Wakikawa, R., et al, "Basic Network Mobility Support", Internet
         Draft: draft-wakikawa-nemo-basic-00.txt, Work In Progress,
         February 2003.
 [6]   Kniveton, T. J., et al, "Mobile Router Tunneling Protocol",
         Internet Draft: draft-kniveton-mobrtr-03.txt, Work In Progress,
         November 2002.

Thierry.