Subject: [rrg] ILNPv6 Mobility

From: Ran Atkinson <[email-masked]>
Date: Mon, 26 Jul 2010 07:36:31 -0400

Earlier, Tony Li wrote:
% ILNP does not provide mobility support for locally unique IDs.

That is a confusion.

I've already given this counter-example once, in longer form,
although Robin and Tony apparently did not read the earlier
note.  

SIMPLIFIED EXAMPLE

A first node is using a cryptographically-generated local-scope ID.
(The IPv6 RFCs on this don't need changes for ILNP.  Please go read 
them now, as I'm not going to try to repeat the RFCs here.)

First node roams to a new subnet.  Some other node ("attacker")
is trying to block that first node from roaming by using the
first node's ID on the new subnetwork.

The first node can authenticate cryptographically that it, 
and not the other node ("attacker") is the authorised node 
for that ID value -- using the mechanisms already defined in 
IETF SEND RFCs.

END EXAMPLE

Thus, we can see that (1) the alleged attack does not work
and (2) that local-scope node mobility can work.

QED

---

From: Robin Whittle <[email-masked]>
Date: Tue, 27 Jul 2010 01:22:59 +1000

Short version:    Ran states that ILNP mobility can be achieved
                  with SEND (IPv6 SEcure Neighbor Discovery) -
                  and gives an example.

                  Yet his explanation seems to be based on a
                  misunderstanding of SEND - he does not seem
                  to recognise that the SEND algorithm uses the
                  upper 64 bits (the /64 subnet prefix) as one
                  of its inputs.

                  Because it does use the upper 64 bits, I argue:

                  1 - ILNP can't provide either multihoming or
                      mobility if used with SEND.

                  2 - Therefore, section 13.6 of draft-rja-ilnp-
                      intro-05 is incorrect.

                  SEND seems to be hardly used anyway.

Hi Ran,

> although Robin and Tony apparently did not read the earlier

I read it but didn't respond - I didn't know much about SEND, but I
figured it probably wasn't widely used.

Your message was:

  ILNP Mobility & local-scope IDs
  http://www.ietf.org/mail-archive/web/rrg/current/msg07116.html

regarding SEND (SEcure Neighbour Discovery) for IPv6:

  http://tools.ietf.org/html/rfc3971  (2005-03)

However, SEND is not incorporated in the update to RFC 2461:

  Neighbor Discovery for IP version 6
  http://tools.ietf.org/html/rfc4861  (2007-09)

    3.3 Securing Neighbor Discovery Messages

        . . . A general solution for securing Neighbor
        Discovery is outside the scope of this
        specification and is discussed in [SEND].

So how many IPv6 networks are likely to use it in the foreseeable
future?

It's hard for me to tell with a quick web search, but Stéphane
Bortzmeyer wrote (2009-09-15):

  http://www.bortzmeyer.org/3971.html

     Pourquoi SEND n'est-il pratiquement pas déployé?
     Il y a sans doute plusieurs raisons : le
     déploiement est difficile puisqu'il faut mettre
     la clé publique des routeurs dans chaque machine
     et la sécurité du protocole NDP n'est pas vraiment
     un problème aujourd'hui (à part sur le réseau de
     Defcon, les attaques réelles sont rares).

Google translation:

     SEND Why is it hardly made? There are probably
     several reasons: the deployment is difficult because
     the public key must be put routers in every machine
     and protocol security NDP is not really a problem
     now (besides the Defcon network, the actual attacks
     are rare).

Here is what you wrote in your previous message:

>   As I hope everyone now understands, the IETF SEND work can
> be used with ILNP.  With SEND, the ID value is a function of
> the cryptographic key used by the legitimate node using that ID
> value.

This statement is incomplete, and therefore incorrect.

