Subject: RE: [nemo] RO taxonomy

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 27 Oct 2004 15:32:53 +0200

> 
> > In short, I believe that the devil is in the details. I like the wording "packet
> inspection" ;) , but the words snooping and hacking apply very well too. I see it falling
> short after some time. The MR will end up having to lookup every packets for source and
> destination, and modify all the RO'ed packets.
> 
> I agree that any three-party approach, i.e. anything involving proxies,
> is more complex than a two party approach. But if we want to solve RO
> between a LFN (vanilla IPv6 with no mobility support) and a vanilla
> MIPv6 CN, then it is clear that something in between those two needs to
> do some work i.e. a proxy of some form is necessary.
> 
> So the first question is how important it is solve this aspect of the
> problem, and then we can see how to construct the best (but perhaps not
> perfect) proxy solution.

:) I like the approach. If I'm correct, then this encompasses the global HAHA approach as well. In HAHA, the proxies are fixed and do route projection. In other words, they establish tunnels on demand and exchange fine grained routes over the tunnels.

> 
> And if you can modify the LFN then you can probably design things to
> avoid a proxy.
> 
By definition, can't :( We could say we do not support RO for them, but an LFNs exist today.

> > Also, it has to sort out whether the MNN is managing its own mobility or security, or if
> there's another MR or RO solution of some sorts that would defeat its action.
> 
> A MNN wouldn't in general know that there is a MR; it is only for
> Nemo-aware nodes that this question comes up. I think this can be
> handled without interference from the proxy function. The Nemo-aware
> node has two choices in terms of its CoA; it can share the MR's CoA or
> it can get a CoA for itself (from some prefix delegated from the AR to
> the MR and advertised to the Nemo-aware nodes for instance).
> If it shares the CoA then the node needs to do some signaling with the
> MR (because the MR would need to know where to forward the packets it
> receives on its CoA and the HoA of the MNN might not be sufficient for
> this in the case of a VMN). Thus, some form of binding update needs to
> be sent from the MNN to the MR. As a result the MR knows not to apply
> the proxy function for that HoA.

Non NEMO aware nodes might be impacted, though. It comes back to the collocation issue. The MR trying to do RR for a MNN regardless of the MNN type could actually ATTACK a Visiting RFC 3775 MN that would try its own RR test at the same time. And that VMN would not do any binding to the MR. 

Also, RRH allows a nemo aware VMN to manage -and do RO for - its own mobility, transparently to the MR. So there no must the binding you refer, either.

>  > and I agree with CW that we should revisit the RR test. RR is a Work
> In Progress anyway. So I'm not necessarily for keeping the CN unchanged
> whatever the cost.
> 
> I think you are barking up the wrong proverbial tree. Your issue isn't
> with the RR test - it is with the explicit assumption that the "owner"
> of the HoA is the node authorized to say where packets for its HoA are sent.

Sure. The assumption is inherited from RFC 3775. And the test was meant to verify that assumption. And the transport (RH2 and stuff) was built around that assumption as well. Same node, quoting:

   o  The Home Address field in the routing header is one of the node's
      home addresses, if the segments left field was 1.  Thus, in
      particular the address field is required to be a unicast routable
      address.

Now, I understand that you could want to see MR + LFNs as a single node, but I'm not sure that the nodes agree. I mean, it takes some bounding to make a node out of separated boxes. Was that Wellfleet who defined the first distributed router? I participated quite actively on the development of the IBM 3746-950, which did that too.

> So replacing the RR test with something that still has at least the same
> strength would never make the fundamental issue you have go away.

Right, I understand that the new RR test would not check the collocation of 2 addresses on a node but the collocation of a careof and the ownership of the MNP where the target address resides.  

> One could attempt to build solutions which makes delegating the
> authorization to a 3rd party easier, but that still only solves the
> authorization aspect of the proxy and does nothing about its impact on
> the data path with HAO and RH2.
> 
> 
> Note that I'm not saying proxies are easy or a good idea; there is a
> long list of things they need to do correctly and things probably will
> not work when there are multiple paths so that a single proxy do not see
> all packets between a LFN and CN.
> 
> What I am saying is that no matter what you replace the RR test with you
> will have the same fundamental issues with proxies.

:) This is why global HAHA places the proxies in the infrastructure with the expectation that a trust model exists between them. I'm not against proxies... 

Pascal

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 27 Oct 2004 13:45:36 -0700

Pascal Thubert (pthubert) wrote:

> Non NEMO aware nodes might be impacted, though. It comes back to the
> collocation issue. The MR trying to do RR for a MNN regardless of the
> MNN type could actually ATTACK a Visiting RFC 3775 MN that would try
> its own RR test at the same time. And that VMN would not do any
> binding to the MR.

