Subject: Re: [mobile-ip] Mobile Routers support without optimization

From: James Kempf <[email-masked]>
Date: Tue, 21 Aug 2001 09:04:55 -0700 (PDT)

Erik,

>The key thing is that we need rules that the CN can use to do 
>authorization checks.
>Those rules better not be circumventable by having any subset
>of HA, MR, and MNN conspire to fool the CN.
>
>Or stated differently, given that the CN doesn't trust anything
>but the ability of the routing system to deliver packets, on a best
>effort basis, to the destination IP address, how can the CN develop any
>trust in a remote entity stating that it should receive packets for
>a whole prefix?
>

IHMO, the answer is "by the same means that any router trusts
the OSPF or BGP updates from other routers that tell it to send packets to a 
remote entity for a whole prefix." Or "by a different means that
allows the CN via some out-of-band authentication technique
to verify that the HA and CN control the prefix in question and
therefore have the right to change it".

This requirement is fairly strict and go beyond the mobile
host requirements of simply proving that the sender of the BU
is who you were corresponding with in the past. But perhaps that
is as it should be, the consequences of hijacking a routing
prefix are much more dire than hijacking an address.

		jak

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Aug 2001 10:50:14 -0700 (PDT)

> prefix are much more dire than hijacking an address.

   There seems to be two separable attacks. First is
   the attack where a spoofer is not reachable
   on the prefix it is attempting to control at all.
   A simple return routability test as is being proposed
   for MIPv6 ought to provide adequate protection to 
   counter that attack (we hope). The second is when
   a node which is reachable on the proposed prefix,
   but is trying to hijack a larger prefix than it is
   authorized for. I believe that the only nodes which
   can make a determination as to whether the mobile 
   router is authorized to advertize that prefix to
   the CN are the routers in the path between MN and
   CN by way of HA.

   In fact, it seems that some router between HA
   and CN ought to know whether it summarizes a prefix
   which is smaller than the proposed prefix and thus
   be able to reject the request. That is, suppose we
   have a MN trying to advertize a /8 to a CN. If the
   CN sends the proposed BU toward MN (say with router
   alert on for grins), and a router in the path discovers
   that it summarizes a /16 toward the MN, then
   it would know that the request is not legitimate
   since it must summarize prefixes which are strictly
   larger than in the downstream direction. Whether this
   solves all potential attacks, I have no idea, but it
   does seem to have the potential for solving this 
   particular attack.

	      Mike

---

From: Alexandru Petrescu <[email-masked]>
Date: 21 Aug 2001 20:20:22 +0200

Michael Thomas <[email-masked]> writes:
>    I believe that the only nodes which can make a
>    determination as to whether the mobile router is
>    authorized to advertize that prefix to the CN
>    are the routers in the path between MN and CN by
>    way of HA.

I think there are cases where the CN can itself
look at what's claimed, send probes and decide
what it can trust.  See my constraints on HA, MR
and MNN home addresses.  Please discard it I
need to get rid of it.

Alex

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Aug 2001 11:40:25 -0700 (PDT)

> and MNN home addresses.  Please discard it I

   Send probes to _what_? I'm afraid that you're
   going to be a lot more specific because the
   trust models along with the knowledge and
   incentives of various hosts/routers are vary
   widely.

		Mike

---

From: Alexandru Petrescu <[email-masked]>
Date: 21 Aug 2001 20:48:51 +0200

>    incentives of various hosts/routers are vary

Sorry, it was "send probes to home subnet".
But it looks like you guys have taken on a
much bigger endeavour, I will step aside.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Aug 2001 09:28:07 +0200 (CEST)

>    counter that attack (we hope).

Agreed.

> The second is when

Yes, this is the second problem I've been trying to shine light on.

>    does seem to have the potential for solving this 

I agree that in theory such a method to extract the hop-by-hop authorization
choices can work. So you are providing a good indication of the issues
in accomplishing authorization for prefix BUs.  

I currently have no idea if such a scheme can be made to work in practice.

  Erik