The ID (lower 64 bits, or most of them) is not simply a function of a
public key.  Numbering these 64 bits left to right, bits 0, 1 and 2
are set according to the choice of the "Sec" parameter (higher values
mean more work computing the SEND ID).  Bits 6 and 7 are set
according to the 'u' and 'g' bits:

  http://tools.ietf.org/html/rfc3513#section-2.5.1

So the SEND ID contains chosen values for 5 bits, with the remaining
59 being set by the crypto algorithm.

These 59 bits are a function of:

  1 - The upper 64 bits (subnet prefix) of the network in which
      the SEND ID is to be used.

  2 - The public key of the host.

  3 - These 3 "Sec" bits.

See:  http://tools.ietf.org/html/rfc3972#section-4

        The process of generating a new CGA takes three input
        values: a 64-bit subnet prefix, the public key of the
        address owner as a DER-encoded ASN.1 structure of the
        type SubjectPublicKeyInfo, and the security parameter
        Sec, which is an unsigned three-bit integer.  The
        cost of generating a new CGA depends exponentially on
        the security parameter Sec, which can have values
        from 0 to 7.

> SEND uses that cryptographic key to generate unique
> authentication data that is cryptographically bound to the ID.
> Unless the underlying cryptographic algorithm (i.e. RSA, SHA)
> has been broken [1], an adversary will not be able to infer
> the cryptographic key from knowledge of the ID.  So, if one
> chooses to deploy the SEND mechanism, this prevents an
> adversary from stealing the ID.

Yes, but since SEND uses the upper 64 bits (AKA subnet prefix) then
for a given public key and value for "Sec", there will be a different
value for the 59 free bits of the ID (lower 64 bits) for every
different /64 the operation is performed in.

> In turn, this means that a node using a CGA (e.g. with SEND)
> can fully participate in ILNP mobility.

I don't see how it could, since if the host goes to another access
network - which be in another /64 (another subnet prefix) - then SEND
will give it a different 59 bits for its lower 64 bits.

ILNP mobility relies on the the host having the same lower 64 bits no
matter what access network it is on, since this is the host's ILNP ID
(Identifier).

So I can't see how you could make this work.  The same goes for
multihoming.

> If some other node tries to use the same local-scope ID on
> any link using SEND, that other node will not possess the
> required cryptographic key material, so that other node won't
> be able to successfully complete the Secure ND (SEND) process.

I agree, within a given /64, if all the networks within this subnet
prefix use SEND - and therefore require that all hosts be SEND
compatible (SEND is not part of the main IPv6 specification) - then
as long as two hosts A and B have different public keys, then there's
no way host A can gain the IP address (with the same 59 bits) which
host B should get, and vice-versa.

> Note further that nothing prevents a node from having multiple
> valid CGAs at the same time, each with its own key material.  So
> folks who wish to vary their ID values over time for perceived
> privacy reasons aren't locked out from mobility either.

I guess generating a series of public keys and then getting the
corresponding lower 64 bit interface identifiers (with the 59 bits
calculated by SEND) would be a way of achieving some degree of
"privacy" - AKA anonymity by using multiple IP addresses in an
attempt to hide from servers the fact that multiple sessions
originate from the one host.

But all these addresses are within the one /64.  This would severely
limit the power of this approach - since there are a bazillion /64s
and enquiring minds (or the Googleplex, or other plexes with such
aspirations) scrutinizing log files of one or more servers can easily
keep an eye out for sessions originating from a given /64, knowing
that some or all of them could be from a single host and therefore
single human user.

> [End of example]
>
>  One could devise multiple examples to illustrate the main
> point above.  Due to extremely scarce time, I'm only providing
> one example.  I'm sure others on this list could come up with
> other examples, and will leave generating a more comprehensive
> list to others.
>
> Yours,
>
> Ran
> ran.atkinson at gmail.com
>
>
> PS:  Nothing above is new.  It has all been clearly documented
>      before now, in various papers, including draft-rja-ilnp-intro.

