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 PROTECTED]]
> Sent: Friday, February 16, 2001 1:41 AM
> To: Powell, Ken; '[EMAIL PROTECTED]';
> [EMAIL PROTECTED]
> 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 PROTECTED]
--------------------------------------------------------------------
