Subject: [rrg] ILNPv6 Mobility problem

From: Robin Whittle <[email-masked]>
Date: Wed, 07 Jul 2010 21:21:55 +1000

Ten days ago (msg07042) Xiaohu Xu wrote (Re: [rrg] ILNP Identifiers)
about a problem with ILNPv6 and Mobility.

An ILNPv6 host has an Identifier (64 bits): NNNN and as part of its
mobility operations needs to operate from an access network whose
Locator is AAAA.  It might have been working fine on another network
whose Locator is BBBB, because it was able to get the IP address
BBBB-NNNN on that network.

But let's say a second (presumably ordinary IPv6) host on the AAAA
network already has the address AAAA-NNNN.  Then our mobile host
can't get this address in the AAAA network, so it can't operate as an
ILNPv6 host in that network.

This is my understanding of the exchange, with Xiaohu quoting Ran, in
which Xiaohu was concerned about the second host getting AAAA-NNNN as
part of a DoS attack, rather than be accident:

>> 3) ILNP is carefully engineered to be fully backwards
>>    compatible with IPv[4,6] and also with ARP/IPv6 ND,
>>    and to do so in a way with no changes being required
>>    to any router prior to ILNP deployment.
>
> It seems that your answer to the following question is "YES":
>
>   "If an attacker who steals your identifier accesses a subnet
>    which you would access later during mobility, to avoid your
>    established session from being broken, should your identifier be
>    changed?"
>
> Then my doubt is why not directly use the Nonce value as an
> identifier since the current identifier (i.e., the rightmost 64
> bits of the IPv6 address) can not be ensured to be permanent during
> a session in the above case of mobility.

My guess is that with ILNP or any other Core-Edge Elimination
architecture (AKA "Locator Identifier Separation") what uniquely
identifies a host is its Identifier, and this needs to remain stable
at all times - including with Mobility.  Other hosts which want to
communicate with this one first need to know its Identifier.  Only
then can they look up its one or more currently valid Locators -
which they must have before being able to send it a packet.  A nonce
wouldn't perform this function.  Only a globally unique Identifier
can be used to reliably implement Loc/ID Separation.

>> 4) The need to deploy new IPv6 routers was and
>>    is an barrier to IPv6 deployment.
>>
>> 5) There is widespread agreement that any proposal in
>>    the IRTF Routing RG needs to be backwards compatible
>>    with IP.
>>
>> 6) There is no new operational issue and no new security
>>    issue with ILNP as compared with IPv[4,6].
>
> For Mobile IP, the home address can be ensured stable since the CoA
> can be any of the available addresses within the foreign subnet.
> However, for ILNP, when there is an already allocated IPv6 address
> within the foreign subnet, which is conflicted with the
> to-be-formed (L, I) pair for a mobile ILNP node just attaching the
> above subnet, to be fully backwards compatible with IPv[4,6] and
> also with ARP/IPv6 ND,  the I value (i.e., identifier) would
> have to be changed during a session.
>
> Best wishes,
> Xiaohu

For ILNP to work robustly, I guess it would be necessary to allocate
portions of the Identifier namespace hierarchically to ensure that
there are no disputes or accidental clashes - that each host can have
its own globally unique Identifier.

But how can this work with existing IPv6 networks, where (frequently,
typically or perhaps always) any host can get any address with lower
64 bits of its own choosing, provided no other host has got it already?

I don't think there is a secure, robust, method of making ILNP work
for Mobility.

  - Robin

---

From: Steven Blake <[email-masked]>
Date: Wed, 07 Jul 2010 11:09:05 -0400

On Wed, 2010-07-07 at 21:21 +1000, Robin Whittle wrote:

> which they must have before being able to send it a packet.

This last sentence is false.  Hosts first look up the locator +
identifier for a correspondent via its FQDN.  Hosts already in
communication with the correspondent learn of locator updates via
ICMP, or via DNS.

> A nonce

Mostly agreed.

> its own globally unique Identifier.

Have you read the draft?  Where do you get off complaining about other's
ability to handle details?

As has been documented for years, and has been patiently explained many
times on this list, it is recommended to synthesize a global-scope
EUI-64 ID from one of a host's globally unique hardware IDs, such as an
Ethernet MAC address.

> 64 bits of its own choosing, provided no other host has got it already?

IPv6 hosts typically synthesize global-scope EUI-64 IIDs from an
interface's globally unique Ethernet MAC address.  Less commonly, they
can synthesize a random, local-scope EUI-64 IID (privacy address), or
use CGAs or HBAs.  In all cases, the probability that two hosts on the
same subnet would accidentally configure the same IID (ID in ILNP) is
astronomically low. 

> I don't think there is a secure, robust, method of making ILNP work

A malicious host on subnet X that wanted to execute a DoS attack on a
mobile ILNP host H moving onto subnet X could lookup all of H's IDs via
DNS, and then "steal" them on X before H arrives, causing H to have to
drop all of its on-going TCP/UDP connections when it moves onto X.  This
is due to a known security weakness with IPv6 Neighbor Discovery, which
is why Secure Neighbor Discovery (SeND) was invented.  This same attack
can be executed in IPv6 today (i.e., a malicious host could use this
attack to block a laptop from powering on and joining a wireless LAN, at
least temporarily).

The fact that SeND isn't widely deployed is an indication that this
attack can be detected and mitigated by network management and isn't
seen as a particularly serious risk.

Regards,

// Steve

---

From: Robin Whittle <[email-masked]>
Date: Thu, 08 Jul 2010 01:49:57 +1000

Hi Steven,

> communication with the correspondent learn of locator updates via

OK, but as a brief explanation of my rejection of Xiaohu's nonce
suggestion, it remains true that host A needs to know the Identifier
of host B before it can send a packet to B.  I agree that in ILNP
there are various ways of finding out the Identifier and Locator(s) of B.

>> can be used to reliably implement Loc/ID Separation.

OK - to what extent do you not agree?

Do you agree that a nonce, as suggested by Xiaohu, couldn't do the
same job as an ILNPv6 64 bit Identifier?

Do you think ILNP could be reliable and robust if the Identifiers
used by hosts are not in actual fact globally unique?  If so, please
give some examples.

> ability to handle details?

I read all the material of all the proposals, including ILNP, and
commented on them all on the list.  I haven't read the very latest
versions of the proposals.  My critiques of ILNP and other such
Loc/ID Separation (Core-Edge Elimination) architectures are well known:

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

and are not solvable by the small details which change from one
version of a draft to another.  So forgive me if I haven't read all
of Ran's latest versions end-to-end.

> EUI-64 ID from one of a host's globally unique hardware IDs, such as an

Sure - but that doesn't eliminate the possibility of clashes.

There could be two Ethernet interfaces with the same MAC - and there
will be many devices which have no Ethernet interface or other
component with a MAC.

I still think that hierarchical division of the Identifier space is
the best approach.

> same subnet would accidentally configure the same IID (ID in ILNP) is

Unless there is a DoS attack or some kind of clash due to the
algorithm you suggest not working well, as noted above.

But what if two hosts A and B in separate subnets have the same
Identifier?  This is Locator - Identifier Separation, where the
Identifier has crisp semantics: it identifies a host!

> drop all of its on-going TCP/UDP connections when it moves onto X.  

It would be worse than that.  It would cause H to be unable to use
its connection on network X, due to it being unable to use its one or
more Identifiers - all of which have been "stolen".

I think that what you wrote confirms my critique.

> This

I don't see how this could be the case, since the laptop can always
obtain an address with a lower 64 bits which is not currently used.
However, I haven't thought much about IPv6 Neighbor Discovery for a
while and I have not read about attacks on it.  Can you point to a
mechanism by which the laptop could be prevented from joining the LAN?

> seen as a particularly serious risk.

But how would SeND protect against the DoS attack which Xiaohu Xu and
I are discussing?  SeND can't very well prevent the attacker from
getting 64 bits of lower address which are guaranteed to be different
from all the 64 bit Identifiers used by all the ILNP hosts in the world.

  - Robin

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 7 Jul 2010 09:03:14 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robin Whittle
> Sent: Wednesday, July 07, 2010 8:50 AM
> To: RRG
> Subject: Re: [rrg] ILNPv6 Mobility problem
> 
> Hi Steven,
> 
> You wrote, in part:
> 

The MANET Autoconf community has debated for years about the
guaranteed uniqueness of MAC addresses without conclusion.
The frequently heard argument is that MAC addresses are
configured by vendors, and anything that can be configured
can be misconfigured.

Being an optimist, I am actually a believer in the assumed
uniqueness of MAC addresses. But, there are many pessimists
in the MANET Autoconf world and I'm sure elsewhere as well.

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

---

From: Steven Blake <[email-masked]>
Date: Wed, 07 Jul 2010 12:57:24 -0400

> same job as an ILNPv6 64 bit Identifier?

Yes.  The nonce is only used to (a) indicate the start of a ILNP
session, and (b) secure ICMP messages.

> used by hosts are not in actual fact globally unique?  If so, please

I think they need to be unique on a subnet.  Being globally unique with
high probability makes uniqueness on a subnet easier to achieve.

> of Ran's latest versions end-to-end.

Get real.  The recommendation to use global-scope EUI-64s for IDs has
existed since day one, and has been common practice in IPv6 (for IIDs)
for over a decade.

> will be many devices which have no Ethernet interface or other

Two hosts on the same link with the same MAC address can't communicate
using any protocol (IPv4, IPv6, ILNP, etc.).  Fortunately, the
occurrence of duplicate MACs is extremely rare.

Name one modern device that doesn't have a unique hardware ID that could
be used to form a global-scope EUI-64?

> Identifier has crisp semantics: it identifies a host!

Nothing breaks if two hosts on separate subnets share the same ID, even
if a separate host is communicating simultaneously with both of them.

> more Identifiers - all of which have been "stolen".

Host H can synthesize a new ID.

Nothing prevents a malicious host from sending bogus NAs for any
address/ID on a subnet (just like nothing prevents a malicious IPv4 host
from sending bogus ARP responses).  So in theory a malicious host can
"steal" any possible ID on a subnet.  This vulnerability is not
ILNP-specific.  If you are worried about this, deploy SeND.  Most
network operators don't seem to be terribly worried about this attack.

> mechanism by which the laptop could be prevented from joining the LAN?

If I know (from previous observation, or DNS query) that your laptop
performs SLAAC using an IID formed from its MAC address, I can cause
your laptop's DAD to fail.  So as you said, you will then have to go
form a new IID and try again.  If I am really malicious, I can track you
by your MAC address and cause all of your future DAD attempts to fail.

Nothing ILNP-specific here.

> from all the 64 bit Identifiers used by all the ILNP hosts in the world.

Go read RFCs 3956 & 3972.

Regards,

// Steve

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 7 Jul 2010 11:20:09 -0700

Back when we had a huge bridging network, we had multiple instances of MAC-address collisions in our network. This was one of the reasons why DECnet Phase IV reassigned all MAC addresses (i.e., to ensure that MAC addresses were indeed unique within the DECnet network).

It is possible that this issue is no longer a problem -- I just don't know. However, the gray-hairs among us remember the time when vendor-assigned MAC address uniqueness was a theoretical claim that far-too-often wasn't true in real-life.

>From Fred Templin

> versions of the proposals.  My critiques of ILNP and other such Loc/ID 
> Separation (Core-Edge Elimination) architectures are well known:
> 
> version of a draft to another.  So forgive me if I haven't read all of 
> Ran's latest versions end-to-end.
> 
> 
> > As has been documented for years, and has been patiently explained 
> > many times on this list, it is recommended to synthesize a 
> > global-scope
> > EUI-64 ID from one of a host's globally unique hardware IDs, such as 
> > an Ethernet MAC address.
> 

The MANET Autoconf community has debated for years about the guaranteed uniqueness of MAC addresses without conclusion.
The frequently heard argument is that MAC addresses are configured by vendors, and anything that can be configured can be misconfigured.

Being an optimist, I am actually a believer in the assumed uniqueness of MAC addresses. But, there are many pessimists in the MANET Autoconf world and I'm sure elsewhere as well.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 7 Jul 2010 11:43:36 -0700

Eric,

> From: Fleischman, Eric
> Sent: Wednesday, July 07, 2010 11:20 AM
> To: Templin, Fred L; Robin Whittle; RRG
> Subject: RE: [rrg] ILNPv6 Mobility problem
> 
> 
> Back when we had a huge bridging network, we had multiple instances of MAC-address collisions in our
> network. This was one of the reasons why DECnet Phase IV reassigned all MAC addresses (i.e., to
> ensure that MAC addresses were indeed unique within the DECnet network).
> 
> It is possible that this issue is no longer a problem -- I just don't know. However, the gray-hairs
> among us remember the time when vendor-assigned MAC address uniqueness was a theoretical claim that
> far-too-often wasn't true in real-life.

I think we agree. As an optimist, I wish it weren't so but
wishing doesn't make it a reality. Possibilities for colliding
MAC addresses is exactly why IPv6 links are required to run
duplicate address detection, which is another matter for
enormous debate in MANET Autoconf (see also "optimistic DAD"
RFC4429).

If you think about the process of assigning managed MAC
addresses, there are multiple levels of trust that are
stacked like a house of cards. To assume MAC uniqueness,
one would have to trust all vendors - great and small -
to not make any mistakes in avoiding duplicates. Plus,
each vendor only gets to number its MAC addresses out
of 2^24 possibilities for each of its vendor codes, so
probabilistic uniqueness is not viable. Plus, think
about all of the 3+yr old networking hardware that has
been thrown away in dumps and long forgotten. Each one
of those junked NICs takes with it a MAC address that
can never be reassigned...

Fred

> Being an optimist, I am actually a believer in the assumed uniqueness of MAC addresses. But, there
> are many pessimists in the MANET Autoconf world and I'm sure elsewhere as well.
> 
> Fred

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 08 Jul 2010 09:43:48 +0800

> drop all of its on-going TCP/UDP connections when it moves onto X.  This

Wait a moment, are you sure the mobile ILNP host H would have to drop all of
its on-going TCP/UDP connections when it moves onto X. If so, it seems much
distinct from the answers from Tony and Ran for the same above question.

> attack to block a laptop from powering on and joining a wireless LAN, at

I think you should bring the Mobile IP, rather than the non-mobile IP into
comparison since both Mobile IP and ILNP are intended to support host
mobility.

Assume a mobile IP host H' encounters the same condition as the above mobile
ILNP host H, H' could use any available IP address on subnet X as its CoA
without dropping all of its on-going TCP/UDP connections since the CoA plays
the PURE role of locator. That is to say, the sessions are bound to the HoA,
rather than the CoA. 

