Subject: [mobile-ip] rethinking security for prefix discovery

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Oct 2002 22:45:20 +0300

This is a new issue #141, about the need for security in prefix
discovery. An analysis follows, with a new proposal on how to handle
this. This would imply a change both in the base draft and the
HA-MN ipsec draft.

INTRODUCTION

Current drafts for MIPv6 base functionality and the related informational
IPsec set-up call for protection of Mobile Prefix Solicitation (MPS) and
Advertisement (MPA) messages.

In order to protect these messages, a number of additional policy
entries and SAs are needed. Furthermore, given that the IPsec policies
need to protect all of ICMPv6 and can't differentiate between different
messages, feature interactions with Neighbor Discovery or other
functions may be found later.

For the above reasons, people have questioned the need for protection
of the MPS and MPA messages. The purpose of this e-mail is to analyze
the security requirements in detail. We will conclude that security
for MPS and MPA isn't necessary after all.

MPS is a message without significant contents to the home agent.
MPA is a message, solicited or unsolicited, with the following
information:

- prefix information option, which contains a prefix, its lifetime,
   router IP address, and autoconfiguration information
- source link-layer address option, containing the link layer address of the
   home agent
- advertisement interval option, which tells how often the HA will send
   advertisements

MPS-MPA contains an ICMP identity field which helps in matching
MPAs to MPSs. In addition,

REQUIREMENTS

We will analyze MPS first. Since there is no real information in
this message, securing MPS appears necessary only if attackers
could use the MPS to generate an MPA, and use this for getting
some interesting information.

Let's look at the information in MPA then:

- Prefixes themselves are not interesting, as the prefix information
   option already comes from an address with the same prefix.

- Learning prefix information might be interesting only if one
   could associate different prefixes that all reside in the same
   place. However, it is not clear how this information could be
   used, and it is likely that the same information is also available
   by observing inter-domain routing tables or DNS, such as finding
   all alternative addresses for a given fqdn.

   If only internally used prefixes are distributed, then this
   leaks potentially interesting information that can't be
   discovered from other sources.

- Lifetime of prefixes tells something about the policies for
   updating prefix information, and may tell something about soon-to-
   expire prefixes. But it is again not clear if this information is
   useful to anyone.

- The same applies to advertisement interval.

- Source link-layer address for the HA could be recovered. This
   might indicate something about the manufacturer of the interface
   card the home agent is using. However, attackers will not be
   able to use the link-layer address unless they are on the physical
   home link, and in this case they would see the address anyway.

The above analysis applies to eavesdropping MPAs. What forged
MPAs, tricking mobile nodes to accept bad information? Analysis
on changing the information in MPA follows:

- Tricking the MN to believe a too large lifetime. The home
   agent would correct this as it accepts a registration.

- Too small lifetime. The mobile node might have to update
   the registration more often than necessary. However, given
   that only on-path attackers can spoof a valid identifier
   field in the MPA, there appears to be easier and more
   serious ways for the attacker to cause trouble.

   An attacker might also try to send a sufficient number of
   MPAs in order to find a right identifier value, as this
   space is only 16 bits. An attack with 0.5 success probability
   would require 32,768 packets, and there are again easier
   ways to cause problems if such large numbers of packets
   need to be sent.

- Wrong advertisement interval would not change the
   real advertisements.

- Wrong link-layer address might lead to the situation
   where the mobile node needs to do ND before contacting
   its home agent, when returning home. However, the wrong
   home agent could not spoof binding acknowledgements, and
   the base draft also outlines how to do ND when returning
   home, in case it needs to be done.

- Invalid prefix. The home agent will detect this, and
   decline the registration.

- Removal of a valid prefix (say, the only real one) is
   potentially dangerous, as the mobile node could be left
   without any valid home prefix. However, this requires
   again an on-path attacker or a large number of packets.
   Still, a denial-of-service attack can be launched this
   way.

PROPOSAL

- It seems that all information in MPS/MPA can be exposed,
   and there is no need for encryption.

- MPS does not need to be authenticated.

