Subject: RE: New idea for Router Sol/Adv and Mobility

From: "Powell, Ken" <[email-masked]>
Date: Thu, 15 Feb 2001 16:46:22 -0500

> -----Original Message-----
> From: T.J. Kniveton [mailto:[email-masked]]
> Sent: Wednesday, February 14, 2001 6:10 PM
> To: [email-masked]; 
> [email-masked]
> Cc: Powell, Ken
> Subject: New idea for Router Sol/Adv and Mobility

<snip>

> Solution
> --------
> The solution to this problem involves two steps: relaxing a Neighbor
> Discovery rule on the HA and MN, and creating a mobility 
> processing rule
> on the HA and MN. Now RS/RA can be sent without any special Mobile IP
> headers, and look very similar to normal RS/RA, except that they are
> routed unicast packets. This solution is very general, and 
> uses the COA
> and HA addr only, so it does not matter whether the MN does, or does
> not, have an HAddr.
> 
> RELAXING TTL:
> 1. An unicast Router Solicitation arriving at an Home Agent is NOT
> discarded if the TTL < 255 (off-link, from MN).
> 2. An unicast Router Advertisement arriving at a Mobile Node is NOT
> discarded if the TTL < 255 (off-link, from HA)
> 
> MOBILITY PROCESSING:
> 1. The Home Agent receiving a Router Solicitation with 
> TTL<255 (from off
> link) knows that this is a request from a MN, and will include extra
> Prefix Information as per the draft.
> 2. The Mobile Node receiving a Router Advertisement with TTL<255 knows
> that this was sent from a HA and contains HA prefix info and it should
> be processed differently by Mobile IP code to create HAddr(s).
> 
> Recap Of Changes From Current Draft
> -----------------------------------
> We are removing
>  - encapsulation on RS
>  - routing header on RA
> 
> We are adding
>  - a rule that TTL<255 is allowed and specifies mobility signaling
>  - RS and RA come into/out of COA on MN. HAddr is not used for this
> info.
> 
> This buys us
>  - mobile nodes without an HAddr are now routable
>  - simplification and shortening of messages
>  - 

Under this proposal, the Mobile Node will have to re-establish the
Security Association between the Home Agent and its Care-Of Address
every time it moves to support IPsec requirements for Router
Advertisements. How does this fit in with the process of
forming the new care-of address and updating bindings? Will
this cause additional hand-off delays?

How does the home agent determine which mobile node sent the
Router Solicitation? Can the Care-of address on a mobile node
be relied on for this?

> -----Original Message-----
> From: Mattias Pettersson [mailto:[email-masked]]
> Sent: Thursday, February 15, 2001 4:01 AM
> To: T.J. Kniveton
> Cc: [email-masked]; 
> [email-masked];
> Powell, Ken
> Subject: Re: New idea for Router Sol/Adv and Mobility
> 
> 
> Hi,
> 
> "T.J. Kniveton" wrote:
> 
> > Open Issues
> > -----------
> > SECURITY:
> > The Router Solicitation must be protected by an  Authentication
> > Header. This is already a requirement.
> 
> Is it? Where do you find that requirement? The RA needs authentication
> though.
> 

<snip>

> 
> Will we open up a security hole or possible denial-of service 
> attack by let's say flood a HA with RSes (that don't require 
> authentication), now that we can send them over multiple hops?
> 

Yes, this does look like a problem, but I think its just as
serious in draft 13. Any node could repeatedly send router
solicits with the mobile node's care-of address (and home
address). The home agent would send a complete Router
Advertisement to the mobile node for each Router Solicit,
possibly eating up expensive wireless bandwidth. Perhaps
the Router Solicit should be IPsec protected?

Ken

---

From: "T.J. Kniveton" <[email-masked]>
Date: Thu, 15 Feb 2001 22:40:47 -0800

> this cause additional hand-off delays?

Good question. Where this question leads is, how can the HA trust an MN when
the MN does not have a trustable identity based on a Home network IP
address? Does it make sense to base security associations on IP addresses
when the addresses themselves are ephemeral and can't be associated to
Identity without the involvement of an outside entity?

Clearly this is already a hot topic. Rather than trying to solve it here,
perhaps I can offer a compromise which allows for the possibility of future
elaboration.

Here's the recipe: start with Draft 13. Now remove encapsulation from RSs
(this is unnecessary and inconsistent). Add the rules for TTL<255 and
mobility processing, as stated in my previous message. Stir in addressing as
follows:

1. The RS is sent with a HAddr option. The HAddr contains the MN's Home
Address (naturally), EXCEPT if the MN has not configured one, in which case
it MAY insert the COA instead.

2. The HA sends an RA using a routing header, as usual. The RHdr contains
whatever was in the HAddr option - namely, the Home Address, EXCEPT if the
COA was in the RS's HAddr option, it goes in the routing header (we could
just leave the routing header off, alternatively). This RA is still
protected by IPsec as in the draft.

This is the best of both worlds:
- In the steady-state case, where a MN has a HAddr, and it needs updated
prefix info, it just sends an RS and the RA is protected with the existing
security association

- If the MN does not yet have a HAddr, it uses the COA, *assuming you have a
way to generate a security association between the HA and the COA*. If you
can not do this, there is no way to get an IPSEC-protected RA. This is part
of the "bootstrap problem."
  As soon as the MN gets a home address, it can use the HAddr in all future
RSs, so this does not suffer from the problem Ken brought up, of having to
update the HA/COA sec.assoc. every time you handover. Using the COA is a
one-time thing while bootstrapping.

This leaves room open for developing a dynamic security architecture where
trust is based on something other than strictly the IP address. For
instance, an NAI, signed key, (whatever) might be used instead.

> Router Solicitation? Can the Care-of address on a mobile node

I contend it doesn't matter. You just need to know that it was sent from a
mobile node. The information you include in a solicited RA consists of the
prefixes from your own AdvPrefixList, and the prefixes advertised (and
therefore served) by all other HAs on the link. No other prefixes will be
Mobile-IP-routable, and so they don't matter while the MN is off-link. The
MN should be able to configure any/all of these prefixes and be served by
any of these HAs, so you must send them all to any node who solicits.

>[Mattias Pettersson wrote:]
>> 

The problem isn't bandwidth here. The security issue is that anyone can see
the prefix information about that potentially private network. You are
thereby exposing the fact that a certain IP address is a router, that it's
also a home agent, and what some or all of the prefixes on that link are.
And you're exposing it to anyone along the path to the MN.

Regarding the bandwidth issue, who cares that the HA will send RAs to the
mobile? If you want to use the MN's bandwidth, nothing stops you from just
sending it packets yourself! Anyway, the HA could protect against this by
limiting the rate at which it sends RAs.
> Ken

So I am interested in your comments on my compromise proposal.
-- 
TJ Kniveton
NOKIA Research