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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 19 Jun 2002 17:05:44 +0200

After some off-list discussion with a few people, 
I'm getting quite confused about the reason 
for having the mobile prefix sol and adv. 
I know this was done a long time ago, but we 
were discussing some security issues and then
I couldn't help but ask: why do we need these 
messages at all? 

To be able to send these messages, the MN needs
to have the HA's address. If it knows that, then it
knows its home address....
Do we need to complicate things and have another 
message pair, that are sent with different src
addresses, and cannot be secured?

Can't the HA just include some prefix options in
the BA ? or even BR ....or whatever message that
can be secured with the MN - HA SA? 
(not relying on dynamic SAs would be an advantage
of course, for obvious reasons). 

Hesham

---

From: "T.J. Kniveton" <[email-masked]>
Date: Wed, 19 Jun 2002 09:39:27 -0700

> of course, for obvious reasons).

Hi Hesham,

I am guilty of writing these sections into the MIPv6 draft, so I guess I should
answer your query. :-)

The mobile prefix solicitation and advertisement were added to the draft for a
couple of reasons, which I will detail. They grew out of the "tunneled router
solicitation/advertisement," which were in the draft previously, but
insufficient to meet all the requirements, and had some problems. I don't have
the draft on hand at the moment, but let me address your question from memory
and others can add more if necessary.

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). 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.

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

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.

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.
This is easily avoidable when static configurations are used (and thus not an
issue at all), but the design philosophy of IPv6 seems to encourage creating
networks starting with nothing or very little.

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.

If you are interested on more information about MPS and MPA, check out the list
archives from around May 2001. When writing these sections, I consciously tried
to reduce as much complexity as possible from Tunneled RS/RA to ease
implementation and fix some problems. Of course, it may be possible to simplify
them even more while preserving functionality.

-TJ

-- 
        T.J. Kniveton 
  Communications Systems Lab
     Nokia Research Center

---

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Jun 2002 22:10:25 +0300

> suggestions on precisely how to word the clarification.

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.

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Jun 2002 16:36:27 +0200 (CEST)

> addresses, and cannot be secured?

Presumably the IPsec SA used to secure the home BUs could also be
applied to the prefix sol/adv messages. But perhaps the spec doesn't say this.
Should it?

  Erik

---

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 24 Jun 2002 09:20:44 -0700

> applied to the prefix sol/adv messages. But perhaps the spec doesn't say this.

OK, This is already done.

Here is from the description of MPS/MPA on page 63:

:         If a Security Association for the IP Authentication Header
:         exists between the sender and the destination address, then the
:         sender SHOULD include this header.  [subject to change]

and on p 65:

:         An AH header MUST be included unless the mobile node has yet to
:         configure a home address.

and on p 103:

:   To avoid possible security attacks from forged Mobile Prefix
:   Advertisements all such Advertisements must be authenticated to the
:   mobile node by its home agent using IPsec [14, 12, 13] if a security
:   associate exists (i.e.  unless the mobile node does not yet have a
:   home address configured).

If someone wants to use IPsex SAs, that's fine..but they have a limitation in
selecting the right kind of traffic. As Vijay pointed out, an implementor would
probably have to secure ALL ICMP traffic. The alternative is to create a new
mobility header type, which it seems too late to do now.

The spec, as written, will work fine. If someone wants to send unsecured MPS,
the HA can decide its security policy as to whether to respond to an
unauthenticated host. If an MN wants to configure its HA and *then* send an
MPS, it is free to do this as well, just like Hesham suggested. In this case,
the MN might not want to send an MPS, and just be content to know only one
prefix. That is a valid choice as well (though it may get unsolicited MPAs and
must know how to process them).

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 25 Jun 2002 11:19:49 +0200 (CEST)

> selecting the right kind of traffic. As Vijay pointed out, an implementor >
would probably have to secure ALL ICMP traffic. The alternative is to create >
a new mobility header type, which it seems too late to do now.

Or rely on IPsec implementations which can use the ICMP type as a selector?
I don't know how many implementations do this, and I haven't thought about
the interoperability issues when one of HA/MN supports it and the other does 
not - perhaps it could be an optional thing when the HA/MN relationship is
created?

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Tue, 25 Jun 2002 21:59:11 +0300

> applied to the prefix sol/adv messages. But perhaps the spec doesn't say this.

It could. Let's see... we can't use exactly the same SA unless it is going
to cover all traffic between the MN and the HA... the SPD entries couldn't
deal with two protocol numbers (MH for BUs and ICMPv6 for the prefix sol/advs).

So we are likely to need two SA pairs but they could of course be set up at
the same time and with similar SPD entries, with the exception of the protocol
number.

The traffic to be secured would be [hoa -> ha: icmpv6] and [ha <- hoa: icmpv6].

 > must know how to process them).

This is all true, but I'm a bit uncomfortable with this much freedom.
Can we reduce it somehow, to ensure interoperability and reduce the
necessary alternative things that implementations must deal with?

One thing that may be missing is stating the implied limitations.

Perhaps we could state that the sol/adv MUST be secured at all times
using the above schemes, which means that either (a) you must have one
home address to begin with or (b) you must have key management.

Jari