- We are proposing that no authentication is needed for
   MPA either. However, to reduce the risk of denial-of-service
   attacks, the following additional mechanisms are proposed:

   o The current identifier approach is kept, but we add
     a statement that the MPS identifier must be a good
     random number.
   o In receiving a valid MPA, the mobile node must
     first successfully register new prefixes before
     it can send a de-registration for a prefix that
     has become invalid due to the new prefix information.
     This ensures that only on-path attackers can
     perform an attack, and that even they can't
     delete all prefixes from the mobile node.
   o Empty MPAs are disallowed.
   o We provide an admin override to sending
     "internal" MPA information to the Internet,
     and we limit the propagation of site-local
     prefixes outside the site.

TEXT

In the HA-MN IPsec draft, delete all material about prefix
discovery.

In MIPv6 base specification, Section 6.7, change

    An identifier to aid in matching a future Mobile Prefix
    Advertisement to this Mobile Prefix Solicitation.

    =>

    An identifier to aid in matching a future Mobile Prefix
    Advertisement to this Mobile Prefix Solicitation. This
    identifier MUST be generated using a random number generator
    that is known to have good randomness properties [1].

In Section 10.9.1, add to the end of the last paragraph:

    It MUST be possible for network administrators to
    override or restrict the information provided in
    the aggregate list. When sending information from the
    list to a global unicast address, remove all site-local
    prefix information.

In Section 11.4.3, change

    Any received Mobile Prefix Advertisement not meeting this test MUST
    be silently discarded.  For advertisements that do not contain
    a solicitation cookie, the mobile node MAY send a solitication
    containing such a cookie before accepting the advertisement for
    further processing.

    =>

    Any received Mobile Prefix Advertisement not meeting this test MUST
    be silently discarded.  For advertisements that do not contain
    the same value as in a recently sent Mobile Prefix Solicitation,
    the mobile node MUST silently discard the received advertisement
    and send a new solitication.

and

    For an accepted Mobile Prefix Advertisement, the mobile node MUST
    process the Prefix Information Options as if they arrived in a
    Router Advertisement on the mobile node's home link [12].  Such
    processing may result in the mobile node configuring a new home
    address, although due to separation between preferred lifetime and
    valid lifetime, such changes should not affect most communication
    by the mobile node, ...

    =>

    For an accepted Mobile Prefix Advertisement, the mobile node MUST
    process the Prefix Information Options as if they arrived in a
    Router Advertisement on the mobile node's home link [12].  Such
    processing may result in the mobile node configuring a new home
    address. All new home addresses MUST be successfully registered
    to the home agent before de-registering any addresses that have
    become invalid.

    Due to separation between preferred lifetime and valid lifetime,
    such changes should not affect most communication by the mobile
    node, ...

In Sections 6, 10, 11, and 14, delete all references to IPsec
in the context of prefix discovery.

In Section 14, replace the current text with a (brief) version
of this analysis.

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 17 Oct 2002 17:33:56 -0400

Jari

>   serious ways for the attacker to cause trouble.

If the HA can correct a "too large lifetime", why can't it correct
a "too short lifetime"?

>   Still, a denial-of-service attack can be launched this

I don't think this is really possbile due to the "2 hour
DoS rule" in 2462.  It then becomes a problem of a "too
short lifetime".

>   and there is no need for encryption.

OK by me, but some people will argue that it's a security issue
(the same people who insist that a 2-face DNS a security measure).

> - MPS does not need to be authenticated.

Is MPS only valid when a associated BCE (successfull BU) exists?
If so, then I agree.  If not, then there is a potential for a DoS
attack agains the home again by simply sending alot of MPS messages
and forcing the HA to reply with MPAs.

>     delete all prefixes from the mobile node.

As I pointed out above, you will usually hit the 2 hour
rule for de-registration.

>     prefixes outside the site.

OK

-vlad--
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 17 Oct 2002 17:01:27 -0700

>   and there is no need for encryption.

Agree.

> - MPS does not need to be authenticated.

Agree. But I think we should note what Vlad said. The Home Agent
should not respond with an MPA, unless there is a binding cache
entry for the MN.

>     prefixes outside the site.

This is fine with me.

Vijay

---

From: gabriel montenegro <[email-masked]>
Date: Sun, 20 Oct 2002 11:48:43 +0200

After some discussion with Jari, we are both
now recommending we *REJECT* this issue. This means
we leave IPsec protection on MPA/MPS as currently
specified, instead of taking it out as suggested by the
proposal for issue 141.