Best wishes,
Xiaohu

---

From: Tony Li <[email-masked]>
Date: Wed, 7 Jul 2010 19:01:12 -0700

> the PURE role of locator. That is to say, the sessions are bound to the HoA,

If the malicious host chooses to attack the CoA, then the attacks that Steve outlines above can be applied as well.  Or, the malicious host can get even more primitive and simply duplicate any MAC that it sees on its subnet.

The fact of the matter is that if the link layer provides no authentication, then its not an appropriate media for secure mobility.  Ergo, sites that are trying to supply true mobility should provide some form of link layer authentication (see 802.1x and better).

Most link layers that we associate with real mobility (i.e., cell protocols) do provide link layer authentication for precisely this reason.

Note that this is wholly independent of ILNP and mostly also independent of IP.  Mobile DECnet would have the same issues.  ;-)

Tony

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 08 Jul 2010 10:26:01 +0800

> -----邮件原件-----
> 发件人: Tony Li [mailto:[email-masked]]
> 发送时间: 2010年7月8日 10:01
> 收件人: Xu Xiaohu
> 抄送: 'Steven Blake'; 'Robin Whittle'; 'RRG'
> 主题: Re: [rrg] ILNPv6 Mobility problem
> 
> 

> If the malicious host chooses to attack the CoA, then the attacks that
Steve
> outlines above can be applied as well.  Or, the malicious host can get
even

The default gateway router of that subnet could simply deem the first
accessed host (IP_x, MAC_y) as legal while the second host (IP_x, MAC_z) as
illegal. Thus the malicious host could not grab the IP address which has
been used by the legal host. 

> more primitive and simply duplicate any MAC that it sees on its subnet.

Similarly, the switch could simply deem the first accessed host with MAC_y
is legal and the second host with the same MAC is illegal.

Best wishes,
Xiaohu

> The fact of the matter is that if the link layer provides no
authentication,
> then its not an appropriate media for secure mobility.  Ergo, sites that
are
> trying to supply true mobility should provide some form of link layer
> authentication (see 802.1x and better).
> 
> Most link layers that we associate with real mobility (i.e., cell
protocols)
> do provide link layer authentication for precisely this reason.
> 
> Note that this is wholly independent of ILNP and mostly also independent
of
> IP.  Mobile DECnet would have the same issues.  ;-)
> 
> Tony

---

From: Fred Baker <[email-masked]>
Date: Wed, 7 Jul 2010 19:35:03 -0700

This has a problem if the EID is presumed to have continuity as the locator changes. I suspect that what you're really asking for is that if N systems are using the same IP layer address (improbable but not impossible), the router forward packets headed for it to each MAC Addresses. All except the first one would be forced to select locally-assigned MAC Address while in that subnet.

Not sure I want to go there, but the alternatives are:
  - ask the mobile system to change its EID in flight, contrary to ILNP assumptions, or
  - lose connectivity to N-1 of the N systems with the same address

I suppose there is in fact one other possibility. The router could <violent handwaving> somehow come up with another subnet locator and put the new device into the new subnet. That would allow the systems to share a MAC address at the MAC layer and enable the end statins to differentiate between their datagrams.

> is legal and the second host with the same MAC is illegal.

http://www.ipinc.net/IPv4.GIF

---

From: Robin Whittle <[email-masked]>
Date: Thu, 08 Jul 2010 13:59:36 +1000

Short version:  I think Steven Blake and Tony Li have not
                successfully responded to this critique.  I reply
                to them both.

                Steve also seems to claim that there is a robust
                method of every host now - and implicitly in the
                future - developing a unique 64 bit address purely
                based on its own hardware configuration.  I will
                pursue that in a separate thread.

Hi Steven,

> session, and (b) secure ICMP messages.

OK - we agree on this.

> high probability makes uniqueness on a subnet easier to achieve.

This doesn't alter the nature of the problem Xiaohu and I are
concerned about.  It seems Fred Templin and Eric Fleischman agree
with this critique, since they have added notes to this thread about
MAC address uniqueness, without disagreeing with the critique.

The latest I-D:

  http://tools.ietf.org/html/draft-rja-ilnp-intro-05

states that the Identifier is recommended to be globally unique.  If
a host's Identifier is not globally unique, but is only unique on a
particular /64, then they should not be used on any other /64 without
first checking that in the second /64, there is not already a host
using these same Identifier bits in its lower 64 bits:

   Locally-unique Identifiers MUST be unique within the context
   of their Locators.  The existing mechanisms of the IPv4 Address
   Resolution Protocol [RFC 826] and IPv6 Neighbour Discovery
   Protocol [RFC 4861] automatically enforce this constraint.
   Locally-unique Identifiers MUST NOT be used with other Locators
   without first ensuring uniqueness in the context of those other
   Locators (e.g. by using IPv6 Neighbour Discovery's Duplicate
   Address Detection mechanism).

It seems that ILNPv6 can't do Mobility if the mobile host's
Identifier is only known to be unique on some particular /64 AAAA -
because as a mobile host, it may soon need to use an access network
in /64 BBBB and find that it can't get an IP address there with its
current Identifier in the lower 64 bits.

Our critique goes beyond whether the Identifier NNNN is globally
unique or not.  Even if it is globally unique, an attacker can easily
find it via DNS and have their host in /64 BBBB gain the address
BBBB-NNNN.  Then when our mobile host - whose Identifier NNNN is fine
on /64 AAAA, because only this host has the IP address AAAA-NNNN -
tries to continue its ILNP sessions when using an access network in
/64 BBBB, it can't do so, because the IP address it needs (BBBB-NNNN)
is already in use.

ILNP mobility involves the mobile host telling other hosts that its
Locator(s) have changed.  There is no way of continuing user sessions
with another Identifier, as far as I know.

   With ILNP, network mobility (as well as node mobility)
   is considered a special case of multihoming.  That is,
   when a network moves, it uses a new Locator value for all
   of its communications sessions.  So, the same mechanism,
   using a new or additional Locator value, also supports
   network mobility.

This is crisp and clear.  The node needs to retain its original
Identifier in order to be able to successfully achieve mobility -
implicitly with continuing higher level sessions.

> Get real.  

I don't understand how this sentence or the next is relevant to me
defending myself against your complaint that I haven't read every
part of Ran's latest versions.

If you want to give me a hard time about lack of attention to detail,
you might like to demonstrate your own attention to it by responding to:

What are your list of goals and non-goals?

Why should ILNP or any other CEE architecture be chosen when it
forces all hosts to do more work and generally will add delays and
extra packets for all Internet communications?

How can any CEE architecture overcome the barriers to widespread
voluntary adoption mentioned in the above and detailed here?:

   http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

> The recommendation to use global-scope EUI-64s for IDs has

I know.  This doesn't affect the critique we are discussing.

> occurrence of duplicate MACs is extremely rare.

Eric and Fred wrote that duplicate MAC addresses are common enough to
be considered a serious problem by people who have studied these
matters more than I have.  Unless I see substantial evidence to the
contrary, I will share their concern.

But this doesn't affect the critique.

> be used to form a global-scope EUI-64?

This is not the primary subject of this thread - since Xiaohu and I
are discussing an attack.  Now you are expanding the discussion to
encompass the question of how the ILNPv6 (ILNPv4 too?) stack would
generate a globally unique 64 bit Identifier without reference to
anything outside its own physical device.

I will discuss this in a separate thread.

> if a separate host is communicating simultaneously with both of them.

More on this below.

> Host H can synthesize a new ID.

Then this would mean its sessions with other hosts could not be
continued.  So our critique is valid.

> ILNP-specific.  

Only ILNP uses the lower 64 bits as an Identifier, which should have
global scope - as you seem to acknowledge by your interest in arguing
that generating unique Identifiers from device hardware is practical.

Any host on a physical Ethernet or in an IP subnet can make a mess of
that Ethernet or subnet, subject to various mechanisms in the switch
or router.

The critique is that a host on any kind of physical network, where it
is able to request and obtain a global unicast IP address with a
specific set of lower 64 bits, can do so, and be totally compliant
with IPv6 protocols - and still achieve the DoS attack Xiaohu and I
are writing about.

This means that ILNP, for mobility at least, is not backwards
compatible with IPv6.

Hosts need to be able to request and gain an IP address with a
specific set of 64 lower bits in order to be able to implement ILNPv6.

> If you are worried about this, deploy SeND.

I am not sure how SeND prevents the attack.  If an attacker knows the
ILNP ID of a mobile host it wants to DoS, before that host gets an
address on a particular /64, and if it can request and gain an IP
address with a lower 64 bits of its choosing, then it can do so and
therefore prevent the mobile host from using its ILNP Identifier when
it connects to this /64.

I assume that any IPv6 host can request an IP address with a specific
lower 64 bits - otherwise, how could the ILNP mobile host get the IP
address which has its pre-existing ILNP Identifier as the lower 64 bits?

The attack doesn't depend on any lack of security in the /64 network
- just the ability of the attacker to know the ILNP Identifier of the
one or more hosts it is targeting.  It can easily find this out by DNS.

> Most network operators don't seem to be terribly worried about
> this attack.

But we are discussing a scenario which doesn't occur today - a host
turning up in a /64 and requiring a particular IP address within that
/64, so it can continue its sessions and therefore be successfully
Mobile.

> by your MAC address and cause all of your future DAD attempts to fail.

Maybe so - I don't know enough about it.  Presumably SeND fixes this.

But AFAIK, SeND wouldn't prevent the attack we are discussing.

> Nothing ILNP-specific here.

The attack we are discussing is ILNP-specific.

> Go read RFCs 3956 & 3972.

I think you are attempting distract me with a lengthy reading
assignment.  These seem pertinent:

  Neighbor Discovery for IP Version 6 (IPv6)
  http://tools.ietf.org/html/rfc2461

  SEcure Neighbor Discovery (SEND)
  http://tools.ietf.org/html/rfc3971

but I don't see how this one is relevant:

  Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast
  Address
  http://tools.ietf.org/html/rfc3956

Even if you and Ran can successfully counter this critique, I am
still completely opposed to ILNP or any other CEE (Locator /
Identifier Separation) architecture.  So I don't want to spend a lot
of time on this critique.  I raised it in its own thread because I
was concerned that Xiaohu's message would be forgotten.

Hi Tony,

You wrote:

> If the malicious host chooses to attack the CoA, then the attacks
> that Steve outlines above can be applied as well.  Or, the
> malicious host can get even more primitive and simply duplicate any
> MAC that it sees on its subnet.

But how would the attacker know the mobile host's MAC address in time
to steal it - before the mobile host tries to connect to the BBBB /64?

I understand that there are typically mechanisms which prevent a
second host which tries to use the BBBB-NNNN address from disrupting
the first which has this address.

Steve's response to this critique seems to be that the mobile node
would simply get a new Identifier.  But I argue above that this
proves the validity of the critique - since this would not allow the
continuity of higher level sessions.

> authentication, then its not an appropriate media for secure
> mobility.  Ergo, sites that are trying to supply true mobility
> should provide some form of link layer authentication (see 802.1x
> and better).

I don't see how SeND would counter the attack Xiaohu proposed.

> protocols) do provide link layer authentication for precisely this
> reason.
>
> Note that this is wholly independent of ILNP and mostly also
> independent of IP.  Mobile DECnet would have the same issues.  ;-)

I don't see anything in what you wrote which disproves the validity
of this critique.

 - Robin

---

From: Tony Li <[email-masked]>
Date: Wed, 7 Jul 2010 22:33:45 -0700

> been used by the legal host. 

802.1x prevents this.

> is legal and the second host with the same MAC is illegal.

And this.

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 7 Jul 2010 22:39:32 -0700

>                successfully responded to this critique.  I reply

Since you're continuing to be unreasonable, I choose not to reply.

Tony

---

From: Robin Whittle <[email-masked]>
Date: Thu, 08 Jul 2010 16:25:17 +1000

Hi Tony,

> Since you're continuing to be unreasonable, I choose not to reply.

Xiaohu made a critique of the ability of ILNP to work as planned with
mobility in a way which is compatible with IPv6.  I supported his
critique and tried to explain it in a way which complements his
explanation.  Steve disagreed with me, but I can't see how he
disproved the critique.  Fred Templin and Eric Fleischman seem to
agree with the critique.

You have recommended ILNP, including its proposed Mobility aspect, be
 developed by the IETF as the solution to the routing and addressing
scaling problem.

You haven't written anything which seems to counter my critique.

In what way was my message unreasonable?

  - Robin

---

From: Roland Bless <[email-masked]>
Date: Thu, 08 Jul 2010 13:54:40 +0200

Hi Steven,

On 07.07.2010 18:57, Steven Blake wrote
> high probability makes uniqueness on a subnet easier to achieve.

I don't think that ILNP will work out of the box if two
nodes have the same ID but are located in different subnets.
The transport cannot distinguish whether it's a connection
to itself or to the other remote system if it only operates on the ID.
I think that the problem of conflicting IDs but different Locators
is probably solvable, but I haven't seen any proposal for this so far.

> be used to form a global-scope EUI-64?

Hmm, when considering the increasing use of virtual hosts, we
may get in trouble here: virtual hosts probably don't have a unique
hardware ID and usually generate a MAC address (or multiple ones
in case of several virtual interfaces) at installation time.

> if a separate host is communicating simultaneously with both of them.

As long as you have the Locator in addition to the ID available,
that's ok, but as far as I understood, the transport layer only
uses I. So further demultiplexing will only work if the transport
layer considers L:I together. Is this the case somewhere, e.g., when
passing packets to the network layer?

Regards,
 Roland

---

From: Tony Li <[email-masked]>
Date: Thu, 8 Jul 2010 08:46:37 -0700

Hi Roland,

> is probably solvable, but I haven't seen any proposal for this so far.

As I just mentioned, this is easy if they are locally generated IDs.  There are specific bit patterns that indicate a locally generated ID and the transport will need to demux on the full address in this case.

As with any locally generated ID, mobility to arbitrary other locators cannot be supported.

> in case of several virtual interfaces) at installation time.

If we take the example of VMware, a virtual host will end up with a pseudo-random address in 00:0c:29, and can create collisions with other VMware installations, in which case you have to set the MAC address locally.  Pretty clearly, folks are abusing basic Ethernet and ILNP cannot fix that.

Using a locally generated MAC would be the right approach here.

> passing packets to the network layer?

The transport will need to use L:I for locally unique IDs.

