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

From: "Powell, Ken" <[email-masked]>
Date: Fri, 16 Feb 2001 17:55:28 -0500

Hesham's response helped greatly to resolve the
security questions I had.

At first, I thought the RS/RA exchange between the
mobile node's COA and the home agent during
initialization shouldn't use the home address or
routing header options. That was until I discussed
this with Vlad Yasevich today.

We don't have any reasons for the initial
router advertisement sent back to the mobile
node's COA to have a routing header, but
there is a reason for keeping the home
address option on the router solicitation.

Vlad pointed out that the Home Agent needs a
way to tell that a router solicitation was sent by
a mobile node. This is important because the home
agent needs to send the aggregate prefix list as
defined in section 9.7.1 instead of just the home
agent's own locally defined prefix list. Without some
flag, a home agent would be forced to assume that any
IPsec protected router solicitation with a global
source address came from a mobile node. Reliance on
this assumption could cause problems with some future
application that may also need RS/RA exchanges with
non-linklocal addresses. Attaching the home address
option to the router solicit solves this problem.

Assuming that the home address option is needed,
what address should it contain before the mobile
node generates its home address? On first
glance, the unspecified address seems best. It is
a clear signal that the mobile node has no home
address and that there is no binding. The other
choice is to repeat the care-of address as you
suggested. This might be easier to implement by
requiring less special logic in the protocol stack
for IPsec and home address option handling.
I haven't thought through all the details.
Both these options are going to require some
special handling.

I suppose another option would be to add a
"request aggregate prefix list" flag bit to
the router solicitation message. Such a flag
bit would be easier to implement in that
it would only impact the part of the stack
that deals with router solicitation/advertisement
processing.

What do others prefer?

On to another concern...

I've been trying to sort out how this proposal impacts
section 9.7.2 which specifies the rules for when the
home agent sends Router Advertisements to the mobile
node. These rules require the home agent keep track
of which router advertisement information was sent
to each mobile node. It seems natural that this
state information be stored with the binding cache
entry. I couldn't see how the home agent could
track the information from the RS/RA exchange before
a binding is created.

I think the home agent should treat RS/RA exchanges
between HA and Mobile node's COA as a completely
separate situation and make no attempt to associate
them with a particular mobile node or binding.

When a mobile node sends an IPsec protected RS to a
home agent from its COA, the home agent should reply
with an ipsec protected RA to the mobile node's COA and
no routing header. The home agent may rate limit the RA's
sent to a particular COA. This should be done independently
from the procedure to send RA's to the mobile node's home
address.

To summarize, I think the current draft should:

  1) Use home address option when the mobile node
     sends router solicitations from its home address
     to the home agent instead of fully encapsulating
     the router solicitation.

  2) Protect router solicitations from the mobile
     node with IPsec, the same as router advertisements
     are protected.

  3) Add a new mechanism for an IPsec protected
     RS/RA exchange between the mobile node's COA
     and home agent for possible use during
     initialization. This gets rid of any need
     for a temporary home address as mentioned
     in appendix A. I'm still undecided how
     to handle the home address option here.

I'm going to be off-line next week and won't be
able to respond to any questions till I get back.

Ken

> -----Original Message-----
> From: T.J. Kniveton [mailto:[email-masked]]
> Sent: Friday, February 16, 2001 1:41 AM
> To: Powell, Ken; [email-masked]';
> [email-masked]
> Subject: Re: New idea for Router Sol/Adv and Mobility
> 
> 
> on 2/15/01 1:46 PM, Powell, Ken wrote:
> 
> > 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?
> > 
> 
> 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.
> 
> 
> > 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?
> 
> 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:]
> >> 
> >> 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?
> 
> 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
> 
> 
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Mattias Pettersson <[email-masked]>
Date: Mon, 19 Feb 2001 11:01:59 +0100

> that deals with router solicitation/advertisement

I prefer this new RS type.

If the HA needs to know what home _link_ is in question, in case there
are more than one, it can use the destination address of the RS. Thus,
one fewer purpose for the home address option.

> them with a particular mobile node or binding.

Yes.

/Mattias

---

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 19 Feb 2001 11:08:12 -0800

> one fewer purpose for the home address option.

Let me play devil's advocate:

No new types are required! What we're sending is still a Router
Solicitation/Advertisement. The fact that it is routed gives us more
information:

1. The TTL of RS is < 255, which tells the HA it is from off-link.
2. The HA knows that (1) means it is a mobile node and needs all
prefixes on the link.
3. It sends a regular (HA) RA, and adds prefix options for every prefix
on the link

4. The TTL of the RA is < 255, which tells the MN it is from off-link.
5. The MN knows that (4) means it is a HA-generated RA and applies to
its home address(es)

There is no need to create a new type, when we are simply allowing a
superset of normal RS/RA behavior. Consider the following:

A. If router solicitations are extended to allow off-link RSs, the RSs
for mobile nodes would be totally compatible and "make sense".
B. If RAs are extended as well, these mobile RAs would also make sense

These messages will only ever be shared between MN & HA, who will both
understand what they mean. Nevertheless, the point of (A) & (B) is that
these messages are globally consistent and do not conflict with other
possible extensions.

It makes more sense to think of these messages as router advertisements
and solicitations -- that's really what they are, extended to handle
mobility. If the goal of Mobile IP is to modify/enhance existing
protocols as little as possible to support mobility, adding message
types when it's not necessary is the wrong thing to do.

-- 
T.J. Kniveton
NOKIA Research Center

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 28 Feb 2001 15:32:48 +0100 (CET)

> Solicitation/Advertisement. The fact that it is routed gives us more

Excessive overloading of semantics might not be the best solution.

So let me play the reverse devil's advocate and say:
The cost of adding two new ICMP types is close to zero and it provides
more clarity since the semantics of a regular RA/RS and an RA/RS
to/from a mobile node will be different.
Also, this clarity helps talking about the mobile node which will
receive RAs from the routers on the visited link, and <different
type> messages from its home agent(s).

So what is wrong with adding new types?

> 1. The TTL of RS is < 255, which tells the HA it is from off-link.

Or a spoofed RS. When a router receives a spoofed RS it would presumbly
log an event and/or increase a counter.
With your overloading proposal it can't tell the difference
between a spoofed one and a mobile node using an RA.

  Erik