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

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 17 Oct 2002 23:23:34 +0200

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

=> Hmm. These functions are limited to the "home interface"
on which the home address is configured and shouldn't interfere
with messages on the visited link. Since the ND-related messages
on the home link are few and far between, I don't see 
this as an important issue.

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

=> or by observing the actual MPA when protected with
AH, or observing the packets containing a HAO.

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

=> The second sentence needs more elaboration/justification 
I think. Just because the attacker can attack in different
ways doesn't justify introducing a new way. I don't get the
logic. At least not yet.

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

=> How about removing one of the valid prefixes and 
keeping a prefix with a short lifetime (being renumbered
for example).

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

=> Agreed.

  > 
  > - MPS does not need to be authenticated.

=> Not sure about this one.

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

=> I'm very reluctant to agree with this recommendation
for a number of reasons: 
- I don't see a good reason for allowing yet another
type of attack when it can be easily avoided. sending
ND messages across multiple links is not allowed in 2461
and the same applies to ARP. 

- If an attacker changes the lifetimes during renumbering,
it could take a very long time for this to be detected. 
The home address might time out and the MN will
take some time to recover. During that time the CN can 
be fooled into believing that it is communicating with the MN.
Yes, this can be done in different ways today, but 
	a. Are they really easier?
	b. why should we give more alternatives
         to the attacker?

- The whole renumbering/S bit area is very grey and 
extremely tricky to analyse and implement in a clean
way. I haven't seen any substantial discussion or analysis
of this. Adding another vulnerability to the process
won't help. 

While these points might seem like a non-concrete
case for keeping the protection, I don't see a concrete
case for removing it either. The fact that we don't 
know enough about how renumbering will be done, the 
use of the S bit with renumbering and allowing something 
that is not allowed today (insecure ND across multiple links)
makes me question the need for this late change. 

If there is a serious concern about ICMP (highly 
under-justified I think) and we are going to spend
some time on changes then we might as well consider
Jarno's suggestion to include this stuff in the 
MH. That is, if time is going to be spent anyway.

Hesham

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 17 Oct 2002 15:25:54 -0700

Jari,

> 
> 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
> 
> 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.
> 
This justification seems a bit weak. I can't remember whether protecting
ICMP selectively (based on code) was ever discussed in Ipsec working
group ever. And we went all the way to create MH (because we could not
protect destination options with Ipsec before), can't we use that for
these messages too ?

-mohan

> 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:
> 
> - 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.
> 
>    used, and it is likely that the same information is also available
>    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.
> 
> 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.
> 
>