Subject: RE: [mobile-ip] confusion about prefix sol/adv

From: [email-masked]
Date: Wed, 19 Jun 2002 18:39:30 -0500

>> As I also mentioned in the e-mail conversation, I would like to clarify the
>> cases when MPS and MPA would be protected by e.g. an AH, and would welcome
>> suggestions on precisely how to word the clarification.
>

What is the security risk associated with not securing the MPS and
MPA? I think we could leave the MPS and MPA unsecured. I believe there
has been previous discussion on this topic and the conclusion is to
use a cookie mechanism. If the issue is related to the MNs being sent
unsolicited MPAs (DoS attack), the MN can send an MPS as a result of
receiving an unsolicited MPA and only act if it receives an MPA as a
response from its HA. I do not believe there are any security issues
related to the HA receiving MPS messages. If the concern is an HA
being flooded with MPS', rate limiting techniques or simply ignoring
these messages can be adopted.

I do not believe we need to have IPsec based security for MPS and
MPA. 

>One potential modification to the current text relates to securing NS. It
>seems to me that it _is_ possible to secure this with AH/ESP even if the
>MN does not yet have an address. Basically, we could have a _single_ SA
>shared by the HA and all the mobile nodes that can be used to send ICMP
>messages to the HA. This SA has to be dependent on the destination address
>per IPsec rules. But it does not have to be dependent on the source address.
>(On the advertisement message the situation is of course reversed.)
>Alternatively, IKE-based security could perhaps be applied.
>
>Another modification to the text would talk more about the specific
>security policy entries that are needed for the protection.
>
>A potential third modification would improve the security of the first
>(unprotected) MPA by adding a cookie in the MPS that would be returned
>by the MPA.

The above (third) modification is the only mechanism that needs to be
applied to MPS, MPA (IMO).

>Jari

-Basavaraj

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 20 Jun 2002 15:06:34 +0200

Hi TJ,

  > The main reasons why MPS/MPA are in the draft are twofold:
  > 1. Bootstrapping. When a MN is starting up, it needs to 
  > know about prefixes on
  > its home network so it can construct an appropriate CoA(s). 

=> You mean HoA(s) ? I don't think it's needed for CoA 
construction.

  > There may be many
  > HAs on the home network servicing multiple prefixes. Any HA 
  > which receives an
  > MPS should respond with a list of prefixes served by HAs on 
  > the home network.
  >   This step is similar to non-mobile address 
  > autoconfiguration, where an IPv6
  > node will send a router solicitation and receive a 
  > (solicited) router
  > advertisement with information about the router and 
  > characteristics of the
  > link, including available prefixes.

=> Sure, but my point was that somehow the MN must
already know the HA's address. Or to be exact, 
it needs to know the HA's anycast address. So
if it knows that it can perform DAAD, then MPS?
I really don't see the need. If the MN knows the
home link's prefix (from the HA's anycast address)
then it has already one home address (since it 
knows its own iid... So why can't the MN send a 
BU _first_, _then_ send an MPS and receive MPA, 
to get the rest of the prefixes?

  > 
  > 2. Maintenance. When a router senses that prefixes have 
  > been added, removed,
  > refreshed, etc., the HA will send a MPA to MNs registered 
  > with it that are
  > affected by the change (or to all MNs registered).
  >   This step is similar to non-mobile periodic unsolicited 
  > router advertisements
  > sent by a router to refresh prefix information on a link.
  > 
  > 3. Renumbering. This is a special case, where the prefixes 
  > in use for a network
  > hierarchy become deprecated when new prefixes are available 
  > (e.g. when
  > switching ISPs), and then disappear entirely. If a MN is 
  > registered during the
  > period of a renumbering event (typically it should take 
  > days or weeks), it will
  > receive information about the new prefix(es). Without this 
  > information, it
  > would not know about the new prefix(es), and potentially 
  > could lose contact
  > with its home network entirely.

=> I'm fine with all of the above, I only object to 
the order in which these messages are sent. I don't
see a reason for this order. We wouldn't need to 
talk about how to secure them, if they were simply
sent after the first BU.

  >   This step is similar to non-mobile unsolicited router 
  > advertisements being
  > sent during renumbering as described in the neighbor 
  > discovery draft RFC 2461,
  > starting on page 78.
  > 

=>Agreed.

  > 
  > It may be possible to operate a mobile node without MPSs 
  > and MPAs, in the same
  > way it is possible to operate a fixed node without neighbor 
  > discovery messages.
  > But that would require a level of static configuration that 
  > seems avoidable.

=> But you already need to statically configure something.
You can do DHAAD if you don't know the HA's anycast address. 
Knowing that seems the same as knowing one home address, unless
you're worried about storing another 64 bits :) 

  > As to the questions people have posed about security 
  > associations, it is
  > desirable to use them at all times possible. And in our 
  > conversation off-list I
  > mentioned that the intent is to use them whenever possible 
  > (i.e. in step 2 and
  > possibly 3 above); however, the SAs are dependent on having 
  > a home address
  > configured, and when MPS/MPA are used, that might not 
  > always be the case (i.e.
  > step 1). It is not entirely clear how to secure messages 
  > between a HA and a MN
  > when the MN is discovering who its HA is, and defining its 
  > own home address.

=> Exactly! so why can't we send them after the BU?
Alternatively you can secure the messages before that
if the HA knows the MN's public key.

Hesham

---

From: [email-masked]
Date: Thu, 20 Jun 2002 13:43:42 -0500

> 
> Vijay Devarapalli wrote:
> 
> 
> > I am not sure if we should do it this way. I agree with Raj.
> > lets go with your cookies approach. and when the MN gets an 
> > unsolicited MPA, instead of using the information, sends an
> > MPS.
> 
> How about the above + note in the spec that you MAY implement
> automatic key management to secure the whole thing if you want
> to?

Optionally, yes.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 24 Jun 2002 16:59:12 +0200

=> That was exactly what I was asking for. If we 
simply re-order the events so that the MN
sends a BU first, then the same IPsec SA can
be used to secure MPS and MPA. I think this 
should work fairly well, andavoid any additional
security mechanisms, which will not be as strong 
as the existing IPsec SA.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 26 Jun 2002 10:44:50 +0200

=> Another thing to add, is there any other ICMP 
message that is currently sent to the HA? 
I don't think so. So there is no harm in securing
ALL ICMP messages (only 2).

Note that the DHAAD is not addressed to the HA's 
unicast address, so it won't count.

Hesham