Tony

---

From: Tony Li <[email-masked]>
Date: Thu, 8 Jul 2010 13:42:51 -0700

> Using a locally generated MAC would be the right approach here.

It occurs to me that VMware is actually very good about crafting per-host licensing.  The truly correct solution here is to then associate a pool of MAC addresses with with each VMware license.  This fixes VM mobility in general and as a side effect, fixes any issues with ILNP.  ;-)

Tony

---

From: Steven Blake <[email-masked]>
Date: Fri, 09 Jul 2010 00:28:26 -0400

> is probably solvable, but I haven't seen any proposal for this so far.

No one ever said explictly that you cannot use locators as part of the
socket demux (directly, or indirectly, by mapping remote locator
+identifier to a correspondent cache entry whose internal index is used
in socket demux).

Locators aren't used in the transport checksum.

I previously sent Ran a comment to clarify this, FWIW.

> in case of several virtual interfaces) at installation time.

VMs usually have their MAC addresses assigned centrally by a Virtual
Machine Manager.  VMware vCenter does this out of a VMware's own OUI
pool.

If you are setting up VMs by hand, you have got to be careful, or you
will break bridging!

> passing packets to the network layer?

Basically correct.  The definition of the boundary between ILNP network
layer and transport layer is left deliberately vague, because the are
multiple viable implementation alternatives.  For example, Christian
Vogt's name-based sockets could be used within transport, and the name
mapped to some internal correspondent cache entry at the
transport/network-layer boundary.

Regards,

// Steve

---

From: Steven Blake <[email-masked]>
Date: Fri, 09 Jul 2010 01:21:35 -0400

> MAC address uniqueness, without disagreeing with the critique.

They said that MAC address collisions are not unheard of.  But MAC
address collisions break Ethernet bridging and everything that runs on
top of it, so when they occur they are a severity 1 problem that needs
to be fixed ASAP.  This is not a specific issue for ILNP.

> current Identifier in the lower 64 bits.

One can use the same reasoning to argue that a laptop cannot perform
mobility because it cannot be sure that its 802.11 MAC address is unique
on every possible WiFi network it might roam to.  One can attack a host
by stealing its MAC address just as effectively as by stealing its ILNP
ID; most OSes don't have code to continually try new MAC addresses in
case of collisions.

> /64 BBBB, it can't do so, because the IP address it needs (BBBB-NNNN)

I acknowledge that this attack exists.  But if the link-layer is
unauthenticated, the same attacker can launch much worse attacks on any
node running plain IPv4 or IPv6.

There are mechanisms that you can implement in access switches/APs to
mitigate this, such as filtering NAs and binding MACs to global-scope
IID/IDs, etc.

> with another Identifier, as far as I know.

Correct for TCP/UDP, not correct for SCTP.  If multi-path TCP takes off,
then this problem could probably be addressed.

> implicitly with continuing higher level sessions.

See above.

> part of Ran's latest versions.

I didn't accuse you of that.  I accussed you of missing one of the most
basic points (using global-scope EUI-64s for IDs is pretty basic).  You
do understand that MAC addresses are allocated hierarchically, right?

> What are your list of goals and non-goals?

At the moment, to try to keep you from spreading false information.

>    http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

That is all your supposition.  Fine.  We agree to differ.
People will choose to implement what they choose to implement, and
deploy what they choose to deploy.  What ever gets deployed will be a
subset of whatever gets implemented.  Are you writing code?

I'm not interested in being a partisan in any debate about the
deployability of any scheme.  It's pointless without running code.

> I know.  This doesn't affect the critique we are discussing.

Whatever.

> continued.  So our critique is valid.

True enough.

> that generating unique Identifiers from device hardware is practical.

Are you aware that this is how IPv6 has worked (to generate IIDs) since
around 1995?

> This means that ILNP, for mobility at least, is not backwards

That doesn't follow.  IPv6 doesn't support network mobility at all,
unless you deploy MIPv6.  ILNP is not backwards compatible with MIPv6,
if that is your concern.

> therefore prevent the mobile host from using its ILNP Identifier when

It can't (strictly speaking, it can't prove that it owns that address
via possession of a public key).  That is the whole point of CGAs.

> But AFAIK, SeND wouldn't prevent the attack we are discussing.

You are misinformed.

>   http://tools.ietf.org/html/rfc2461

You'll be wanting RFC4861.

>   http://tools.ietf.org/html/rfc3956

Oops, my bad: I meant RFC3756.

http://tools.ietf.org/html/rfc3756

> was concerned that Xiaohu's message would be forgotten.

You're opposition has been duly noted.

Regards,

// Steve

---

From: Robin Whittle <[email-masked]>
Date: Fri, 09 Jul 2010 16:44:24 +1000

Short version:    Steven acknowledges the validity of the attack
                  which Xiaohu Xu proposed.

                  He seems to think that SeND (Secure Neighbour
                  Discovery) can protect against it, but as far as I
                  can see, neither SeND nor any other mechanism can
                  protect against it.

                  If ILNP Identifiers were hierarchically assigned,
                  then there would be a way of looking them up in
                  the DNS.  As far as I know, such lookups are not
                  possible.  Therefore, there is no way of preventing
                  an attacker gaining an IP address GGGG-VVVV in the
                  GGGG /64, where VVVV is the Identifier of the
                  victim ILNP host.  This attack prevents the victim
                  host from using the mobility aspect of ILNP to
                  operate from an access network which uses the GGGG
                  /64.

Hi Steven,

> to be fixed ASAP.  This is not a specific issue for ILNP.

I understand this - I was asking you about the critique, about the
attack Xiaohu Xu proposed.  Below, you acknowledge it is valid.

The critique has nothing whatsoever to do with two hosts in an
Ethernet having the same MAC address.

> ID; most OSes don't have code to continually try new MAC addresses in

The attack Xiaohu suggested doesn't involve the attacker snooping a
MAC address from a LAN.  It works from the victim's Identifier, which
the attacker can easily find out via ILNP's extensions to DNS, by
looking up the victim's FQDN.

The attack has nothing to do with LAN or any other L2 technologies.
It would work if the attacker had a cellphone on a 3G network and the
victim's cellphone then tried to get the IP address it needs on that
network, and so presumably in the same /64.  As far as the network is
concerned, the attacker's cellphone is perfectly entitled to request
its IP address, which happens to have the lower 64 bits equal to the
Identifier of the victim's ILNP cellphone.

As far as I can see, the only way around this attack is a change to
IPv6 networks - to make them all check any request for an IP address
to make sure that it comes from a device which is authorised to
request it.  That would be onerous enough, especially before IP
communications were fully up, if all hosts were ILNP aware - and if
this checking were possible.  Below I argue that such security
measures are not possible with ILNP as currently described.

The attack works just fine with the attacker's host being an ordinary
IPv6 host which for some reason wants a particular IP address.

> I acknowledge that this attack exists.  

OK - thanks.

> But if the link-layer is

Maybe so, but that only works on a LAN, and there will be billions of
mobile hosts in the form of 3G cellphones and the like.  As far as I
know, those devices are not linking to their access networks via MAC
addresses in an Ethernet environment.  So I suspect that these hosts
are not subject to link layer attacks, as you suggest, or at least
not the same link layer attacks.  Considering the frightening size of
the GSM documentation (a metre of shelf space when I saw it in the
early 1990s) I guess that the 3G UMTS stuff is even more voluminous
and has much more robust security arrangements than Ethernet.

The nature of this attack is that it covers an entire /64 and
requires knowledge only of the Identifier, which is public knowledge.

> mitigate this, such as filtering NAs and binding MACs to global-scope

Yes, but this doesn't affect the attack, or apply to 3G access
networks, AFAIK.

> then this problem could probably be addressed.

OK.

>> implicitly with continuing higher level sessions.

OK.

> do understand that MAC addresses are allocated hierarchically, right?

I know they are allocated hierarchically.

> At the moment, to try to keep you from spreading false information.

Such as?

I was asking about the list of goals and perhaps non-goals for ILNP?

For the list of goals I assume, see these headings within the above
message:

 17.2.3 Portability, Multihoming and inbound Traffic Engineering (TE)
 17.2.3 IPv4 Address Exhaustion
 17.2.4 Global Mobility
 17.2.5 Security and robustness

> That is all your supposition.  Fine.  We agree to differ.

I have tried to update this page with any comments - but so far
no-one has pointed out what is fundamentally wrong with this.

Since you disagree with this attempt to list the constraints, I think
it would be helpful if you discuss on the RRG list what is wrong with
my attempt to list these constraints.

> subset of whatever gets implemented.  

Sure, but ILNP or any other CEE architecture faces such enormous
barriers to widespread voluntary adoption, that I think they are all
non-starters.

> Are you writing code?

Not yet.

> deployability of any scheme.  It's pointless without running code.

What does "partisan" mean in this context?  We are all arguing for
what we believe is best for the Net.

I think there is no practical purpose in writing code for an
architecture which has no hope of being sufficiently widely adopted.

A more fundamental critique of ILNP and other CEE architectures is
the extra delays they cause in communications, the extra burden they
place on all hosts, and the extra packets and/or longer packets they
involve:

  http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html
  (Dae Young Kim wrote in support of this: msg07074.)

>> I know.  This doesn't affect the critique we are discussing.

OK.

(Lots of quotes deleted.)

>> continued.  So our critique is valid.

OK.

> Are you aware that this is how IPv6 has worked (to generate IIDs) since

Sure - but this attack works on publicly available information about
the victim host, before the victim host tried to connect to the new
access network.  It covers an entire /64, no matter what the L2
technology is - and prevents ILNP from working for the victim host in
that /64.  So it is unlike any LAN-based attack.

> unless you deploy MIPv6.  ILNP is not backwards compatible with MIPv6,

What I meant was that if this attack is regarded as serious enough to
be a "show-stopper", then ILNP's mobility is not backwards compatible
with IPv6 networks - since there is no obvious workaround.

> via possession of a public key).  That is the whole point of CGAs.

Yes - so SeND does not prevent the attack Xiaohu Xu proposed.

>> But AFAIK, SeND wouldn't prevent the attack we are discussing.

How so?

Whether it is SeND or some other system, here is what would have to
happen in order to prevent the attack.

  Attacker's host connects to, or is already connected to an access
  network in /64 GGGG.  It wants an IP address GGGG-VVVV where
  VVVV is the Identifier of the victim.  (I assume this is a globally
  unique Identifier, since if the victim host only had a locally
  unique Identifier, it wouldn't expect to be able to connect to the
  AAAA access network.)

  SeND etc. needs to somehow look up this Identifier to see if it
  was being used by any ILNP host.  I can't see how this could be
  done.  The host could provide a FQDN which when looked up by
  SeND etc., returned an ID record equal to VVVV - but this is not
  a mechanism by which SeND etc. could reliably verify whether
  VVVV was being used as an ILNP identifier.

  I understand that ILNP Identifiers are not hierarchically assigned,
  so there is no possibility of a DNS lookup of VVVV to return some
  information about a host which might be using it as an Identifier.

  Even if this could somehow be done, then SeND etc. would need to
  retrieve some certificate, crypto key or whatever, or communicate
  with some distant server, and the do some kind of exchange with the
  host by which the host could prove it was authorised to use this
  VVVV value as its Identifier.

  This would be inordinately expensive and would require central
  coordination of ILNP Identifiers, perhaps with PKI etc. etc.
  It would surely be too slow and expensive for mobile use.

  Such a process would not be backwards compatible with IPv6 hosts.
  At present, a plain IPv6 host could ask for GGGG-VVVV and it should
  be able to get it - unless the SeND etc. system can somehow
  determine that VVVV is an ILNP identifier.  But without
  hierarchical assignment of ILNP Identifiers, this is not possible.

> You'll be wanting RFC4861.

Yes - thanks.

> http://tools.ietf.org/html/rfc3756

OK: "IPv6 Neighbor Discovery (ND) Trust Models and Threats".

BTW, I think all Ran's references to "RFC 4219" are erroneous and
should be to RFC 4291.

> You're opposition has been duly noted.

OK.  I am not convinced that reading these RFCs would affect my
understanding of the critique Xiaohu raised - and I need to
concentrate on other things, including reading the latest IRON I-D.

  - Robin

---

From: Robin Whittle <[email-masked]>
Date: Fri, 09 Jul 2010 17:17:56 +1000

Short version:  I was wrong to assume there was no way of looking
                up an ILNP Identifier to get a FQDN and/or
                Locator(s).

                The lookup is in principle possible with a Locator.

                However, this assumes the /64 network whose Locator
                this is has a fully functioning, securely and
                rapidly updated reverse DNS lookup system.

Further to my recent message, in which I assumed that it was not
possible to look up an Identifier to get a FQDN and or Locator(s), I
just read in draft-rja-ilnp-intro-05:

  Reverse DNS lookups, to find a node's Fully Qualified Domain Name
  from the combination of a Locator and related Identifier value,
  can be performed as at present.

However, this involves the reverse DNS of the /64 network being
securely updated with a FQDN.  I am not sure how this could be done
securely or without a lot of trouble.

To make SeND or similar securely able to determine whether a lower
order 64 bit value such as VVVV was in fact an ILNP identifier, it
would be necessary for the requesting host to also provide a set of
upper 64 bits UUUU, and then for the SeND etc. system to do a reverse
DNS lookup on that.  So the UUUU must be a locator in a previous
access network which has maintained its reverse DNS in some way.

Then the SeND etc. system could look up the FQDN and securely
determine whether the results included an ID record containing VVVV.

This would be a start to forcing the host to prove it had the
credentials to use this VVVV as an ILNP identifier, which would
overcome (in an expensive and probably slow fashion) one barrier to
securely checking hosts requests for a given low order set of bits in
its IP address.

However, I mentioned other barriers to this being possible - and it
would involve altering the behaviour of routers in IPv6 networks in
order to enable them to be usable for ILNP mobility whilst also being
immune to the attack proposed by Xiaohu Xu.

  - Robin

---

From: Roland Bless <[email-masked]>
Date: Fri, 09 Jul 2010 09:46:26 +0200

Hi Tony,

Am 08.07.2010 17:46, schrieb Tony Li:
>> I don't think that ILNP will work out of the box if two nodes have
>> the same ID but are located in different subnets. The transport
>> cannot distinguish whether it's a connection to itself or to the
>> other remote system if it only operates on the ID. I think that the
>> problem of conflicting IDs but different Locators is probably
>> solvable, but I haven't seen any proposal for this so far.
> 
> 
> As I just mentioned, this is easy if they are locally generated IDs.
> There are specific bit patterns that indicate a locally generated ID
> and the transport will need to demux on the full address in this
> case.
> 

