Subject: RE: [nemo] RO taxonomy

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 29 Oct 2004 11:54:12 +0200

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

I believe that you are clear, in your response to Brian, that the problem is introduced by NEMO; and that the situation where the 2 bindings are related should not occur in MIPv6. 

So now, I'm confused... why should RFC 3775 say anything here? 
 
> 
> > 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.
>

OK. Seems you're changing the rules. All this talking is about the algorithm that you detailed in this thread, and that is basically MIRON as I understand it. If we go to the delegation space, it's another chapter in the taxonomy, it's a very different discussion, and all my arguments here do not apply. Actually, as you know, I like the delegation space very much, and share a draft with Ralph on doing some LMM/RO that way.

Now, as I understand your algorithm, each MR would bind the careof of its visitor (as a home address) with its own careof. If the visitor is a MR doing the same thing, we end up creating a chain of bindings at the CN, again, exactly as you detailed in the next mail. 

The specific problem I was discussing here is that each MR would actually add a HoA option to the packets on the way to the CN. And I do not see an existing CN implementation understanding the semantics of this chain of home address options in a same packet.

The RRH and RO taxonomy drafts both have some text that list generic problems with that approach (I copied the RRH text inline in a separate mail). 

I think that discussing over your algorithm is an excellent education for us all on that very new problem, and that our conclusion should reside in the taxonomy draft. One thing I had in mind, starting the RO taxonomy draft, was to save some of this WG time by sharing our findings on various families of approaches, including the MIRON one, in a single document. 

I hope that soon we can let that specific exercise behind and move forward.

Pascal

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 29 Oct 2004 10:09:01 -0700

Pascal Thubert (pthubert) wrote:

> I believe that you are clear, in your response to Brian, that the
> problem is introduced by NEMO; and that the situation where the 2
> bindings are related should not occur in MIPv6.
> 

Because a broken or malicious node might cause the same thing.
So at least the CN/HA shouldn't crash or die because of the multiple 
related bindings.

>>> 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.
>> 
> OK. Seems you're changing the rules.

No, I was merely confused by your unstated assumption that there was no 
address delegation in your case above.

  All this talking is about the
> algorithm that you detailed in this thread, and that is basically
> MIRON as I understand it. If we go to the delegation space, it's
> another chapter in the taxonomy, it's a very different discussion,
> and all my arguments here do not apply. Actually, as you know, I like
> the delegation space very much, and share a draft with Ralph on doing
> some LMM/RO that way.
> 
> Now, as I understand your algorithm, each MR would bind the careof of
> its visitor (as a home address) with its own careof. If the visitor
> is a MR doing the same thing, we end up creating a chain of bindings
> at the CN, again, exactly as you detailed in the next mail.

Nope. Each Nemo aware MNN would have lots of addresses to choose from,
one from each layer of MRs.
In particular, it would have a address delegated in a nested way from
the AR.
It can use this address as the CoA and do a regular MIPv6 BU to a CN.

This assumes that in the nested case the AR hands out sufficient address 
space to pass down a piece to all the links in the nested network.
But the MRs don't have to do anything special except delegating the 
address space (and announcing it to their downstreams in a way that
doesn't confuse any LFNs).

> The specific problem I was discussing here is that each MR would
> actually add a HoA option to the packets on the way to the CN. And I
> do not see an existing CN implementation understanding the semantics
> of this chain of home address options in a same packet.

Agreed.
It makes sense to focus on the cases when the CN isn't modified
and look at what the MRs and MNNs need to do in that case.

    Erik

> The RRH and RO taxonomy drafts both have some text that list generic
> problems with that approach (I copied the RRH text inline in a
> separate mail).
> 
> I think that discussing over your algorithm is an excellent education
> for us all on that very new problem, and that our conclusion should
> reside in the taxonomy draft. One thing I had in mind, starting the
> RO taxonomy draft, was to save some of this WG time by sharing our
> findings on various families of approaches, including the MIRON one,
> in a single document.
>