Subject: RE: [nemo] RE: RO between MR and CN

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 15 Oct 2004 09:15:01 +0200

Hi Carlos:

I need to give you my review on MIRON.

Note that your text is being unfair with RRH about the security issues. Security is debated in the draft, if you care to read that part. There have been a number of drafts that tried to propose more secure solutions based on misunderstanding of what the threats might be. They all died. Then there was Fan's very good study, (Fan, we need the update), but still, most of the issues were moot.

The point is that to date, there is no specific attack against RRH that was identified to make any good sense, compared to, say, scramble the radio wave or anything else a MITM might do. You understand that propagating ideas like 'there are security issues' without being specific is prejudicial...  For instance, you might want to take a specific attack and show how MIRON handles it better or something. 

Pascal

> -----Original Message-----
> From: Carlos Jesús Bernardos Cano [mailto:[email-masked]]
> Sent: jeudi 14 octobre 2004 12:08
> To: Masafumi Watari
> Cc: Pascal Thubert (pthubert); [email-masked]; María Calderón
> Subject: Re: [nemo] RE: RO between MR and CN
> 
> Hi Pascal, Masafumi,
> 
> El mié, 13-10-2004 a las 19:08, Masafumi Watari escribió:
> > Hi,
> >
> > On Wed, 13 Oct 2004 13:34:06 +0200,
> > "Pascal Thubert (pthubert)" <[email-masked]> wrote:
> >
> > > Hi Tania
> > >
> > > I was thinking things like of snooping. MR might intercept all packets to LFN, recognize
> a HoT and keep it. I remember discussing that with Alex long ago... Anyway, we try to say
> "don't take that path" as opposed to describe a solution in details.
> >
> > I don't think its possible to provide RO while keeping the RR function
> > of MIPv6 untouched.  It would probably require modification of the
> > packet at MR to use the HoA opt and the routing header for every
> > packet, if we want to keep the MIPv6 spec as is.
> 
> 	Yes, one possible solution is the MR performing all the RR and RO
> signalling on behalf of the LFNs of the NEMO, in order to provide RO for
> LFNs that are communicating to CNs outside the NEMO. This is actually
> the solution we have proposed in MIRON (see my previous e-mail if you
> want a pointer to it), so the MR, as you said, has to process the
> packets sent/received by a LFN in order to insert HoA DO/remove RH. I
> agree that it could have some performance concerns if the process is
> performed to every LFN-CN "flow", but as we have already discussed in a
> previous thread, some mechanism should be used to perform the RO in a
> reasonable way.
> 
> >
> > > It seems preferable, for instance, to establish a MR-CR tunnel and exchange fine grained
> routes for MNPs over the tunnel (route projection).
> >
> > I think I agree on this.
> 
> 	This is, IMHO, a different approach, in which the RO requires some
> support from the routing infrastructure, and that present some
> advantages. But, OTOH, solutions based on MR-CN RO are also interesting
> IMHO, as an approach that does not require support in the routing
> infrastructure and puts the RO support functionality only in the edges,
> i.e. the CN and the MR (if the transparency to the MNNs is required, the
> MR is the other edge in which RO mechanisms can be added).
> 
> 	What do you think?
> 
> 	Kind Regards,
> 
> 	Carlos J.
> >
> > Masafumi Watari
> >
> > > Pascal
> > >
> > > > -----Original Message-----
> > > > From: Tânia Pinto Calçada [mailto:[email-masked]]
> > > > Sent: mercredi 13 octobre 2004 13:16
> > > > To: [email-masked]
> > > > Cc: Pascal Thubert (pthubert)
> > > > Subject: RO between MR and CN
> > > >
> > > > Hello,
> > > >
> > > >
> > > >
> > > > I am interested in route optimization between the MR and the CN. I read the taxonomy
> draft
> > > > (draft-thubert-nemo-ro-taxonomy-02.txt), and several other documents related to RO:
> > > >
> > > > draft-jeong-nemo-ro-ndproxy-02.txt
> > > >
> > > > draft-leekj-nemo-ro-pd-02.txt
> > > >
> > > > draft-na-nemo-gen-ro-model-00.txt
> > > >
> > > > draft-na-nemo-path-control-header-00.txt
> > > >
> > > > draft-wakikawa-nemo-orc-00.txt
> > > >
> > > > ROProblem.txt
> > > >
> > > >
> > > >
> > > > I also read some threads of the NEMO mailing list http://www1.ietf.org/mail-
> > > > archive/web/nemo/current/index.html <http://www1.ietf.org/mail-
> > > > archive/web/nemo/current/index.html> , however I am still looking for a document that
> > > > describes a solution for the RO between the MR and the CN.
> > > >
> > > >
> > > >
> > > > The taxonomy draft says at section 2:
> > > >
> > > > "A major issue with this form of optimization is that the end-to-end
> > > >
> > > >    principle of the MIPv6 Reverse Routability (RR) test is broken.  The
> > > >
> > > >    RR test is meant to ensure the care-of address (CoA) and the home
> > > >
> > > >    address (HoA) are collocated. With a mobile network, when the MR
> > > >
> > > >    performs RO on behalf of the MNNs, the CoA in BU will be the MR's
> > > >
> > > >    CoA.  Thus, a MNN is reachable via the CoA, but not at the CoA.
> > > >
> > > >
> > > >
> > > >    Some tricks may be performed on the fly by the MRs but it seems that
> > > >
> > > >    a clean MR-to-CN optimization for Nemo will impact the CN function."
> > > >
> > > >
> > > >
> > > > Can somebody point the "tricks" that may be performed, or indicate a document that
> explores
> > > > this subject?
> > > >
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Tania Calcada
> > >
> > >
> > >
> --
> Carlos Jesús Bernardos Cano - http://www.it.uc3m.es/cjbc/
> GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 18 Oct 2004 19:21:36 +0200