Ok, thanks for clarification.

>> Hmm, when considering the increasing use of virtual hosts, we may
>> get in trouble here: virtual hosts probably don't have a unique 
>> hardware ID and usually generate a MAC address (or multiple ones in
>> case of several virtual interfaces) at installation time.
> 
> 
> If we take the example of VMware, a virtual host will end up with a
> pseudo-random address in 00:0c:29, and can create collisions with
> other VMware installations, in which case you have to set the MAC
> address locally.  Pretty clearly, folks are abusing basic Ethernet
> and ILNP cannot fix that.

Yes, but my point was that we probably cannot assume
that every "device" in the Internet has a unique hardware ID,
because we may have many virtual hosts in the future.
How "smart" individual vendor's solutions are is IHMO out of scope here.

>> layer considers L:I together. Is this the case somewhere, e.g.,
>> when passing packets to the network layer?
> 
> 

Ok. Moreover, I think that using the IPv6 privacy extensions in
combination with ILNP is actually quite useful, i.e., the ID
is fine for servers, but for end-users it's probably a good idea
to have several IDs an change them from time to time.

 Roland

---

From: Tony Li <[email-masked]>
Date: Fri, 9 Jul 2010 01:10:03 -0700

Hi Roland,

> How "smart" individual vendor's solutions are is IHMO out of scope here.

I respectfully disagree.  All physical devices have had a MAC address (or equivalent) for quite some time now.  Even the virtual devices are emulating Ethernet, so for all practical purposes, EUI-48 and EUI-64 are a clear and distinct identifier space.  

The virtualization vendors need to be a little bit more pro-active in MAC address allocations, independent of everything else, and then IPv6 is good to go.

> to have several IDs an change them from time to time.

Some people feel that that's appropriate.  That's fine.  I'm more of a mobility junkie myself.

Tony

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 9 Jul 2010 10:40:17 +0200 (CEST)

On Fri, 9 Jul 2010, Tony Li wrote:

> I respectfully disagree.  All physical devices have had a MAC address 
> (or equivalent) for quite some time now.  Even the virtual devices are 
> emulating Ethernet, so for all practical purposes, EUI-48 and EUI-64 are 
> a clear and distinct identifier space.

... apart from D-Link who shipped residential NAT routers with identical 
MAC addresses and their customer support claimed to customers that "their 
devices were not unique enough" and wanted the customer to use their 
"clone PC address"-feature in the web interface, which let the NAT router 
copy the PC MAC address to use on the WAN interface, so again it wasn't 
unique.

In the real world, MAC addresses are not unique, they're just unique most 
of the time. Any scheme that depends on unique MAC addresses need to 
gracefully handle when they're not.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Klaas Wierenga <[email-masked]>
Date: Fri, 09 Jul 2010 10:45:53 +0200

On 7/9/10 10:10 AM, Tony Li wrote:

Tony,

> Some people feel that that's appropriate.  That's fine.  I'm more of a mobility junkie myself.

hmm, I am also a 'mobility junkie' but that is precisely why I am 
concerned about a globally unique, persistent, hard to change 
identifier. Thinking out loud, how about instead of using the privacy 
extensions make it possible (for an end user) to perform some kind of 
one-way function on the EUI-64 address that can not be related to the 
original hardware address. It would then be up to the user to not apply 
this function, apply it once or apply it many times, whatever the 
trade-off between location privacy and session persistence of the user 
duictates.

Klaas

---

From: Tony Li <[email-masked]>
Date: Fri, 9 Jul 2010 09:40:18 -0700

> In the real world, MAC addresses are not unique, they're just unique most of the time. Any scheme that depends on unique MAC addresses need to gracefully handle when they're not.

In the real world, there are no perfect solutions.  Why is everyone insistent on an architecture that solves all problems, even in the face of equipment that clearly does NOT follow existing architectures?  

Tony

---

From: Tony Li <[email-masked]>
Date: Fri, 9 Jul 2010 09:43:25 -0700

> hmm, I am also a 'mobility junkie' but that is precisely why I am concerned about a globally unique, persistent, hard to change identifier. Thinking out loud, how about instead of using the privacy extensions make it possible (for an end user) to perform some kind of one-way function on the EUI-64 address that can not be related to the original hardware address. It would then be up to the user to not apply this function, apply it once or apply it many times, whatever the trade-off between location privacy and session persistence of the user dictates.

That's a perfectly fine way to generate (but not validate) a locally unique identifier.  However, if you want your mobility with session continuity, you're going to have to exchange that with correspondents.  As soon as you do, you've lost privacy.

Simply put: privacy is mutually exclusive with session continuity.   Pick one.  Either is fine, but you can't have both.  ;-)

Tony

---

From: Robin Whittle <[email-masked]>
Date: Sat, 10 Jul 2010 20:22:54 +1000

Short version:  It would be better if there were no locally unique
                Identifiers and if Identifiers were guaranteed to be
                globally unique - ideally via being hierarchically
                allocated.

                Still, when it comes to Mobility, it seems that
                Xu Xiaohu's proposed attack, (which I dub "Identifier
                squatting") means an ILNP Identifier can't be a first
                class citizen.

                Only perhaps with hierarchically assigned Identifiers
                and with very expensive, global, cryptographic,
                measures to control which lower 64 bits every host
                gets (to be retrofitted to any IPv6 network an ILNP
                host might want to roam to) might it be possible to
                make ILNP Identifiers "first class".  I think this
                would probably be too onerous and slow to support
                Mobility with a VoIP conversation in progress.

Hi Tony,

In "Re: [rrg] ILNPv6 Mobility problem" (msg07096 - and BTW, each
paragraph is a very long line in the archives) you wrote:

> In the real world, there are no perfect solutions.  Why is
> everyone insistent on an architecture that solves all problems,
> even in the face of equipment that clearly does NOT follow
> existing architectures?

Further to Toni Stoev's message, one reason a person might expect an
architecture such as ILNP not to have basic flaws, such as I think
Xiaohu Xu pointed out, is we can think of other architectures with
fewer flaws.  Another reason is that you and a few others are making
great claims for ILNP as being superior to any other architecture.
So it had better be good.

You wrote:

  http://tools.ietf.org/html/draft-irtf-rrg-recommendation-08

   These changes should be cleanly integrated, first-class
   citizens within the architecture.  That is to say that any new
   elements that are integrated into the architecture should be
   fundamental primitives, on par with the other existing legacy
   primitives in the architecture, that interact naturally and
   logically when in combination with other elements of the
   architecture.

If ILNP continues to include an option for locally unique
Identifiers, then these will always be second-rate things compared to
a proper globally unique Identifier.  As I wrote:

   ILNP Identifier and Locator semantics are muddled and !crisp
   http://www.ietf.org/mail-archive/web/rrg/current/msg07091.html

the inclusion of locally unique Identifiers means:

      the true semantics of Identifier and Locator are muddled
      and not at all crisp.  Likewise, the ILNP functionality in
      the stack will be much more complex.

I think that it would be no great loss to get rid of these locally
unique Identifiers.

Likewise, Identifiers which are not guaranteed to be globally unique
- as is currently the case with ILNP's lack of hierarchical
assignment of Identifier space - means these are not first-class
citizens.

This too is easily fixed - implement a hierarchical assignment system
like IP addresses today.

Then you could add a DNS system which is indexed on Identifier - to
return an FQDN (or more than one?) and one or more Locators.  That
DNS system would be run by organizations which are responsible for
each subset of the Identifier namespace, just as is the case for
reverse DNS of IP addresses today.

As ILNP is today, I understand you can't look up an Identifier unless
you have a Locator which belongs with it, and only if the network
whose Locator this is implements its own reverse DNS, which has been
securely and promptly updated.  Even then, you can't trust the
results - because there is no guarantee that this network was
correctly instructed.  So you would have to get the resulting FQDN
and do the existing secure ILNP DNS lookup before you could get the
one or more Locators which are genuinely in use with this Identifier.
 With hierarchically assigned Identifiers, the reverse DNS would be
authoritative - so only a single lookup would be required.

I don't understand why you, Ran and I guess others want to build a
host's Identifier from a hardware ID in the device itself.  Saving on
administrative structures I guess.

You referred - "equipment that clearly does NOT follow existing
architectures" - to Ethernet interfaces with MAC addresses which were
not globally unique.  This is only causes a clash, and therefore a
problem, if two devices with the same MAC are connected to the same
Ethernet.

Extending the reach of potentially duplicate MAC addresses and other
forms of hardware identification numbers directly to ILNP's
supposedly globally unique Identifier system seems like a bad idea to
me.  Likewise, I think, to other people: Roland Bless (msg07092),
Mikael Abrahamsson (msg07094) and Klaas Wierenga (msg07095).

The current ILNP design makes a device's participation in a global
system - you intend it to be *the* global system - dependent on the
correct behaviour and configuration of other devices the world over.
 So the clash scope is not a LAN - it is the entire world.

Unfortunately, I don't see a practical way you can make even a
hierarchically assigned, actually globally unique, Identifier into a
truly first-class entity - at least where Mobility is concerned.  I
think every scalable routing solution should have very good support
for Mobility.

Because ILNP relies on new semantics for the IPv6 lower 64 bits, it
would be at least extremely expensive (msg07088) to make each /64
network robust against the attack Xiaohu Xu devised.  Even if this
could be done, I think it would be too slow to support mobility in a
manner suitable for VoIP.

Xiaohu Xu's attack, which might be known as "Identifier squatting",
involves the attacker's host gaining publicly available information
about the victim host and then behaving in a manner which is
indistinguishable from an ordinary IPv6 host, or an ordinary ILNP host.

 - Robin

---

From: Tony Li <[email-masked]>
Date: Sat, 10 Jul 2010 11:49:05 -0700

Hi Robin,

> So it had better be good.

ILNP has no basic flaws (as known to date).  However, people seem to want to reset the bar for it.  ILNP already stipulates:

	"the security properties
	of the new proposal are never worse than for existing IPv6."

ILNP does not fix IPv6's (or IPv4's) security problems.  It does not fix a MITM attack.  It will not prevent a DoS attack.  It will not prevent SYN floods.  It will not fix prefix theft.  It does not prevent L2 (MAC) layer spoofing.  It will not prevent Google from snooping your WiFi.  And while it may be an adequate sleep aid (sorry Ran), it is neither a dessert topping nor a floor wax.

> a proper globally unique Identifier.  

Agreed.  However, we cannot introduce new security problems.  Back when 8+8/GSE was originally introduced, security folks pointed out that if hosts were constrained to ONLY use a global identifier, then Bad Guys could track a host.  Privacy advocates were rightly concerned, and in today's environment of even more sensitivity to privacy, that ILNP hosts (and their users) would effectively have no privacy.

This will not fly.

Now I, and many others, don't particularly care.  However, the fact of the matter is that there are MANY others who do care.  I concur that this needs to be an option for those that want it.  This implies that there needs to be a mechanism for local identifiers, as Ran has proposed.  As I've previously mentioned, once you use a local identifier, you give up session continuity across mobility.  This seems only reasonable: if you want privacy, you can't really expect the 'net to also track your movements.

Based on the behavior of most people today, I would expect that 99% of the population would continue to use globally unique identifiers.

> administrative structures I guess.

Exactly.  Good architecture does not introduce unnecessary bureaucracy.  IPv4 addresses are hierarchically assigned and should be unique.  Has anyone done any significant amount of networking work and not seen duplicates?  Hierarchical assignment is also an imperfect solution.

> problem, if two devices with the same MAC are connected to the same

The basis of this problem is not small.  Today, many folks are working on VM migration for data centers.  The lack of a globally unique MAC address in VM implementations is causing some truly annoying problems, giving rise to some very hacky 'solutions'.

Again, this problem is independent of ILNP and it's unreasonable to suggest that ILNP solve it.

> So the clash scope is not a LAN - it is the entire world.

Not at all.  It only requires that hosts that choose to use a locally unique identifier ensure that it is locally unique.

> think every scalable routing solution should have very good support

Ergo, we use the EUI-64.

> manner suitable for VoIP.

Cell companies have already proven otherwise.  It is possible to make the link layer include sufficient authentication so that knowledge of a MAC address (or any other on-air bits) is insufficient.

> indistinguishable from an ordinary IPv6 host, or an ordinary ILNP host.

The attack is already well known as MAC address spoofing.  Again, ILNP does not address it.   Both Steve and I have pointed out the well known mechanisms to address the problem.  

You have not disagreed with any of those points.

Regards,
Tony

---

From: Robin Whittle <[email-masked]>
Date: Sun, 11 Jul 2010 16:01:14 +1000

Short version:   I think Tony misunderstands the "Identifier
                 squatting" DoS attack proposed by Xiaohu Xu:
                 msg07042 --> msg07057.

                 This vulnerability of ILNP mobility to a DoS
                 attack is quite independent of the questions of

                 1 - How to generate globally unique Identifiers
                     (from MAC addresses etc. or via hierarchical
                     assignment).

                 2 - How locally unique Identifiers cause great
                     complexity for the ILNP stack, and make ILNP's
                     Locator and Identity semantics seriously
                     muddled.

                 Tony also states that ILNP has no known faults.
                 I list some of what I consider to be its faults.

Hi Tony,

Thanks for your detailed reply, in which you wrote:

>> Further to Toni Stoev's message, one reason a person might
>> expect an architecture such as ILNP not to have basic flaws,
>> such as I think Xiaohu Xu pointed out, is we can think of other
>> architectures with fewer flaws.  Another reason is that you and
>> a few others are making great claims for ILNP as being superior
>> to any other architecture. So it had better be good.
> 
> 
> ILNP has no basic flaws (as known to date).