As far as I can see, nothing resembling the above is mentioned in
your draft.  (I haven't read your papers, since as far as I know,
ILNP is well described in your drafts.)  The only mention of SEND in
your drafts is:

    13.6 Neighbor Discovery Authentication

         Nothing in this proposal prevents sites from using the
         Secure Neighbor Discovery (SEND) proposal for
         authenticating IPv6 Neighbor Discovery. [RFC 3971]

But this seems to be incorrect if ILNP is to support mobility, for
reasons I just mentioned.

Likewise if if ILNP is to support multihoming.

Let's say a host is multihomed using ISPs which give it addresses in
two /64 prefixes: PPPP and QQQQ.  ILNP multihoming (and mobility)
relies on the host having the same ILNP Identifier (hereafter "ID",
in this example AAAA) no matter which of these IPv6 addresses it uses:

  PPPP-AAAA
  QQQQ-AAAA

If both ISPs use SEND, then this is not going to happen.  The host
could have some public key which generates AAAA in the PPPP ISP's
SEND system, but that public key would not generate AAAA in ISP
QQQQ's SEND system.  Furthermore, given that some public key PKA1
generates AAAA in the PPPP system, there's no way the host could
generate a key-pair with public key PKA2 which will generate the ID
AAAA in the PPPP SEND system too.

So I think the above-quoted 13.6 statement in your draft is incorrect.

>      All that this note is doing is repeating what Steve Blake
>      and others have pointed out, and what the existing IETF
>      standards-track RFCs on CGAs and SEND have specified.

Maybe so, but I can't see how you could use SEND with ILNP for either
multihoming or mobility.

> [1] Note that an ordinary "collision attack" on SHA-1 would not
>     be sufficient to compromise SEND.  An adversary has to find
>     the precise key value used for authentication, which is a
>     significantly harder problem than an ordinary "collision
>     attack".  A quick web check of the published literature
>     reveals no reason to believe that any significant progress
>     has been made on attacking either of these algorithms in a
>     manner that would be relevant for SEND.

Sure, but as far as I can see, SEND can't be used with ILNP.

> them now, as I'm not going to try to repeat the RFCs here.)

I assume you mean using SEND, as you previously described.

> for that ID value -- using the mechanisms already defined in 

Actually, the first node can't get the same ID on the new subnet (the
second /64 which the mobile node roams to, as I described above.  If
the second /64 also allowed only SEND, then the attacker wouldn't be
able to get the same ID either - but that doesn't matter, since as
far as I can see, ILNP can't work with SEND.

> and (2) that local-scope node mobility can work.

How can ILNP do either mobility or multihoming when using SEND to
generate its IDs?

I have already argued that ILNP can't provide mobility in a robust
manner, due to the ease with which any ILNP or IPv6 host could mount
the DoS attack Xiaohu Xu first mentioned, which I call "Identifier
squatting":

   http://www.ietf.org/mail-archive/web/rrg/current/msg07155.html

Toni Stoev agreed.

  - Robin

---

From: Tony Li <[email-masked]>
Date: Mon, 26 Jul 2010 08:34:07 -0700

> % ILNP does not provide mobility support for locally unique IDs.

Indeed.  Suppose a node with local-scope ID wishes to roam outside of its scope?  How does that work? My understanding is that it needs to change its ID.

Tony

---

From: Ross Callon <[email-masked]>
Date: Mon, 26 Jul 2010 14:28:09 -0400

This would seem to be pretty much the definition of "local scope". 

Thus, the inability of a system to use a local scope ID outside of the scope of that ID is implicit in the definition of "local scope", and in my mind is not a limitation specific to ILNP. As I understand it, ILNP *allows* use of local scope identifiers, but does not require that anyone ever actually use local scope identifiers. 

Ross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Monday, July 26, 2010 5:34 PM
To: Ran Atkinson
Cc: IRTF Routing RG
Subject: Re: [rrg] ILNPv6 Mobility

Tony

_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg