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,
You wrote:
> 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.
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.
Back to your message today:
> 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.)
I assume you mean using SEND, as you previously described.
> 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.
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.
> END EXAMPLE
>
> Thus, we can see that (1) the alleged attack does not work
> and (2) that local-scope node mobility can work.
>
> QED
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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