That's a matter of opinion.  In addition to the "Identifier squatting"
DoS vulnerability for mobile ILNP which Xiaohu Xu proposed, these
come to mind:

  1 - Extra delays establishing communication sessions,
      extra packets and/or longer packets, plus extra CPU
      effort for all hosts.  (Common to all CEE Loc/ID Separation
      architectures.)  msg07017.

  2 - No prospects of wide enough voluntary adoption to provide
      substantial benefits to adoptors or to scalable routing - due
      in part to the benefits arising only when essentially all
      hosts have adopted it:

  3 - Applicable only to IPv6, since ILNPv4 requires all DFZ and
      other routers be upgraded to handle the new header option.

  4 - Identifier uniqueness is brittle due to dependence on host-
      generated identifiers from MAC addresses and the like, which
      may not be unique.  Also, it is not assured that all hosts
      now or in the future have any unique hardware from which
      to derive a unique hardware identifying number

  5 - Inability to look up an Identifier to find its one or more
      Locators.  This is because neither type of Identifier:

        a - MAC-etc. generated supposedly globally unique.

        b - However generated and only locally (within a /64) unique.

      is suitable for creating an kind of lookup system, such as
      one based on DNS, which is indexable on Identifier.  Please
      see my previous msg07099 for discussion of this.

      In today's IP protocols, the IP address is both the Identifier
      and the locator, so a host can use this to send a packet, with
      the knowledge that the packet will either get to the host
      which has this identity, or will be dropped and therefore not
      delivered to a host with any other identity.

      Therefore (according to my potentially faulty understanding),
      ILNP relies on starting with a FQDN or from an Identifier-
      Locator pair, where the /64 of this Locator has a correctly
      updated reverse DNS, which will return an FQDN.  Then, you look
      up the FQDN to reliably obtain the one or more Locators which
      are currently used by the host with this Identifier.

That said, in IPv6, ILNP does not involve longer packets - which is a
blessing compared to CES architectures which use encapsulation.
ILNPv4 does involve longer packets, but this should not cause as much
trouble with Path MTU Discovery as a CES architecture which uses
encapsulation, since the sending host adds the option - the packet is
not made any longer in transit.

An ILNP-aware stack is intended to work with existing applications -
while some other CEE architectures (such as Name Based Sockets)
require applications to be rewritten, which would raise a still
steeper barrier to any level of adoption.  Furthermore, I think such
rewriting would force changes to some application protocols, with the
new protocols probably being less efficient.  So the NBS-compatible
version of the application would not be backwards compatible with the
original protocol.

As long as ILNP supports all current applications (which remains to
be seen), it should be able to support all existing protocols.  If
this can be done, I think these protocols will run slower (at least
in the initial exchanges) under ILNP than they do on native IPv6.
Some protocols may become very slow and inefficient under ILNP, such
as any protocol which involves UDP packets flying back and forth
between a large number of hosts, rather than concentrating on simple
two-way sessions.  This should probably count as a flaw too.

> However, people seem to want to reset the bar for it. ILNP already
>  stipulates:
> 
>       "the security properties of the new proposal are never worse 
>        than for existing IPv6."
> 
> ILNP does not fix IPv6's (or IPv4's) security problems.  It does
> not fix a MITM attack.  It will not prevent a DoS attack.  It will
> not prevent SYN floods.  It will not fix prefix theft.  It does
> not prevent L2 (MAC) layer spoofing.  It will not prevent Google
> from snooping your WiFi.  And while it may be an adequate sleep
> aid (sorry Ran), it is neither a dessert topping nor a floor wax.

Can you cite an instance where people are expecting ILNP to be more
secure, or better in any way, than IPv6 today?

I can't think of anyone expecting this.

ILNP's mobility is unlike anything in IPv4 or IPv6 today, but it is
reasonable to expect that it doesn't introduce a simple DoS
vulnerability like we have been discussing.

>> Identifiers, then these will always be second-rate things
>> compared to a proper globally unique Identifier.
> 
> Agreed.  

OK - hence the title of this thread.  Therefore, this option in ILNP
doesn't accord with the text you wrote in the RRG Recommendation,
regarding the architecture using constructs which are first-class
citizens.

> However, we cannot introduce new security problems.  Back
> when 8+8/GSE was originally introduced, security folks pointed out
> that if hosts were constrained to ONLY use a global identifier,
> then Bad Guys could track a host.  Privacy advocates were rightly
> concerned, and in today's environment of even more sensitivity to
> privacy, that ILNP hosts (and their users) would effectively have
> no privacy.
> 
> This will not fly.
> 
> Now I, and many others, don't particularly care.  However, the
> fact of the matter is that there are MANY others who do care. 

"Many" is a big word.  Can you document this?

Who really cares about the ability of an IPv6 host to repeatedly
choose a fresh lower 64 bits for its IP address, thereby breaking
all sessions, but supposedly achieving a degree of privacy not
possible if it retains the one set of bits?

Just because it is an option in IPv6 doesn't mean anyone was
clamouring for it (maybe some were - I wasn't involved in IPng), or
whether anyone uses it now or would use it if IPv6 was widely adopted.

> I concur that this needs to be an option for those that want it.

OK - but it makes the host stack much more complex, because there are
two classes of Identifier, and for locally unique ones, there are all
sorts of combinations for host AAAA to consider when communicating
with a host BBBB which has an identifier which is only locally unique:

   DNS lookup of FQDN returns BBBB with locators XXXX and YYYY.

   AAAA needs to distinguish this BBBB from any other hosts it is
   communicating with which also have an Identifier BBBB, and which
   have different Locators.  So the semantics are not at all
   "crisp and clean".

   Also, AAAA needs to cope with the situation of its own Identifier
   being locally unique, but communicating with one or more other
   hosts whose Identifier is also AAAA.

   When AAAA receives a packet from XXXX-BBBB it can't just send a
   packet back to that address, as if that packet would definitely
   reach the host whose Identifier is genuinely BBBB.  It first
   needs to use BBBB to securely find which Locators the real BBBB
   host currently uses.

   Since there is no ability to look up anything based on just an
   Identifier (as noted above, due to the lack of hierarchical
   assignment of Identifiers) AAAA must do a reverse lookup of
   the IP address XXXX-BBBB.  That will only be possible if the
   XXXX /64 network runs reverse DNS with ILNP extensions and
   has had its information correctly set up.  This will return
   a FQDN and perhaps some Locators.  If the reverse DNS can't be
   assumed to be totally up-to-date with Locators, then AAAA needs
   to use the FQDN via the main secure ILNP DNS extensions to look
   up the Identifier (which should be BBBB) and potentially multiple
   Locators.  Only then can host AAAA know how to send a packet to
   the host whose Identifier really is BBBB in the XXXX /64 without
   a chance that the packet will arrive at any other host.

   All this is mandatory, since the ILNP stack is required to
   support existing applications - and existing applications
   assume that sending a packet to any host whose Identity is
   that of a particular IP address will not result in the
   packet being received by any other host.  (This is discussed
   in msg07017 too.)

I guess there would be other complications - I haven't tried to think
 of every one.  I assume that a host using XXXX-BBBB can communicate
with hosts in /64s other than XXXX - otherwise, this would be no use
for privacy.  So three hosts all with the same Identifier, locally
unique in their own /64s, and so with IP addresses XXXX-BBBB,
YYYY-BBBB and ZZZZ-BBBB should all be able to communicate.

Compare this complex, muddled, semantics for "Locator" and
"Identifier" with the text I quoted from Ran's I-D in msg07091 - and
you will see that most of the ILNP explanation assumes crisp, clear,
semantics which are impossible with Identifiers which are only
locally unique.

However, I understand you want to retain locally unique Identifiers
as an option, in the knowledge they can't be used for Mobility -
primarily or purely for its ability to provide some anonymity (AKA
privacy) when used on the global Internet.

I guess this may help with the privacy aspect, since the one host
could regularly change its Identifier (breaking sessions, of course)
and so avoid leaving a pattern of the same IP address and therefore
the one ILNP Identifier at servers all around the world.  Still, as
long as this all happens in a single /64, the privacy benefits are
limited - dependent largely on how many other broadly similar usage
patterns are observed by the servers in hosts with other IP addresses
in the same /64.

I am a privacy advocate and I was never much impressed by IPv6's
option for rapidly changing lower 64 bits as a privacy enhancement
measure.

I think you could get much the same level of privacy by having the
host switch between a large number of pre-existing globally unique
Identifiers.  All will use the same /64 prefix for their Locators, I
guess - so this would be equivalent to the current "privacy"
arrangements in IPv6.

The host needs access to some very large pool of such Identifiers,
each with a usable Locator.  But there's plenty of Identifier space
in 64 bits, so this should not be a problem.

To maximise privacy properly in this manner, the host would probably
want to choose between Identifiers from multiple different
organisations - multiple divisions of the Identifier hierarchy.

Still, the Locator will be the same /64, and it would be well known
to enquiring minds poring over the logs of one or more servers which
parts of the Identifier space were frequently used in this way.

   (BTW, see http://panopticlick.eff.org for how a Java applet, I
    guess, reports browser plugins, screen size, system fonts etc.
    which will frequently identify individual hosts.)

I think IPv6's "privacy" arrangements are pretty weak.  I can't think
of anything much better in any architecture, short of using TOR or an
anonymizing proxy.  Perhaps what I suggest above - switching between
a bunch of Identifiers from various parts of a hierarchically
assigned Identifier space - would be judged somewhat less
satisfactory than the existing IPv6 arrangements, but I think they
are not much value anyway.

I guess there is no documented use of the existing IPv6 privacy
functions, partly because these folks don't want to talk about it and
also because so few people use IPv6.

I still think ILNP would be significantly improved by getting rid of
locally unique Identifiers and using only globally unique,
hierarchically assigned Identifiers.

> This implies that there needs to be a mechanism for local
> identifiers, as Ran has proposed.  As I've previously mentioned,
> once you use a local identifier, you give up session continuity
> across mobility.  This seems only reasonable: if you want privacy,
> you can't really expect the 'net to also track your movements.

OK.

> Based on the behavior of most people today, I would expect that
> 99% of the population would continue to use globally unique
> identifiers.

I agree - I think the actual utilization of these locally unique
identifiers would be so low as to not justify the great complexities
in the ILNP stack which are required to support it.

As I wrote recently:

   ILNP Identifier and Locator semantics are muddled and soggy
   http://www.ietf.org/mail-archive/web/rrg/current/msg07091.html

I believe you can't claim that the Identifier and Locator semantics
are crisp and clear as long as you allow these locally unique
Identifiers.

>> I don't understand why you, Ran and I guess others want to build
>> a host's Identifier from a hardware ID in the device itself.
>> Saving on administrative structures I guess.
> 
> Exactly.  Good architecture does not introduce unnecessary
> bureaucracy.  

Yes - but good architecture is robust and not overly dependent on
correct configuration of external systems.  As far as I know, the
only way to get robustly globally unique Identifiers involves
bureaucracy.

> IPv4 addresses are hierarchically assigned and
> should be unique.  Has anyone done any significant amount of
> networking work and not seen duplicates?  Hierarchical assignment
> is also an imperfect solution.

Can you cite any actual examples?  I know sometimes by accident or
design a whole prefix is advertised in the DFZ in a way which hijacks
traffic from the router which properly advertises this prefix.  That
is not altered by any of the proposed architectures.  But that kind
of attack is generally very public, easy to detect and at odds with
accepted standards of router administration.

>> architectures" - to Ethernet interfaces with MAC addresses which
>> were not globally unique.  This is only causes a clash, and
>> therefore a problem, if two devices with the same MAC are
>> connected to the same Ethernet.
> 
> The basis of this problem is not small.  Today, many folks are
> working on VM migration for data centers.  The lack of a globally
> unique MAC address in VM implementations is causing some truly
> annoying problems, giving rise to some very hacky 'solutions'.

Sure, but they are localised to Ethernets or whatever non-globally
significant domains a MAC address is used.

> to suggest that ILNP solve it.

Neither I nor anyone else is expecting ILNP to solve problems caused
by MAC clashes.

There have been three lines of discussion here - which have been
somewhat entwined:

  1 - The DoS attack I call "Identity squatting", as proposed by
      Xiaohu Xu.  This has nothing to do with MAC addresses.  It
      doesn't matter whether the supposedly globally unique
      ILNP Identifier results from hierarchical assignment,
      MAC addresses, or radioactive decay.

      It is an intentional attack which Steven Blake acknowledges as
      real, against a victim host going mobile to another /64.  It
      is based on publicly available information about the victim
      host (its Identifier).  To any IPv6 or ILNP-enhanced IPv6
      network, the actions of the attacker are indistinguishable
      from the ordinary behaviour of an IPv6 or ILNP host.

  2 - Problems resulting from non-hierarchical assignment of
      Identifiers - specifically the current plan of using a
      MAC address or some other hardware identifier to generate
      the Identifier, in a direct, deterministic, manner by the
      host itself.

      Several folks have written about MAC addresses not being
      unique, and of (virtual) hosts not having any unique
      hardware to gain a MAC address or any other globally
      unique number from.

      Since you want the ILNP identifiers to be "first class",
      I think you need to avoid this MAC address etc. reliance
      and use another approach.  The only approach I can imagine
      working is hierarchical assignment.

  3 - The problems arising from allowing locally unique Identifiers
      no matter how the Identifiers are generated.

>> The current ILNP design makes a device's participation in a
>> global system - you intend it to be *the* global system -
>> dependent on the correct behaviour and configuration of other
>> devices the world over. So the clash scope is not a LAN - it is
>> the entire world.
> 
> Not at all.  It only requires that hosts that choose to use a
> locally unique identifier ensure that it is locally unique.

But that rules out mobility.  I and I guess many other people believe
that a scalable routing solution without mobility is a non-starter.

Keeping the option of locally unique Identifiers will make writing
the stack code a can of worms.

Because Ran and I think you set such an elevated threshold between
"architecture" and "engineering" and since it seems the details of
the stack code fall into the latter - which you have little interest
in - I don't think you have fully considered what a horror it will be
to write this stuff, and somehow support existing applications with
the assumptions they currently make about the properties of IP addresses.

>> hierarchically assigned, actually globally unique, Identifier
>> into a truly first-class entity - at least where Mobility is
>> concerned.  I think every scalable routing solution should have
>> very good support for Mobility.
> 
> Ergo, we use the EUI-64.

I think you are failing to distinguish between what I am discussing
here - the "Identifier squatting" attack (1) - and the matter of
whether supposedly globally unique Identifiers result from
hierarchical assignment or are generated by each host from a MAC
address or the like (2).

It doesn't matter how you generate globally unique Identifiers or
whether or not they are in fact globally unique - the "Identifier
squatting" attack will still work.

>> Because ILNP relies on new semantics for the IPv6 lower 64 bits,
>> it would be at least extremely expensive (msg07088) to make each
>> /64 network robust against the attack Xiaohu Xu devised.  Even
>> if this could be done, I think it would be too slow to support
>> mobility in a manner suitable for VoIP.
> 
> Cell companies have already proven otherwise.  It is possible to
> make the link layer include sufficient authentication so that
> knowledge of a MAC address (or any other on-air bits) is
> insufficient.

Not counting international roaming and switching from one 3G/GSM
network to another (which may clobber the call, for all I know) the
situation with cellphone companies is rather different than what
would be required to protect ILNP from the "Locator squatting" attack.

The cellphone companies run their own access network so the whole
thing is integrated.

Global mobility of the kind that ILNP aims to provide (as does TTR
Mobility, and now Fred Templin's IRON, using similar techniques)
requires that the host be able to use some access network which has
no relationship with the Mobility provider.  The access network
cannot be assumed to have any special mechanisms.

To prevent the "Locator squatting" attack, every protected access
network would need to prevent a host getting a lower 64 bits QQQQ
until one of these was true:

  1 - The system had determined that QQQQ was not used as a
      globally unique ILNP identifier by any host whatsoever.

      (This could only be done with an Identifier indexed lookup
       system, which I think would only be possible if all
       Identifiers were hierarchically assigned.)

      This would require an explicit negative response from a
      single global lookup system.

  2 - The lookup indicates that QQQQ is being used as an ILNP
      Identifier.  Then the routing system needs to engage in
      a cryptographically secure exchange with the host, and
      probably with whichever organisation administers this
      part of the Identifier hierarchy, so that the host can
      prove it is authorized to use this Identifier.

So this would involve retrofitting every IPv6 network which could be
used for mobility, in order to protect against this attack.

My impression is that this is bound to be slower than whatever the
cell-phone companies do - since they are running their own access
networks which include the authentication stuff for their customers -
and which are more tightly integrated (than what I suggest above)
with other cellphone companies for the purpose of supporting roaming.

>> Xiaohu Xu's attack, which might be known as "Identifier
>> squatting", involves the attacker's host gaining publicly
>> available information about the victim host and then behaving in
>> a manner which is indistinguishable from an ordinary IPv6 host,
>> or an ordinary ILNP host.
> 
> The attack is already well known as MAC address spoofing.  

I think you do not understand this attack.  It has nothing at all to
do with MAC addresses.  It is arguably spoofing an ILNP Identifier,
since there is nothing to prevent this from happening at present.

The attack only works if the attacker moves first and grabs the IP
address with the victim's Identifier in the lower 64 bits before the
victim's host attempts to use ILNP Mobility to connect to the same
/64 in which the attackers host is based.

The attacker can't cause any trouble if the victim's host gets this
address first.

This attack is only very vaguely related to MAC address spoofing.

> Again,
> ILNP does not address it.   Both Steve and I have pointed out the
> well known mechanisms to address the problem.
> 

Sure - but the attack has nothing to do with MAC address spoofing.
Steve seems to understand the attack and has acknowledged it is real:

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

     "I acknowledge that this attack exists."

  - Robin

---

From: Tony Li <[email-masked]>
Date: Sun, 11 Jul 2010 01:00:12 -0700

Hi Robin,

> That's a matter of opinion.

That's correct.  While your opinion does not match mine, you happen to be incorrect.

>      architectures.)  msg07017.

ILNP resolves its mapping as part of normal DNS lookups.  There are no extra sessions and no extra packets during connection setup.

>         http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

The lure of seamless mobility is ample motivation.

>      other routers be upgraded to handle the new header option.

Both necessary and sufficient.

>      to derive a unique hardware identifying number

Globally unique identifiers are not brittle.

>      Locators.

This is not necessary.

> in the initial exchanges) under ILNP than they do on native IPv6.

