Subject: RE: [nemo] RO taxonomy

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 28 Oct 2004 15:21:04 +0200

> Would do you mean by "ATTACK"?
I mean causing the flow to fail.Maybe CN trying to make sense of a HoA option in a CoT message and updating the wrong binding?
Or having a chain of HoA options so that an existing implementation gets confused?

If we are really interested in digging here, I can try to figure out a scenario where such a thing happens. 

> 
> The RR tests are independent so a proxying MR doesn't need to 
> interfere with a VMN doing the same thing. But there is an 
> issue with a CN seeing BUs that create "nested" bindings.
> Let's take an example:
> 	MN has HA(MN), HoA(MN); it configured CoA(MN) from the mobile
> 	network prefix; let's called the CoA P1::IID
> 
> 	MR has HA(MR), HoA(MR), gets CoA(MR) from the AR and advertises
> 	P1 on the mobile network.
> 
> 	Thus the MN would try to setup a binding in the CN from HoA(MN)
> 	to P1:IID. I doing so it would receive a HoT tunneled from
> 	its HA (which the MR can't even see if ESP is used on the
> 	tunnel) and a CoT addressed to P1::IID.
> 
> 	Should the MR try to do a proxy RO on behalf of the MN
> 	then the only thing the MR knows is that it has a MNN with
> 	the IP address CoA(MN); it might not be able to tell that this
> 	is a VMN. For example, if the VMN does not perform RO and has a
> 	ESP tunnel with its HA, to the MR it looks like a MNN which has
> 	an ESP tunnel which could be a VPN or whatever.
> 	Thus the MR would try to route optimize by creating a binding
> 	in the CN for CoA(MN) (P1:IID) to the CoA(MR).
> 	In doing so, it would need process the CoT sent to CoA(MR),
> 	but this doesn't interfere with any CoT that the MN would
> 	trigger itself since the destination address is different.
> 	The MR would also need to intercept the HoT packet addressed
> 	to P1:IID, but this doesn't interfere with the above HoT
> 	tunneled to HoA(MN).
> 
> Hence both the MR and MN can complete the BUs to the CN.
> If they do, it would result in two separate binding on the CN:
> 	from HoA(MN) -> P1::IID
> 	from P1:IID -> CoA(MR)

I think I understand what you mean; yes, that much should work...
with the restrictions already in the list from Ville and Vijay. 

Let's look at the flows a bit more:

case one)  VMN does not attempt RO yet. So the only CN is HA(VMN).
So we end up with MR doing RR test with HA(VMN). Say HA(VMN) accepts trying.
The security you had by signing the careof in MIP6 is now back to that of the RR test. 
We have to see what threats this opens.

In short, I think that the result is the same security as that of RRH (please have a glance at:
http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-header-05.txt )
AFAIK, the only 'successful' attack identified to date is a time shifting attack, 
discussed recently on this list with Marcelo. It happens if the interval between full 
RRHs is very long. Actually, the default in the draft is on every packet, 
and the usage of RH3 is optional and implementation dependent. 
 
Case two) VMN attempts RO to CN, sends traffic directly to CN; MR sees that and starts its own RO to CN.
Then we end up with what teh RRH draft calls  "1.1  Recursive complexity" and in particular "3.  CN operation"

The text in that RRH section has been reused and then modified as the RO taxonomy draft evolved.
I'm not copying the RRH text here, but if you wish to continue on this topic (please do :) then maybe we can comment on that text directly.

Case three: MR is attached to MR' in a nested configuration.
Think about the egress direction. Would we end up with a list of Home Addresses? There's no definition in the order in which they are stacked, for instance, and what the CN would do with that. 

This discussion is very, very close to the one we had in my group when we designed and implemented RRH. 

Pascal

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 28 Oct 2004 11:34:46 -0700

Pascal Thubert (pthubert) wrote:
> I mean causing the flow to fail.Maybe CN trying to make sense of a
> HoA option in a CoT message and updating the wrong binding? Or having
> a chain of HoA options so that an existing implementation gets
> confused?

1) The CN doesn't receive CoT messages - did you mean CoTI?
2) The {C,H}oT{,I} messages do not modify any state on the CN; only the 
BU does.

> a scenario where such a thing happens.

Please do. I don't see any issue than creating multiple separate binding 
on the CN.

> case one)  VMN does not attempt RO yet. So the only CN is HA(VMN). So
> we end up with MR doing RR test with HA(VMN). Say HA(VMN) accepts
> trying. The security you had by signing the careof in MIP6 is now
> back to that of the RR test. We have to see what threats this opens.

In this case the HA ends up with two bindings - the home binding from
HoA(MN) to P1::IID and the binding created by the MR from P1:IID to CoA(MR).

What does RFC 3775 say about that?

> The text in that RRH section has been reused and then modified as the
> RO taxonomy draft evolved. I'm not copying the RRH text here, but if
> you wish to continue on this topic (please do :) then maybe we can
> comment on that text directly.

Sorry, but I'm trying to have a discussion about the problem space, and 
not comment on any particular proposed solution; we need to understand 
the problem space first IMHO.

> Case three: MR is attached to MR' in a nested configuration. Think
> about the egress direction. Would we end up with a list of Home
> Addresses? There's no definition in the order in which they are
> stacked, for instance, and what the CN would do with that.

You need to specify where the addresses come from in this case.
Is there prefix delegation so that each MR gets a piece of address space 
from the AR, or not?

If you have delegated prefixes (which are marked as special so that LFNs 
don't use them) then each nemo-aware VMN can use a CoA from the AR 
delegated prefix and just MIPv6 BUs.

That is simple, but assumes delegated address space.

    Erik