----- Original Message -----
From: "Hesham Soliman (ERA)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, February 18, 2001 9:21 PM
Subject: RE: New idea for Router Sol/Adv and Mobility
> 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
