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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 16 Feb 2001 11:51:27 +0100

<If I sent this to the wrong MIPaddress could you 
please forward it to the _right_ address.>

Hello

I basically like the idea of not tunnelling. Tunnelling doesn't
do anything for you actually. But I have some comments 
on the details you mentioned below. I'll send a separate 
mail with a similar proposal to yours but with small modifications
and attempt to give some hints for the authorisation problem.

Regards,
Hesham

> > 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.
> 
	=> I'm afraid we can't skip this one. After all this is one of 
	the seeds for the authorisation discussion. Which 
	is one of the reasons holding the draft as far as I know.

> 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.
> 
	=> Well, we're talking about a start up procedure here. So let's 
	assume the MN doesn't have a home address yet. 
	Therefore there is no need to have a HAddress option. 
	I'll explain in a second email how I thought we could 
	replace this.

> 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). 
> 
	=> Yeah. I think you can leave off the routing header for sure.

> > 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. 
> 
	=> But how can the HA verify that based on your proposal ?
	Anyone can include a Home address option in their packets.

> >[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. 
> 
	=> Is that an issue really ? I mean after all _everyone_
	will see that prefix when they do a DNS lookup on the MN. 
	I don't think this would be a problem. Unless I missed 
	your point ?

> 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.
> 
	=> You expose your home link's prefix as soon as you
	start communicating with anyone. 

> 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.
> 
	=> Agreed.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 16 Feb 2001 12:12:42 +0100

Hello again, 

There is a number of problems that need to be solved 
I think to get the right proposal.

- ND does not allow you to send an RS outside your 
  subnet. 

- MNs need to get the Home network prefix to configure
  themselves with a Home address. 

- To be able to send an RS with TTL <255 you need to be 
  authorised to do so. 

So based on this list, I don't think that tunnelling the 
RS from the MN to the HA will buy us anything. 
Strictly speaking the HA can drop the packet anyway
if he MN is not authorised to send an RS across 
subnets. 

So I think one way to solve this is to send the RS
as follows: 

Src_addr : MN CoA
Dst_addr : HA address
TTL < 255
Obviously secured by AH or ESP.

Now we're faced with difficult task of authorising this 
user to send this message. 

There are two options that I can think of: 

1. PKI

If the MN has a PK and the HA is aware of all PKs for 
all MNs that it serves, then all the HA needs to do
is be able to verify the identity of the sender. Ie. verify
that the sender is actually _one_of its MNs. This verification
is obviously based on using the PK as an identifier for 
the MN. Associated with that Key is the level of authorisation. 

2. AAA

The MN already has a secret key with AAAH. AAAH can be used 
to generate a temporary SA between the MN and the HA
so that the MN can authenticate itself o the HA. The MN
can identify itself to the AAAH based on the NAI and 
NOT the Home address, as it clearly doesn't know that yet. 
When the AAAH establishes this temporary SA, it can 
provide the HA with the MN's NAI, authorisation level ...etc
so that the HA can be sure it is one of it's nodes. 

This proposal (for AAAH to establish SAs) was already 
prsented in San Diego. 
http://search.ietf.org/internet-drafts/draft-soliman-mobileip-routeopt-mipv6
-00.txt

Comments ?

Regards,
Hesham

PS: After writing this mail I saw Erik's mail ! 
I should have read it first and saved myself some typing :)
I think the model is very similar but I'm sending this 
anyway for the authorisation part.

---

From: "Powell, Ken" <[email-masked]>
Date: Fri, 16 Feb 2001 17:55:28 -0500

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:
> 
> Good question. Where this question leads is, how can the HA 
> trust an MN when
> perhaps I can offer a compromise which allows for the 
> possibility of future
> elaboration.
> 
> mobility processing, as stated in my previous message. Stir 
> in addressing as
> follows:
> 
> Address (naturally), EXCEPT if the MN has not configured one, 
> in which case
> 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.
> 
> 
> 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.
> 
> 
> The problem isn't bandwidth here. The security issue is that 
> anyone can see
> the prefix information about that potentially private network. You are
> > Ken
> So I am interested in your comments on my compromise proposal.
> -- 
> TJ Kniveton
> NOKIA Research
> 
>