Subject: RE: [nemo] multihoming: potential threat? (was: about draft-ietf-nemo-requirements-00.txt)

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 28 Mar 2003 19:26:14 -0000

> Are you basically saying that when a mobile network is 
> multi-homed, and the MRs and HA run dynamic routing protocol, 
> then it is possible for one MR to fool the other MR into 
> believing a fake route?
> 

Yes, sort of. The RA is actually a form of connected toute
advertisement, if you'll accept it.

> 
> A topology like this:?
> 
>                             ---------
>                           /          |
>                ----------/           |
>    -------    |          |           |
> -| HA/BR |---| Internet |           |
>    -------    |          |           |
>                ----------\           |
>                           \          |
>                            \         |
>                             |        |
>                             |        |
>                           -----    -----
>                          | AR1 |  | AR2 |
>                           -----    -----
>                             |        |
> 
> 
>                             |        |
>                           -----    -----
>                          | MR1 |  | MR2 |
>                           -----    -----
>                             |        |
>                            ------------
>                                      |
>                                   -----
>                                  | LFN |
>                                   -----
> > 
> > MR1 -> prefix 1 MR2 -> prefix 2

Right, I should have drawn that picture. Thanks for doing it. Note that
MR2 is a rogue, does not even need a real home agent.

> Ok, and both prefixes come from the home domain, right?, not 
> from the visited domain.
> 

Prefix 1 is from MR1's admin domain. 
Prefix 2 is from MR2's admin domain, but if MR2 is an attacker, prefix 2
is anything it wants to intercept.

> > Now if MR1 supports stateless autoconf on that interface:
> > 
> > MR1 will allocate an address out of P2 AND install a connected
> > route to P2 via the ingress interface.
> 
> I don't understand this, why would MR1 configure itself 
> ("allocate?") an address out of P2?  P2 is advertised on the 
> RAs sent by the ingress interface by MR2, not by MR1 right?
> 

MR1 gets RAs from MR2 like anyone else. If it is configured to autoconf
addresses, it will. Try it!

> Also, why would MR1 install a connected route to P2 via its 
> ingress interface?

Because it has an address on that prefix on that interface. So the
prefix is expected to be there. This is true for both static addresses
and autoconf'ed addresses.

> 
> > If MR1 redistributes its connected routes over the routing 
> protocol  
> > with the HA, and if in turn the HA redistributes that, now 
> we end up 
> > with a situation where HA1 advertises P2.
> 
> Do you mean "a situation where MR2 advertises P2"?  If you 
> mean so, then even if MR1 claims to HA that is being capable 
> to route to p1 (as a directly connected interface), and that 
> HA runs dynamic routing protocol both with MR1 and MR2, you 
> might fear of ending up with three routers (HA, MR1 and MR2) 
> that exchange routing information.  So I assume they do it 
> right, that's the job of routing protocols.
> 
> On another hand, if you assume that among these three 
> routers, one is rogue and pretends a prefix that it does not 
> actually own, and injects a route there where it shouldn't, 
> then this can be probably reduced from a model with three 
> routers MR1, MR2 and HA1 to a model with two routers MR and HA.
> 
> In that case, yes, please clarify?
> 

You missed the point. I meant what I wrote. If MR1 did learn P2 from a
trusted routing protocol relationship with MR2, that would not be a
problem, but a standard case. Here MR1 learns the prefix from ND that is
not secure in nature. If there is a MRHA routing protocol and if MR
advertises the info about P2 to HA1, HA1 will trust this. And install a
route to P2. And advertise that to its autonomous system, etc... So
anyone around HA1 is fooled into sending all traffic for P2 to MR2 via
MR1. This is not actually specific to mobility, same as the initial
discussion. 

I do not know if SeND looks into securing the prefix part of RAs. The
trust problem we have in PSBU is exactely the same for RA prefixes, if
you look at it.

Pascal

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Mar 2003 20:56:36 +0100

> is anything it wants to intercept.

Ok, I see. So the basic assumption is that a mobile network is formed
by MR1 and LFN. Then suddently MR2 comes in the picture and offers
Internet alternative access to the mobile network. If that is the
case, then MR2 should do first a form of access control to the mobile
network. I mean, this would be an alternative tool to protect against
that threat, but of course there might be others.

>> ("allocate?") an address out of P2?  P2 is advertised on the RAs
>> sent by the ingress interface by MR2, not by MR1 right?
>> 
> 
> 
> MR1 gets RAs from MR2 like anyone else. If it is configured to
> autoconf addresses, it will. Try it!

Ok, I see, right, it will, if configured. But I wouldn't try this at
home because:

"The autoconfiguration process specified in this document applies
  only to hosts and not routers. Since host autoconfiguration uses
  information advertised by routers, routers will need to be
  configured by some other means."

I mean, there is of course much text in many specs to read, and many
interpretations are possible. Moreover, many implementations do many
things, and many are in widespread use, and many things are common
practice.

So the above cited text is my preferred interpretation, and I have
nothing against other interpretations.

But, if I go with my preferred interpretation, then new doors are open
by "other means", like e.g. zerouter-to-be.

> prefix is expected to be there. This is true for both static
> addresses and autoconf'ed addresses.

Ok, yes, if autoconfiguring an address then the directly connected
route is added in the kernel routing table. I wonder if it will show
up in the app's routing table too after if that is already started.

If it does, then the threat sort of assumes that MR2 (the attacker)
can securely talk to HA to inform it about the fake route.

> You missed the point. I meant what I wrote.

Sorry for missing your point, it was not my intention. All I'm trying
to say is to better refine the threat and identify the potential
protections against that threat. I'm not saying there's no threat.

> If MR1 did learn P2 from a trusted routing protocol relationship 
> with MR2, that would not be a problem, but a standard case. Here 
> MR1 learns the prefix from ND that is not secure in nature. If 
> there is a MRHA routing protocol and if MR advertises the info 
> about P2 to HA1, HA1 will trust this. And install a route to P2. 
> And advertise that to its autonomous system, etc... So anyone 
> around HA1 is fooled into sending all traffic for P2 to MR2 via 
> MR1.

Yes, exactly, I'm getting your point now, you're right.

> I do not know if SeND looks into securing the prefix part of RAs.
> The trust problem we have in PSBU

The biggest trust problem with PSBU (to my understanding) is that it
is a prefix and RR for prefixes impossible, because RR is a ping and
you can't ping all addresses of a prefix.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 31 Mar 2003 20:21:38 +0200 (CEST)

> addresses, it will. Try it!

Note that RFC 2461 doesn't say that routers autoconfigure addresses
based on RAs they receive - it merely states that routers should do some
sanity checks to make sure different RAs don't have conflicting information
(where different prefixes isn't a conflict).

> MR1. This is not actually specific to mobility, same as the initial

I don't think the setup you are considering makes any sense.
If you have two routers on a link they both need to know the full set
of prefixes assigned to that link in order for them to route
packets properly. Having the routers try to learn this by peeking at
router advertisements is not likely to be operationally robust.
And this is not specific to Nemo.

  Erik