Hello Ken,
Erik suggested in his email definnig a new type for
the RS. The use of this new type should be enough
to show the HA that the request is coming from a MN
and that it is not a normal RS.
I think doing that removes the need for the Home address
option and the additional complication that comes
with that (what should be in the option ...etc).
Also it would be a much cleaner approach IMO.
Cheers,
Hesham
> -----Original Message-----
> From: Powell, Ken [SMTP:[EMAIL PROTECTED]]
> Sent: Saturday, 17 February 2001 9:55
> To: 'T.J. Kniveton'; [EMAIL PROTECTED];
>[EMAIL PROTECTED]
> Subject: RE: New idea for Router Sol/Adv and Mobility
>
> 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]
--------------------------------------------------------------------