Why?

> two-way sessions.  

There are no additional packets.  Where did this alleged latency come from?

> secure, or better in any way, than IPv6 today?

All of the attacks listed are exactly identical to ones that can be done on IPv6 today.

> regarding the architecture using constructs which are first-class

Locally unique identifiers are intentionally not first class citizens.  Globally unique ones are.

> "Many" is a big word.  Can you document this?

Please see the archives of the big-internet mailing list.

> possible if it retains the one set of bits?

The entire security directorate, security AD, the IESG and the IANA.

> OK - but it makes the host stack much more complex,

Agreed, however, it is still vitally important.

> YYYY-BBBB and ZZZZ-BBBB should all be able to communicate.

Note that a locally unique identifier effectively gives the host the same capabilities as a legacy v6 host plus multi-homing support.  But not mobility.

> option for rapidly changing lower 64 bits as a privacy enhancement

While it may not be a solution, I suspect that you will concur that a trail of a permanent, globally unique identifier is an even larger privacy issue.  It's the logical equivalent of a continually updated Google maps page with a red pin stuck in it that says "Robin is here right now".  ;-)

> guess - so this would be equivalent to the current "privacy"

Except that the number of identifiers necessary for a host balloons, as they basically need to be a one-time pad.  This depletes the address space unnecessarily quickly.

If, instead, the locally unique pool is dynamically assigned and reused, in much the same way that DHCP assigns addresses today, we avoid this issue, we get local uniqueness, and identifier reuse.

> hierarchically assigned Identifiers.

Sorry, that won't be happening.  Get over it.

> are crisp and clear as long as you allow these locally unique

Fortunately, I'm a _recovering_ perfectionist.  There is such a thing as good enough.

> only way to get robustly globally unique Identifiers involves

Bureaucracy NEVER is robust.  A glance at any front page should tell you this.

> Can you cite any actual examples?  

Hundreds, personally.  Prior to the advent of DHCP (and even in the early days of DHCP), getting duplicates was trivial.  And it still happens in the lab, when some enterprising soul decides that allocating an address manually is too hard and simple "makes one up".  In defense of that, every OS that I can think of has duplicate address detection logic.  And also why DAD is built into IPv6 ND.
 
Oh, and that's just for /32's. 

> I know sometimes by accident or

But that's not very robust, is it now?  You seem to want perfection.  This is clearly imperfect and therefore unacceptable.

<Insert Kirk's monologue from The Changeling.>

> significant domains a MAC address is used.

Sorry, but no.  People are talking about trans-oceanic data center migration for disaster recovery.  Necessary as certain parts of the world are considered likely to slip off into the ocean.

> Neither I nor anyone else is expecting ILNP to solve problems caused

Yet you consider Xu's 'attack' to be a flaw.  It is EXACTLY a MAC collision.  And to be frank, you can execute it today: go to your favorite WiFi hotspot.  Sniff the traffic.  Copy down someone's MAC address.  Go again tomorrow, and use their MAC address before they show up.

Your logic is inconsistent.

>      MAC addresses, or radioactive decay.

The point is that if an attacker has your identifier/MAC address and is authorized to join a subnet without any link level authentication, then they can either impersonate you and/or DoS you.  We'll ignore the fact that they can also snoop you.  

The remedies for this are well known and have been mentioned to you, yet you fail to accept them or explain why they are problematic.

Again: 802.1x, SeND.

Instead, you endlessly repeat your allegations.  

Do you understand why discussions with you are pointless?  You accuse, but you do not listen to responses.

>      the Identifier, in a direct, deterministic, manner by the

Problems from hierarchical assignment are provably FAR worse.  Experience in the field has made this very clear.

>      hardware to gain a MAC address or any other globally

Yes, mistakes happen.  If you want a world without mistakes, you first need to remove all humans.  Sorry, but you're on the wrong planet.

You need to weight the probability of mistakes.  So far, the odds of a duplicate MAC are FAR lower than a duplicate manually assigned /128 or /64.

> that a scalable routing solution without mobility is a non-starter.

Asked and answered.

> in

False.   Do you understand how much code I've written?  And where it runs?  Hint: this message will not get to you without it.  ;-)

> - I don't think you have fully considered what a horror it will be

Incorrect.  This is not even hard.

> hierarchical assignment or are generated by each host from a MAC

I'm trying to respond to your comments.  It's not my fault if your line of discussion is confusing.

> squatting" attack will still work.

Until you apply the remedies as discussed.

Similarly, other IPv6 attacks will work, until you apply IPsec.  Nothing new here.

> would be required to protect ILNP from the "Locator squatting" attack.

Incorrect.  You're correct about roaming dropping calls, but the ability of a handset to authenticate itself and have a unique identifier (IMEI) are well known.  In the cell world, the analog to the locator squatting attack resulted in theft of services, so non-cleartext link layer authentication was introduced.  We simply need the same.

> The cellphone companies run their own access network so the whole

The architecture is almost identical to the Internet's.  Many different bands, several different protocols, all resulting in roaming with authentication and end-to-end calls.

> cannot be assumed to have any special mechanisms.

Disagree.  If you want secure mobility (not everyone does), you need authentication.

>      prove it is authorized to use this Identifier.

3 - The host accessing the network was a cryptographically authenticated known host, with a non-cleartext protocol, with known host attributes, such as the MAC address and identifier.

> used for mobility, in order to protect against this attack.

Only if you care about secure mobility.  If you don't, you can visit Starbuck's today and squat away with IPv6 today.

> since there is nothing to prevent this from happening at present.

I think YOU don't understand the attack.  If I sniff your IPv6 address today and arrive at Starbuck's ahead of you, I've done _exactly_ the same thing.

Tony

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 11 Jul 2010 11:11:54 +0200 (CEST)

On Fri, 9 Jul 2010, Tony Li wrote:

>> In the real world, MAC addresses are not unique, they're just unique 
>> most of the time. Any scheme that depends on unique MAC addresses need 
>> to gracefully handle when they're not.
>
> In the real world, there are no perfect solutions.  Why is everyone 
> insistent on an architecture that solves all problems, even in the face 
> of equipment that clearly does NOT follow existing architectures?

When I designed a ADSL residential broadband solution in 2002 (or so) I 
made sure we could handle duplicate MAC addresses between customers (this 
was solved by RFC3069 capable equipment) and I was very happy about that 
when we discovered a few years later that 5% of our user base was using 
the same MAC address.

I don't know enough about the pros and cons of each proposed solution 
(because I haven't really found an easily understandable 
summary/presentation), but I'm saying that operationally (working at an 
ISP) I want any solution proposed to gracefully handle identifier 
collissions (either intentional or unintentional).

It took a long time before there were standards/proprietary mechanisms 
that made it possible to deploy IPv4 securely to residential customers 
(finally we now have the SAVI-WG that'll hopefully make this happen for 
both IPv4 and IPv6) and any solution proposed for the future should have 
this kind of work built in already.

---

From: Klaas Wierenga <[email-masked]>
Date: Sun, 11 Jul 2010 12:01:32 +0200

On 7/9/10 6:43 PM, Tony Li wrote:
>> identifier. Thinking out loud, how about instead of using the
>> privacy extensions make it possible (for an end user) to perform
>> some kind of one-way function on the EUI-64 address that can not be
>> related to the original hardware address. It would then be up to
>> the user to not apply this function, apply it once or apply it many
>> times, whatever the trade-off between location privacy and session
>> persistence of the user dictates.
>
>
> That's a perfectly fine way to generate (but not validate) a locally
> unique identifier.  However, if you want your mobility with session
> continuity, you're going to have to exchange that with
> correspondents.  As soon as you do, you've lost privacy.
>
> Simply put: privacy is mutually exclusive with session continuity.
> Pick one.  Either is fine, but you can't have both.  ;-)

well... not really, perfect privacy and perfect session continuity are, 
I agree on that. What concerns me is that for the lifetime of my device 
I will be traceable. I think it would be very desirable (again, not 
aiming for perfection, just for a reasonable trade-off between privacy 
and conituity) to have at least the *ability* to change your persistent 
identifier without having to get a new device.
You talk about losing privacy with your correspondents, but what I am 
worried about is losing privacy with the world, I choose who to 
correspond with, but I don't want the world to be able to look up my 
location.

"What? Is Tony again at Madame Jeanette today?" ;-)

draft-rja-ilnp-intro-03.txt does specify that cryptographically 
generated id's or privacy extensions can be used, I hope that that will 
not get lost in the process.....

Klaas

---

From: Robin Whittle <[email-masked]>
Date: Mon, 12 Jul 2010 01:21:15 +1000

Short version:  A long exchange with Tony, regarding various things
                including the effectiveness of changing the lower
                64 bits in an IPv6 address (either for IPv6 or as
                Identifier changes for ILNP) and how this supposedly
                helps with privacy / anonymity.

                I think it doesn't help much - but I can't think of
                any robust system which assures such privacy /
                anonymity.

                Tony attests that this approach is strongly desired
                by many people, but the only documented evidence of
                this he cites is the archives of a mailing list
                which closed in 1997.

                To achieve this frequent change of Identifier, ILNP
                uses locally unique Identifiers - and I am sure this
                makes the ILNP stack much more complex.  I am sure it
                makes the semantics of Locator and Identifier
                horribly messy, when Ran attests they are "crisp and
                clear".  Tony agrees that the locally unique
                Identifiers are not "first class citizens".

                Despite repeated discussions, Tony seems to think
                that the "Identifier squatting" DoS attack against
                ILNP mobility, developed by Xiaohu Xu, is identical
                to MAC spoofing on a LAN.  I tried to explain in
                several ways that it is not, but Tony attests that
                it is the same thing, and that I don't understand
                this attack.

                His defence against the attack would not work.

                Yet Steve Blake agrees the attack is real.

Hi Tony,

> That's correct.  While your opinion does not match mine, you

OK - I'll bite:

I think there is no objective test for whether ILNP has any flaws
which doesn't rely on people's opinions.  Can you nominate one?

>> 1 - Extra delays establishing communication sessions, extra
>>     packets and/or longer packets, plus extra CPU effort for all
>>     hosts.  (Common to all CEE Loc/ID Separation architectures.)
>>     msg07017.
> 
> ILNP resolves its mapping as part of normal DNS lookups. There are
>  no extra sessions and no extra packets during connection setup.

So you disagree with my argument:

   "Overloading" of Loc & ID functions is good for hosts and should
   be maintained
   http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html

I will write another message in that thread and attempt to explain
it, specifically for ILNP.

>>     substantial benefits to adoptors or to scalable routing - due in
>>     part to the benefits arising only when essentially all hosts
>>     have adopted it:
>> 

Yes, but ILNP only provides mobility for communications with other
ILNP hosts, of which there initially very few.

By contrast, TTR Mobility - as would be implemented with Ivip and now
I think IRON - supports communication sessions with all hosts: all
IPv4 or IPv6 hosts which are not in upgraded networks, as well as all
Ivip/IRON hosts, mobile or not.

I don't recall you giving a critique of this page, yet some other
folks found it to be a reasonable statement of the barriers to
widespread adoption, in the form of constraints on architectures such
that they may be widely enough adopted to solve the routing scaling
problem.

Core-Edge Separation architectures are much more capable of meeting
these constraints.  I think Ivip meets them and LISP, ideally, would
too - but I don't think it would work as well.  Perhaps IRON could
meet them too.