Here's some further thoughts and observations based on the traffic
on the list as well as on some off-the-list exchanges:

The above proposal did not meet the desired support in the WG alias.
Achieving some rough consensus in support of this issue, although
conceivable, will take even more time.

There were responses that yes, in fact there were justifications to
use IPsec to protect these exchanges.  Some concerns may have been
allayed by recommending that unsolicited MPA's would not be heeded by
the MN. Instead, the MN would use it as a trigger and then initiate an
MPS/MPA exchange. There were other comments to the effect that the HA
would only respond to an MPS if the mobile were in its BCE.
This seems like it may hinder the MN's bootstrapping itself
when away from home, at least according to the scenario in the
draft's appendix (B.5 on Remote Home Address Configuration).

The MPS/MPA exchange, although devoid of IPsec protection, would use the
identification field in the ICMP message to implement a request-response
cookie. This would be accomplished by requiring that the identification
field be inititalized with a good random number generator.

A remaining issue was that it seemed like a waste to send an complete
Prefix Information field in an unsolicited MPA, given that the MN would
ignore it.  An easy answer to this would be to mandate that unsolicited
MPA's could include an empty Prefix Information.

[NOTE: There is no mention in the draft of what the Identifier value in
unsolicited MPA's MUST be set to, for example, zero.]

Another approach would be to include the prefix discovery within the
MH mechanism. At a minimum, we could define a new Binding Error to trigger
the MPS/MPA exchange.  Must check to see how such an "unsolicited BE"
is handled by the protocol.  If it's not, this could be a subtle change
to make at this point, and would not be recommended.

The main issue is: why are we here at this point in time?  It seemed
like we would have a problem after all in trying to protect the MPS/MPA
exchanges with IPsec, and in having potentially some conflicts because
of that protection.  This is a problem that Jari had thought existed
as a chicken-and egg problem. Subsequently, Jari thought about it
some more and it seemed like we would not have such an chicken and egg
issue after all. The reason is that ND in the home link uses link-local
addresses, and we are guaranteed that the MPA/MPS rules will not use
link-local. Why? Because on a separate issue we have decide that
home addresses are defined as "unicast routable addresses"
(which, conveniently enough, exclude link-local addresses).
Thus the IPsec rules for those two cases (MPA/MPS versus ND
at the home link) will not conflict.

After realizing the above point, we should have closed this issue.
It does not make any sense to keep it open at this point, *unless* the
current scheme is broken. As it is, it may be complex, but it works.
Eliminating this complexity may be a good goal to have, but given
the time constraints and the lack of initial consensus in response
to issue 141, it seems like the best course of action is
to reject it and move forward.

-gabriel

---

From: "T.J. Kniveton" <[email-masked]>
Date: Sun, 20 Oct 2002 23:45:36 -0700

I was very convinced by the argument that protections for MPS/MPA are 
NOT needed; those points were clear and fairly intuitive. On the other 
hand, there are arguments that maybe the protection should be mandated 
after all are not as clear to me, FWIW.

> conceivable, will take even more time.

Out of curiosity, what was the desired support? Unfortunately, MPS and 
MPA might not be  high on most people's lists of things to think about, 
so there wouldn't be many comments.

> draft's appendix (B.5 on Remote Home Address Configuration).

This is true. However, that can be mitigated by changing the order of 
bootstrapping: 1. Do DHAAD to configure one home address 2. Establish 
binding/SA 3. Do MPS/MPA.

> MPA's could include an empty Prefix Information.

Good suggestion.

> to make at this point, and would not be recommended.

Agreed - this could be more complicated than it seems, for minimal gain.

> at the home link) will not conflict.

OK, I'm willing to accept that even though I'm not 100% clear on 
following the reasoning to the conclusion. Nevertheless, if we just 
agreed or at least had a pretty good idea that we could remove some of 
the complexity without harm, why not just do it and save ourselves more 
similar conversation about these complexities down the line?

> to reject it and move forward.

I can't really speak to this point; I guess I'll just leave things at my 
comments so far and let it stand at that. :)

> -gabriel
Thanks, -TJ

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 22 Oct 2002 10:53:20 +0200

> after all are not as clear to me, FWIW.