Would do you mean by "ATTACK"?

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)

When the CN sends packets to HoA(MN) it would match the first binding.
I don't think RFC 3775 prescribes what a CN should do when, after 
applying the binding and adding RH2 to the packet, there is another 
binding which matches what is then in the destination field of the 
packet. (But it would make sense to check this in the spec).
So different CN implementations might do different things such as:
  - ignore the second binding
  - apply the second binding in a recursive way i.e. add another RH2
    header
  - fail (drop the packet or crash)

Thus the conservative approach would be to try to prevent the MR's proxy 
binding from showing up.
The MR could observe the CoTI/CoT/BU being exchanged between the MN and 
CN and use this as a trigger to deregister any proxy binding it has done.

> Right, I understand that the new RR test would not check the
> collocation of 2 addresses on a node but the collocation of a careof
> and the ownership of the MNP where the target address resides.

I don't understand how that can differ from the current RR and not be 
less secure.

    Erik

---

From: Ville Nuorvala <[email-masked]>
Date: Thu, 28 Oct 2004 01:56:41 +0300 (EEST)

>   - fail (drop the packet or crash)

RFC 3775 Section 6.1.7 says:

   Binding Updates for a care-of address which is not a unicast routable
   address MUST be silently discarded.  Similarly, the Binding Update
   MUST be silently discarded if the care-of address appears as a home
   address in an existing Binding Cache entry, with its current location
   creating a circular reference back to the home address specified in
   the Binding Update (possibly through additional entries).

What this exactly means is open to interpretation. Strictly speaking it
might mean it is ok to have several linked entries as long as they don't
create a circular reference, but it is unlikely.

I think the general assumption is that there will be just one RH type 2
per packet. That's at least what we assume in MIPL, but of course I can't
speak on the behalf other implementations.

Regards,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: [email-masked], phone: +358 (0)9 451 5257

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 27 Oct 2004 16:37:07 -0700

sorry for the cross posting, but here is something to consider
when RFC 3775 is revised.

> create a circular reference, but it is unlikely.

yes, it should be possible to have several linked binding cache
entries.

> speak on the behalf other implementations.

but we seem to have disallowed by the above by mistake in RFC 3775.

RFC 3775 restricts RH Type 2 to only one address (segments left is
always 1). RFC 2460 says a routing header can occur only once in
a packet. (except for destinations options header, all other
extension headers can appear only once in a packet).

RFC 3775 should have allowed more than one address in RH type 2
and required that the desination address on the packet and the next
addressed to be processed in the routing header belong to the same
node. this would have allowed us to include more than one address
in the routing header, but still satisfy the security requiements
of Mobile IPv6.

Vijay

---

From: Brian Haley <[email-masked]>
Date: Thu, 28 Oct 2004 11:23:07 -0400

>>>  - fail (drop the packet or crash)

I know I purposefully did 1) to not have nesting problems, it's just been a 
while since I played with that code to remember more.

>> create a circular reference, but it is unlikely.

But how can this happen?  If I'm a MN at COA1, would I ever send a BU to anyone 
to say COA1 is now at COA2?  I would think you'd just update the existing 
binding to point at COA2.

In the draft-thubert-nemo-reverse-routing-header-05.txt case, the HA would 
construct a multi-hop routing header, then send it to the first hop.

What am I missing?

> in the routing header, but still satisfy the security requiements

I guess I don't agree 100% with this since RH2 was supposed to be a special case 
to hold the HoA.  Extending it to have more than that seems to turn it into a 
glorified RH0 with MRs in it, but that's my opinion...

-Brian

---

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

Brian Haley wrote:

> But how can this happen?  If I'm a MN at COA1, would I ever send a BU to 
> anyone to say COA1 is now at COA2?  I would think you'd just update the 
> existing binding to point at COA2.
> 
> In the draft-thubert-nemo-reverse-routing-header-05.txt case, the HA 
> would construct a multi-hop routing header, then send it to the first hop.
> 
> What am I missing?

The Nemo context where this was discussed.

There might be a MR which will help a MNN by sending BUs on its behalf
and the MNN might be a MIPv6 MN doing its own BUs.
The MR only "sees" what the MNN has as its CoA so we end up with the MR 
creating a binding in the CN from CoA(MN) -> CoA(MR) and the MN creating 
a binding in the same CN from HoA(MN) -> CoA(MN).

My question was whether RFC 3775 defined what would happen if this was 
done; for instance if it specified to ignore the second binding.
Seems like it does not.

   Erik