I think ILNPv6 fails to meet constraints 1 to 5 and that ILNPv4 fails
to meet constraints 1 to 6.

  1 - The solution must provide immediate and
      compelling benefits to any new or existing
      end-user networks which adopt it, irrespective
      of how many other networks have so far adopted
      it.

ILNP multihoming and mobility only works for sessions with other ILNP
hosts, which will initially be a very small proportion of hosts.  So
except perhaps within particular inter-communicating groups of users
who all adopt ILNP, there is little or no benefit to early ILNP
adoptors.  So there's no strong reason for most people to adopt it
and user numbers will remain low indefinitely.

  2 - Therefore, it must provide multihoming, TE and
      portability for the adopting networks in a
      manner which fully supports communications with
      all hosts - including all hosts in non-upgraded
      networks.

Likewise, ILNP's benefits don't extend to sessions with non-upgraded
hosts.

  3 - Therefore, the solution must be compatible with
      all hosts (stacks and applications) and routers
      in non-upgraded networks.

As above.

  4 - The solution must be compatible with all
      existing applications in the adopting networks.

While ILNP is not supposed to require new applications, its benefits
only apply to communications with applications running in hosts with
upgraded stacks.

  5 - Although in principle, some or many host stacks
      could be upgraded in the adopting networks, the
      difficulties this presents means that a scalable
      routing solution will only be widely enough
      adopted on a voluntary basis if no such upgrades
      are required in order for the new system to
      provide compelling benefits.

      Firstly, there are difficulties in motivating
      operating system / stack programmers to add and
      test new facilities.  Secondly there may be
      costs and disruption for the adopting network in
      upgrading the stacks.  Thirdly, in many or most
      end-user networks, some or many hosts will not
      be amenable to stack upgrades due to them using
      operating systems which are no longer being
      maintained or developed.  This is especially
      the case for devices such as printers, routers
      etc. which do not use one of the major
      operating systems.

ILNP involves stack upgrades.  So it doesn't meet this constraint either.

  6 - If the solution requires extra functionality in
      interdomain routers, . . .

I understand ILNPv6 meets this constraint, since it doesn't require
any changes to IPv6 routers.  For ILNPv4, DFZ and other routers need
to be upgraded before any upgraded hosts can use ILNP.  Hopefully
this can be done by firmware - but ILNPv4 can only work once
essentially all IPv4 DFZ and many other routers are upgraded.  Host
stacks need upgrading too.

I think that if ILNP could have met the above constraints, then it
could also meet the remaining constraints 7, 8, 9 and 10.

> Both necessary and sufficient.

Your interest in IPv4 is apparently zero or negative.  Google:

   "Tony Li" IPv4 toast

Most people care a lot about IPv4 and will continue to do so for many
years to com.

>>     generated identifiers from MAC addresses and the like, which may
>>     not be unique.  Also, it is not assured that all hosts now or in
>>     the future have any unique hardware from which to derive a
>>     unique hardware identifying number
> 

They are if they are generated from MAC addresses and the like, which
is what my statement says.

Klaas Wierenga, Mikael Abrahamsson and Toni Stoev have all written
with concerns about the ability of a MAC etc. based system to
generate genuinely unique Identifiers.

How would you convince these people, and me, that into the indefinite
future, either every host which could be an ILNP host will have a
suitable unique hardware identifier, or that alternatively the
instances of Identifier clashes resulting from this will be
sufficiently low not to be a significant problem for ILNP adoption?

>> 5 - Inability to look up an Identifier to find its one or more 

Please see my forthcoming message in the "Overloading of Loc & ID
functions ..." thread.

>> As long as ILNP supports all current applications (which remains
>> to be seen), it should be able to support all existing
>> protocols.  If this can be done, I think these protocols will
>> run slower (at least in the initial exchanges) under ILNP than
>> they do on native IPv6.
> 
> Why?

As above.

>> Some protocols may become very slow and inefficient under ILNP,
>> such as any protocol which involves UDP packets flying back and
>> forth between a large number of hosts, rather than concentrating
>> on simple two-way sessions.
> 

Actually there can be additional packets, for instance, from
draft-rja-ilnp-intro-05:

     The receiver(s) of such a UDP session SHOULD send a gratuitous
     IP packet containing an ILNP Nonce option to the sender, in
     order to enable the receiver to subsequently send ICMP Locator
     Updates if appropriate.

Also, there can be additional lookups if the first DNS lookup returns
an LP record - which requires a second DNS lookup to get the current
Locator(s).

I was thinking of a perhaps hypothetical protocol which involves
scattered UDP unidirectional communications with large numbers of
hosts - but I don't have a concrete example, so this is not a very
good argument.

I am now more concerned about how ILNP seems to assume that each
communication must start with a FQDN.  If it starts with an IP
address - that is a currently valid Locator-Identifier pair, then I
think the stack has to do extra lookups.  I explore this in the
forthcoming message.

>> Can you cite an instance where people are expecting ILNP to be
>> more secure, or better in any way, than IPv6 today?
> 

The "Locator squatting" attack is not related to any existing IPv6
functionality - only to ILNP's mobility functionality.

I am not sure what other security concerns have been expressed about
ILNP.  Can you recall others?

>> OK - hence the title of this thread.  Therefore, this option in
>> ILNP doesn't accord with the text you wrote in the RRG
>> Recommendation, regarding the architecture using constructs
>> which are first-class citizens.
> 
> Locally unique identifiers are intentionally not first class
> citizens.

OK.

> Globally unique ones are.

If they are genuinely globally unique.  But I and some other people
believe this can only be achieved via hierarchical assignment, rather
than the current ILNP approach of making them from MAC addresses and
the like.

Still, the inclusion of locally unique Identifiers means that the
class of objects known as ILNP Identifiers are not all "first class
citizens" - and that the semantics of Locator and Identifier are
anything but "clear and crisp" as Ran frequently claims.

The bunch of statements I quoted from his intro I-D would be true if
Identifiers were all genuinely globally unique.

But since the current arrangements allow also for locally unique
Locators, those statements are misleading.

> Please see the archives of the big-internet mailing list.

OK.  The list ran from 1992 to 1997:

  ftp://munnari.oz.au/big-internet/list-archive/

You wrote about the present day - "do care" - regarding an IPv6 host
switching to new IP addresses frequently, within the same /64:

> the fact of the matter is that there are MANY others who do care.

>> choose a fresh lower 64 bits for its IP address, thereby
>> breaking all sessions, but supposedly achieving a degree of
>> privacy not possible if it retains the one set of bits?
> 

Maybe so - but if this is the case, I hope you will point to some
kind of documents to this effect, say from 2006 onwards.

Since almost no-one uses IPv6 and since there is a desire or need for
anonymity, I think various approaches different to this have been
developed for IPv4.  These should work fine for IPv6 too.  To what
extent they would work for ILNP or for LISP, Ivip etc. would have to
be carefully considered.

That said, I think trying to ensure anonymity in a given set of user
actions, with particular servers, particular kinds of scrutiny, and
particular sets of other users' activity to blend into, is an
extraordinarily complex social and technical thing to achieve.  I
doubt it can be achieved to a high degree without a great deal of
thought and careful work.

I suspect Internet anonymity needs to be added to Romana Machado's
list of unsolved engineering problems, which currently stands at
"death and taxes".

> Agreed, however, it is still vitally important.

On the list, so far, I think only Klaas Wierenga has expressed an
interest in anything like this.  He wants to be able to change his
Identifier frequently (msg07104) and my understanding of msg07095 is
that he doesn't want to be stuck with persistent Identifiers.

In msg07095 I don't think he is expressing a lack of interest in
globally unique Identifiers, since he says he is a "mobility junkie"
and since, by your own account and I think Ran's I-D, locally unique
Identifiers should not or can't be used for mobility.

So my guess is that Klaas wants to be able to switch between multiple
Identifiers which are globally unique, but which he or his host
somehow has a role in generating or selecting, I guess in part to
avoid any path of detection arising from his host requesting these
numbers from any particular place and to avoid having to trust
external systems.

I don't care about how much ILNP supports this particular approach to
privacy / anonymity, since I am opposed to ILNP anyway and am
convinced it will never by widely deployed.  (I am only writing this
stuff to learn about scalable routing in general and to help convince
people to devote their energies to CES architectures.)

Its just that I think you could much improve ILNP and could only live
up to your own and Ran's claims about "clear and crisp semantics" by
ditching these locally unique Identifiers.

At least you admit that the stack will be made more complex by these
locally unique Identifiers.  This will make ILNP harder to introduce.

>> I guess there would be other complications - I haven't tried to
>> think of every one.  I assume that a host using XXXX-BBBB can
>> communicate with hosts in /64s other than XXXX - otherwise, this
>> would be no use for privacy.  So three hosts all with the same
>> Identifier, locally unique in their own /64s, and so with IP
>> addresses XXXX-BBBB, YYYY-BBBB and ZZZZ-BBBB should all be able
>> to communicate.
> 
> Note that a locally unique identifier effectively gives the host 
> the same capabilities as a legacy v6 host plus multi-homing
> support. But not mobility.

Yes - I understand this.  It will provide multihoming via the
currently established two or more Locators, because somehow the host
will only choose a "locally unique" Identifier after it tests it for
uniqueness in each of the the /64 ISP networks it is using - one for
each Locator.  However, it can't (or might not be able to) suddenly
go off and get another Locator in another access network, since there
is no guarantee that its current Identifier can be used in that /64.

>> option for rapidly changing lower 64 bits as a privacy
>> enhancement measure.
> 
> While it may not be a solution, I suspect that you will concur
> that a trail of a permanent, globally unique identifier is an even
> larger privacy issue.  It's the logical equivalent of a
> continually updated Google maps page with a red pin stuck in it
> that says "Robin is here right now".  ;-)

I agree.  Its just that changing only the lower 64 bits doesn't
really impress me.  If someone or some process was scrutinizing
server logs then this would only be effective to the degree that many
other sessions other than the one from my host were arriving from the
same /64s as I am using.   Perhaps I could deliberately use some ISP
or VPN or whatever which did this, but that would require a large
number of presumably privacy sensitive people also using the same
/64.  Inquiring minds would be wise to this, so this may not result
in any gains.

I can't think of any approach which would work well.

>> I think you could get much the same level of privacy by having
>> the host switch between a large number of pre-existing globally
>> unique Identifiers.  All will use the same /64 prefix for their
>> Locators, I guess - so this would be equivalent to the current
>> "privacy" arrangements in IPv6.
> 
> Except that the number of identifiers necessary for a host
> balloons, as they basically need to be a one-time pad.  This
> depletes the address space unnecessarily quickly.

Yes, but there are 2^64 locally unique Identifiers to share around,
so this should not be a problem.  They don't really need to be
"one-time" - as long as a host uses a sequence of Identifiers which
don't repeat and don't have any discernible relationship to each
other, that's the best you can do in this scheme.

> If, instead, the locally unique pool is dynamically assigned and
> reused, in much the same way that DHCP assigns addresses today, we
> avoid this issue, we get local uniqueness, and identifier reuse.

Yes - I can see that if you have enough similar users in the /64 and
they are all sharing or not sharing a bunch of Identifiers, then my
particular session would be mixed up with theirs.  But how many of
those people will be accessing the particular servers I am accessing?

Probably far too few - like none - to give my sessions any kind of
anonymity.

>> I still think ILNP would be significantly improved by getting
>> rid of locally unique Identifiers and using only globally
>> unique, hierarchically assigned Identifiers.
> 

OK.  The extra complexity in the stack and the failure to meet Ran's
claims about "crisp, clear semantics" are further reasons to think
dimly of ILNP.

>> I believe you can't claim that the Identifier and Locator
>> semantics are crisp and clear as long as you allow these locally
>> unique Identifiers.
> 

OK.  I reckon that by retaining locally unique Identifiers, the
semantics of ILNP Identifiers and Locators becomes a foetid swamp
which only the bravest or most foolhardy programmer would want to try
to implement.

Maybe this muddle is good enough for you - but I suggest you pull
down the "crisp and clear" billboards to avoid further discussions
such as this one.

>> Yes - but good architecture is robust and not overly dependent
>> on correct configuration of external systems.  As far as I know,
>> the only way to get robustly globally unique Identifiers
>> involves bureaucracy.
> 

I and some other folk believe that globally unique Identifiers will
better result from hierarchical assignment than from the current ILNP
approach.

This is another reason for us to think dimly of ILNP.

>>> IPv4 addresses are hierarchically assigned and should be
>>> unique.  Has anyone done any significant amount of networking
>>> work and not seen duplicates?  Hierarchical assignment is also
>>> an imperfect solution.
>>
> Hundreds, personally.  Prior to the advent of DHCP (and even in
> the early days of DHCP), getting duplicates was trivial.  And it
> still happens in the lab, when some enterprising soul decides that
> allocating an address manually is too hard and simple "makes one
> up".  In defense of that, every OS that I can think of has
> duplicate address detection logic.  And also why DAD is built into
> IPv6 ND.
> 

Sure - but this doesn't have any global significance.

Duplicate IP addresses are only a problem in a local network which
covers that address space.

Duplicate supposedly globally unique ILNP Identifiers clobber or
threaten the ability of a host to operate on a global basis.  The
catchment area is the world, not your LAN or corporate / campus network.

>> I know sometimes by accident or design a whole prefix is
>> advertised in the DFZ in a way which hijacks traffic from the
>> router which properly advertises this prefix.  That is not
>> altered by any of the proposed architectures.  But that kind of
>> attack is generally very public, easy to detect and at odds with
> But that's not very robust, is it now?  You seem to want
> perfection.  This is clearly imperfect and therefore unacceptable.

I am not insisting on perfection.

I am suggesting that one way to make people happier about ILNP is to
ensure all Identifiers are genuinely globally unique.

You don't want to do it, and I guess Ran thinks the same way.

> <Insert Kirk's monologue from The Changeling.>

Sorry - I only watched a few episodes of Star Trek.

>> Sure, but they are localised to Ethernets or whatever
>> non-globally significant domains a MAC address is used.
> 
> Sorry, but no.  People are talking about trans-oceanic data center
> migration for disaster recovery.  Necessary as certain parts of
> the world are considered likely to slip off into the ocean.

OK - but the catchment area is still within some private system.
With duplicate supposedly globally unique ILNP Identifiers, the
catchment area is global.

>> Neither I nor anyone else is expecting ILNP to solve problems
>> caused by MAC clashes.
> 
> Yet you consider Xu's 'attack' to be a flaw.  It is EXACTLY a MAC
> collision.  

