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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sun, 18 Feb 2001 13:21:03 +0100

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-masked]]
> Sent:	Saturday, 17 February 2001 9:55
> To:	'T.J. Kniveton'; [email-masked]; [email-masked]
> 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-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: "Koichi Ishibashi" <[email-masked]>
Date: Tue, 20 Feb 2001 10:36:31 +0900

---

From: "Koichi Ishibashi" <[email-masked]>
Date: Tue, 20 Feb 2001 10:36:31 +0900