Hi Pascal,

sorry for the delay, but as you may notice, the 18th has arrived :-)

As a co-author of the paper, let me give you p.o.v. of this issue.

El 15/10/2004, a las 9:15, Pascal Thubert (pthubert) escribió:

> Note that your text is being unfair with RRH about the security 
> issues. Security is debated in the draft, if you care to read that 
> part.

The content of the paper is the result of the analysis of the different 
proposals. Yes, we have read the RRH draft and its security 
considerations section. In particular, we have read the part that 
states:

   "This section is not complete; further work is needed to analyze and
    solve the security problems of record and source route."

Pay particular attention to the "solve" part.

This seems perfectly coherent with the comment presented in the paper 
stating that:

"It  has been identified that this approach [RRH] has security 
concerns."

Note that we only say concerns while in the draft it is stated 
"problems"

> There have been a number of drafts that tried to propose more secure 
> solutions based on misunderstanding of what the threats might be. They 
> all died. Then there was Fan's very good study, (Fan, we need the 
> update), but still, most of the issues were moot.
>
> The point is that to date, there is no specific attack against RRH 
> that was identified to make any good sense, compared to, say, scramble 
> the radio wave or anything else a MITM might do. You understand that 
> propagating ideas like 'there are security issues' without being 
> specific is prejudicial...

IMHO the paper propagates less this kind of ideas that the draft 
itself. As i mentioned, it is the draft that states that the RRH has 
"security problems" that need to be solved.

I guess that if you do not want to propagate this type of ideas, i 
would suggest you to remove this type of statements from the draft.

>  For instance, you might want to take a specific attack and show how 
> MIRON handles it better or something.
>

As you may notice, the MIRON paper is not about RRH security but about 
the MIRON proposal (moreover is not even about MIRON security), and 
considering the length restrictions on a paper, i guess that it isn't 
possible to include examples about all the statements provided.

Regards, marcelo

PS: I would like to apologize to the list about this mail, since it is 
clearly out of scope for the list. I won't sent any other mails about 
this specific issue. OTOH, i will be sending a constructive mail 
containing some security analysis about RRH, hoping to contribute with 
that effort

>>>>> Can somebody point the "tricks" that may be performed, or indicate 
------------------------------------------
Please note that my former email address
[email-masked] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 18 Oct 2004 19:52:25 +0200

Hi all,

This is part of the security analysis that we have performed about the 
RRH.

I guess that we could summarize it as follows:
- The RRH security issues that we identified are more related to lack 
of specification rather than fundamental ones. Meaning that IMHO, the 
current draft doesn't take into account some issues, in particular 
time-shifted attacks, when performing the RRH.
- The identified issues can be solved through proper host behaviour.

The main security problem of RRH imho is related with the fact that the 
signaling channel between the MR and the HA is protected through a 
IPSec SA that may be manually configured, for instance. This means that 
the resulting level of trust may be relatively high. However, the 
information contained in the RRH, is not protected with this SA, and 
its protection relies on that the presence of the attacker along the 
path, so the information obtained through RRH has a different level of 
trust than the information obtained through a BU sent from the MR to 
the HA. However, both informations are stored in the same BCE, with the 
same parameters, in particular with the same lifetime. This is a 
security problem since the lifetime of the BCE is closely related with 
the level of trust of the information within the BCE, in particular, 
the BCE lifetime defines the level of protection against the time 
shifted attacks.
Now, the information protected with IPSec SA between the MR and the HA 
is not vulnerable against time shifted attacks, while the information 
contained in the RRH may be vulnerable to time shifted attacks, as 
presented next.

The key elements when preventing time shifting attacks, imho, are:
- the BCE lifetime
- the frequency of the RRH

Now let me put an example of how a time shifted attack would be imho:
- suppose that the MR is configured to send a RRH only with a 
relatively low frequency once that the first RRH is sent i.e. it 
doesn't sends RRH in all data packets, only in one in a time T (suppose 
time T long for efficiency). I guess this makes a lot of sense since we 
don't want to introduce the RRH overhead in all packets.
This means, that upon the reception of the RRH, the information 
contained in the RRH will be stored in the HA BCE for the BCE lifetime 
(which may be very long) and will not be refreshed for a period T.
Now suppose that an attacker, that is on the path, modifies the content 
of the RRH, including its own address on the RRH.
This means that for the time T, the HA will be sending packet to the 
attacker.

Now MIPv6 prevents this type of attacks by limiting BCE lifetime to 7 
minutes. The problem here is that the BCE lifetime may be higher 
because the BU that has created it was protected with an IPSec SA.

The result of this attack is that an attacker may be on the path for 
just a moment and launch an attack that last for a period T (which may 
be very long)

AFAICT the draft does not consider this explicitely, in particular it 
doesn't defines values for T.
Please note that sending the RRH in every packet doesn't really 
protects against this attacks, since for instance unidirectional flows 
comming from the HA to the MR would still be susceptible to this type 
of attacks.

My suggestion would be to limit the lifetime of the information 
obtained from the RRH to 7 minutes, the same that the BCE information 
obtained through the RR procedure.

Comments?

Regards, marcelo