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 PROTECTED]
--------------------------------------------------------------------