I am still convinced we could simplify the protocol along the lines of the
proposal. I haven't had a change of heart in that respect. What I'm
wondering is if we can do so within the meager time we have. We can
certainly take a couple more days discussing this issue, but we'll
have to close it (and all others) "soon" (we're working on the final
schedule for MIPv6, so please stay tuned).

I also believe that rethinking the whole MPS/MPA exchange might
be a good idea. In that light, doing the work implied by 141
(and incurring the potential delay) may not be worth the meager
benefit. From this point of view, we could just ship it as is
and then after MIPv6 ships take the time to look at more radical
ideas.

> so there wouldn't be many comments.

Hard question to answer. True there weren't that many responses, but
whatever responses we got showed that (a) there was some strong
opposition and (b) we had not done our homework in that some
details still need to be resolved. Can we handle a and b within
a few days?

> agreed 

"agreed" may be too strong, but yes, at least some of us had a
pretty good idea that simplification was possible.

> or at least had a pretty good idea that we could remove some of 
> the complexity without harm, why not just do it 

If we could do it in 2 days (agree on a complete proposal), then sure
that would be good. Can you work on improving Jari's proposal to
have something complete, and gather the required support within this
week?

> and save ourselves more 

To take the time to do a more thorough job?

> comments so far and let it stand at that. :)

Or perhaps you could complete the proposal within this week...

-gabriel

---

From: "T.J. Kniveton" <[email-masked]>
Date: Fri, 25 Oct 2002 02:20:00 -0700

gabriel montenegro wrote:

>> NOT needed; those points were clear and fairly intuitive. On the 
>> other hand, there are arguments that maybe the protection should be 
>> mandated after all are not as clear to me, FWIW.
>
>

This point is understandable, and I did not make any more comments so 
people could focus on the higher priority topics. However, there are a 
couple more things to add before things are wrapped up.

> and then after MIPv6 ships take the time to look at more radical

Yes, rethinking it could yield something better. However, I'm not sure 
it's easier or necessarily better to ship with protection than to ship 
without. "Shipping" the draft with security is a lot easier than 
implementing that specification of it, and it may be a bit misleading to 
have this security, for the following reasons:

1. Although protection is in there now, it was not put there in any more 
reasoned way than taking it out now, according to the conclusions of 
Jari A.'s rational and systematic analysis.
2. The possible attacks from forging MPSes are not great
3. This is what I feel most strongly about and why I'm posting this: I 
think that protecting the contents of an MPA is a false assurance. It is 
ten times better for the Home Agent's links to not have any sensitive 
prefix information on them, and/or for the HA to be configured to *not 
send* any MPAs or at least minimize the prefix info, if that info is 
sensitive. Just encrypting it does not really protect the network as 
much as alternative answers would.
4. There is nothing stopping anyone from protecting MPS/MPA in exactly 
the way it is described now. However, it should not be *mandatory* 
because the added complexity doesn't buy much in the default case where 
the configuration at the HA might be sloppy.

>> Out of curiosity, what was the desired support? Unfortunately, MPS 
>> and MPA might not be  high on most people's lists of things to think 
>> about, so there wouldn't be many comments.
>
>

There didn't seem to be any strong opposition that was well reasoned and 
laid out. It just seemed like a good idea to put the protection in, so 
we did.

>> or at least had a pretty good idea that we could remove some of the 
>> complexity without harm, why not just do it 
>
>

I didn't really have a good idea on how to put something together inside 
of a couple of days that would be convincing enough to satisfy everyone. 
People seem to have their own opinions on the subject of securing 
protocol messages and prefix info already formed.

>
>> and save ourselves more similar conversation about these complexities 
>> down the line?
>
>
>> I can't really speak to this point; I guess I'll just leave things at 
>> my comments so far and let it stand at that. :)
>
>

Hmm, I guess the proposal would be to make protection on MPS and MPA 
optional. There, that was easy. :-)

> -gabriel
TJ

---

From: Jari Arkko <[email-masked]>
Date: Mon, 28 Oct 2002 18:06:36 +0200

> optional. There, that was easy. :-)

Could this be an acceptable compromise?

Note we already currently (well, in the version that I have) say that
support is a MUST but use is a SHOULD. Is this enough or should we
downgrade both to SHOULD?

Jari