I am sure it is not exactly like a MAC clash.  If Xiaohu Xu agrees
with me, then I would say you don't understand the attack.

Steve Blake seems to understand it - and he admits it is real.

> And to be frank, you can execute it today: go to your
> favorite WiFi hotspot.  Sniff the traffic.  Copy down someone's
> MAC address.  Go again tomorrow, and use their MAC address before
> they show up.

Sure - but I have to find out the victim's MAC address first, which I
can only do via the LAN it happens to be on.  Then I can only mount
the attack on a LAN it connects to.

With the "Identifier squatting" attack, the attacker can gain the
information he or she needs anonymously from public resources -
looking up the FQDN of the victim host to gaining its Identifier.
Then, the attacker only needs to be in the same /64 as the victim -
though the attacker has to connect there and squat on the victim's
Identifier as the lower order 64 bits before the victim's mobile host
tries to connect to any access network which uses this /64.  This
could cover a whole 3G network in a city or other large area.

> Your logic is inconsistent.

Your response make me think you do not understand the attack.  I
can't think of what more I can say to explain it.  Steve thinks it is
real and you don't.  Perhaps you can discuss it with him.

>>     doesn't matter whether the supposedly globally unique ILNP
>>     Identifier results from hierarchical assignment, MAC addresses,
>>     or radioactive decay.
> 
> The point is that if an attacker has your identifier/MAC address
> and is authorized to join a subnet without any link level
> authentication, then they can either impersonate you and/or DoS
> you.  We'll ignore the fact that they can also snoop you.
> 
> The remedies for this are well known and have been mentioned to
> you, yet you fail to accept them or explain why they are
> problematic.
> 
> Again: 802.1x, SeND.
> 
> Do you understand why discussions with you are pointless?  You
> accuse, but you do not listen to responses.

You do not appear to understand how this attack differs from the
LAN-based MAC attack, which is only very roughly comparable.

>>     Identifiers - specifically the current plan of using a MAC
>>     address or some other hardware identifier to generate the
>>     Identifier, in a direct, deterministic, manner by the host
>>     itself.
> 
> Problems from hierarchical assignment are provably FAR worse.
> Experience in the field has made this very clear.

There's nothing in what you wrote to convince me of these assertions.

>> Several folks have written about MAC addresses not being unique,
>> and of (virtual) hosts not having any unique hardware to gain a
>> MAC address or any other globally unique number from.
> 
> Yes, mistakes happen.  If you want a world without mistakes, you
> first need to remove all humans.  Sorry, but you're on the wrong
> planet.
> 
> You need to weight the probability of mistakes.  So far, the odds
> of a duplicate MAC are FAR lower than a duplicate manually
> assigned /128 or /64.

Mikael Abrahamsson, in his two recent messages, indicates the problem
of duplicate MAC addresses is significant.

No-one is advocating manually configured ILNP Identifiers.  With the
hierarchically assigned Identifier system I have in mind, and I guess
which others have in mind, the ILNP stack would be be manually
configured with a FQDN or some other way so it can figure out its
place in a hierarchy, and request an IP address from that system.

>> But that rules out mobility.  I and I guess many other people
>> believe that a scalable routing solution without mobility is a
>> non-starter.
> 
> Asked and answered.

So we agree that mobility is vital to the success of any scalable
routing system?

If so, this is another reason to think poorly of ILNP compared to
Ivip or probably IRON and LISP (assuming LISP is able to do mobility,
which at present I think they can't).  These 3 CES architectures
promise to do mobility with any correspondent host.  ILNP can only do
it for ILNP upgraded hosts.

ILNP mobility only works with the MN getting a global unicast address
- not behind NAT.  This might be likely on IPv6, but it is highly
unlikely for numerous mobile devices if ILNP was ever made to work
for IPv4.

TTR Mobility can work with the MN on IPv4 or IPv6, behind one or more
layers of NAT, and even on an address which itself is provided by TTR
 Mobility.  There can be any recursion of NAT and mobility in the
path between the MN's point of connection and the open Internet.  In
all cases, the MN establishes a 2-way tunnel to the TTR, and
everything will work fine.

>> Because Ran and I think you set such an elevated threshold
>> between "architecture" and "engineering" and since it seems the
>> details of the stack code fall into the latter - which you have
>> little interest in
> 
> False.   Do you understand how much code I've written?  And where
> it runs?  Hint: this message will not get to you without it.  ;-)

So I believe.  That's why I am perplexed that you go along with
claims of "crisp and clear semantics" for Locators and Identifiers,
when locally unique Identifiers lead to a horrible muddle between them.

You and Ran have consistently championed a "high-level", supposedly
"architectural" design process - leaving out all sorts of concerns
about details.

I guess that is how Ran started off with ILNP - globally unique
Identifiers = "crisp and clean semantics".  So far, so good.

But then, I guess, he added locally unique Identifiers, without
considering the details of this - how this completely destroys the
original "crisp and clean" semantics, and how messy it will be to
implement a stack which can do all this, while maintaining an
interface to standard IPv6 applications which respects their
expectations about the IP addresses the stack gives them, and which
the applications give to the stack.

>> - I don't think you have fully considered what a horror it will
>>   be to write this stuff, and somehow support existing
>>   applications with the assumptions they currently make about the
>>   properties of IP addresses.
> 

It looks very messy to me.  If you can do it without fuss, then good
luck to you!

>> I think you are failing to distinguish between what I am
>> discussing here - the "Identifier squatting" attack (1) - and
>> the matter of whether supposedly globally unique Identifiers
>> result from hierarchical assignment or are generated by each
>> host from a MAC address or the like (2).
> 

But how am I to respond if you repeatedly write in a manner which
indicates you do not understand the "Identifier squatting" attack,
and how it differs from LAN-based attacks involving MAC addresses?

>> It doesn't matter how you generate globally unique Identifiers
>> or whether or not they are in fact globally unique - the
>> "Identifier squatting" attack will still work.
> 

As above.

>> network to another (which may clobber the call, for all I know)
>> the situation with cellphone companies is rather different than
>> what would be required to protect ILNP from the "Locator
>> squatting" attack.
> 
> Incorrect.  You're correct about roaming dropping calls, but the
> ability of a handset to authenticate itself and have a unique
> identifier (IMEI) are well known.  In the cell world, the analog
> to the locator squatting attack resulted in theft of services, so
> non-cleartext link layer authentication was introduced.  We simply
> need the same.

As previously noted, link-layer encryption or authentication can't
protect against the "Identifier squatting" attack.  To do so, you
need an elaborate, global-scale, arrangement which would rely, I
believe, on hierarchically assigned Identifiers - as I explored in a
section of my previous message below.

>> The cellphone companies run their own access network so the
>> whole thing is integrated.
> 
> The architecture is almost identical to the Internet's.  Many
> different bands, several different protocols, all resulting in
> roaming with authentication and end-to-end calls.

Maybe so, but to prevent the "Identifier squatting" attack, each
access network needs to coordinate with a central hierarchy which
assigns Identifiers, as I described in my previous message quoted below.

>> Global mobility of the kind that ILNP aims to provide (as does
>> TTR Mobility, and now Fred Templin's IRON, using similar
>> techniques) requires that the host be able to use some access
>> network which has no relationship with the Mobility provider.
>> The access network cannot be assumed to have any special
>> mechanisms.
> 

TTR Mobility doesn't require any authentication or special
arrangements in the access network.  The MN needs to authenticate
itself to the typically nearby TTR, but that is not necessarily -
probably not - in the access network.

>> To prevent the "Locator squatting" attack, every protected
>> access network would need to prevent a host getting a lower 64
>> bits QQQQ until one of these was true:
>> 
>>     system, which I think would only be possible if all Identifiers
>>     were hierarchically assigned.)
>> 
>>     This would require an explicit negative response from a single
>>     global lookup system.
>> 
>>     Identifier.  Then the routing system needs to engage in a
>>     cryptographically secure exchange with the host, and probably
>>     with whichever organisation administers this part of the
>>     Identifier hierarchy, so that the host can prove it is
>>     authorized to use this Identifier.

This was my approach to protecting against the attack.

You added this, so I guess you think this is all that is needed:

> 3 - The host accessing the network was a cryptographically
>     authenticated known host, with a non-cleartext protocol, with
>     known host attributes, such as the MAC address and identifier.

This doesn't protect against the attack - your approach concerns
authentication between the access network and the host.  It doesn't
concern whether the lower 64 bits the host wants to use is an ILNP
Identifier, or whether this host is authorised to use this Identifier.

>> So this would involve retrofitting every IPv6 network which
>> could be used for mobility, in order to protect against this
>> attack.
> 
> Only if you care about secure mobility.  If you don't, you can
> visit Starbuck's today and squat away with IPv6 today.

The attack is not against the security of ILNP mobility.  It is a
Denial of Service attack against ILNP mobility.

>> I think you do not understand this attack.  It has nothing at
>> all to do with MAC addresses.  It is arguably spoofing an ILNP
>> Identifier, since there is nothing to prevent this from
>> happening at present.
> 
> I think YOU don't understand the attack.  If I sniff your IPv6
> address today and arrive at Starbuck's ahead of you, I've done
> _exactly_ the same thing.

At the time you wrote this, I believe you did not understand this attack.

  - Robin

---

From: Christian Müller <[email-masked]>
Date: Fri, 23 Jul 2010 21:28:11 +0200

Hi

> The transport will need to use L:I for locally unique IDs.
just another thought:
what happens if a mobile device (with a locally unique id) roams into a
subnet when there is a different device on that subnet already that uses the
same Identifier value?

chris

---

From: Tony Li <[email-masked]>
Date: Fri, 23 Jul 2010 16:13:21 -0700

Hi Christian,

> what happens if a mobile device (with a locally unique id) roams into a subnet when there is a different device on that subnet already that uses the same Identifier value?

Not much.  The device needs a new locally unique ID.  The one that it previously acquired only had local scope.

Tony

---

From: Robin Whittle <[email-masked]>
Date: Sat, 24 Jul 2010 16:32:55 +1000

Short version:  After 4 weeks of discussion, I think it is fair to
                conclude that ILNP can't provide global mobility in
                a robust manner.

                The idea of "mobility" with only an Identifier which
                is locally unique is not really "mobility".

There have been 33 messages in this thread since my first one:

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

which cited Xiaohu Xu's original critique, 4 weeks ago:

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

in which he proposed what I later called the "identifier squatting"
DoS attack.

In all these discussions I don't recall any evidence that this attack
is invalid.  There have been arguments that it is equivalent to MAC
stealing, but I don't accept this, since the victim's Identifier is
easily found by the attacker (from DNS lookup of the victim's FQDN),
because the attacker's action DoSes the victim in an entire /64, not
just a particular LAN within it and because the attacker's actions
are indistinguishable from the actions of an ordinary IPv6 or ILNP
host.  (MAC stealing involves learning the MAC number, which can only
be done from some LAN the victim host attaches to - and the attack
only works within the scope of a LAN.

Part of the discussion involved questions about relying on the
uniqueness of MAC addresses, or other identifying numbers for the
hardware the host runs on.  This is a separate question from that of
the "identifier squatting" attack, but several people noted that it
was not uncommon for MAC addresses to be duplicated.  Also, it was
pointed out that with virtual hosts, there may be no unique hardware
involved at all.

Another part of the discussion involved how to combine mobility -
implicitly global mobility of an Identifier - with some mechanism for
choosing multiple Identifiers in order to give the user "privacy".
"Privacy" in this sense means something like support for anonymous
browsing (but not just for HTTP, of course): being able to use a
series of Identifiers so as to avoid the sites they communicate with
comparing notes and recognising multiple sessions as having
originated from a particular host.  I think this is a separate matter
from the problem I was discussing, and I mentioned that I can't think
of any method, with ILNP - or any other architecture, including
today's IP protocols - of reliably achieving a "privacy / anonymity"
goal such as this.

Ran has not responded to this critique of the mobility aspect of his
architecture.  Tony has responded, but I don't think he denied that
the attack would succeed.  Steven Blake (msg07086) acknowledged the
attack exists.

The recent messages between Christian Müller and Tony Li concerned
the concept of "mobility" with an Identifier AAAA which is only known
to be locally unique - within a given /64 PPPP.  (So its IPv6 address
is PPPP-AAAA.)  When that host connects to an access network which
uses /64 QQQQ, it may find that it can't use its Identifier AAAA,
because some other host is already using it, either as an IPv-6 host,
or as an ILNP host. In both cases the IPv6 address QQQQ-AAAA can't be
used by our "mobile" host.

Tony acknowledges this:

>> what happens if a mobile device (with a locally unique id)
>> roams into a subnet when there is a different device on
>> that subnet already that uses the same Identifier value?
>
> Not much.  The device needs a new locally unique ID.  The one
> that it previously acquired only had local scope.

So this supposed form of "Mobility" may require getting a new
Identifier when using another access network.

This is not really "Mobility".  I think "Mobility" in the sense most
people have been aiming for in the context of the RRG is for the host
to retain its Identifier and maintain its sessions, no matter what
access networks it roams to.

TTR Mobility will provide this - by the mobile host retaining one or
more global unicast IP addresses, no matter what access network it uses.

ILNP could principle do it properly, if both these were true:

   1 - Each host has an Identifier which is truly globally unique.

   2 - There is some way of preventing any host on any access network
       it wants to use, from gaining the corresponding IP address
       first.

Regarding point 1, Tony and I think Ran have either argued against
the need for absolutely globally unique Identifiers, and/or have
argued that generating an Identifier from a MAC number (AKA
"address", though some people object to this term for MAC) or the
like will, for all practical purposes, achieve this.  If ILNP was to
be used, I think there would need to be a better way of choosing
Identifiers to be globally unique than relying on MAC number etc.
The only approach I can think of would be hierarchical assignment.
However Tony argued against this on grounds of privacy (anonymity) in
(msg07131) and because of problems with bureaucracy (msg07100).

Point 2 is the only way to prevent the "Identifier squatting" DoS
attack - and no-one has suggested a way of achieving this.

So I conclude that ILNP can't do global mobility in a robust fashion,
due to 2 above, and also due to reliance on MAC numbers and the like
leading to some probably low, but still unacceptable, level of
Identifier clashes.

Mobility with a locally unique Identifier is not mobility at all, at
least in the sense that most of us are aiming for.

 - Robin

---

From: Toni Stoev <[email-masked]>
Date: Sat, 24 Jul 2010 10:34:18 +0300

I agree.