Re: [RRG] Re: ILNP Critique

[Steven Blake <slblake@petri-meat.com>]

Ran,

I think some of the confusion surrounding the details of ILNP are the
result of my presentation of your slides in Dublin.  Specifically,
although I might not have said that ILNP *mandates* that applications
adopt a new API, I'm pretty sure I suggested that it was a very good
idea (and although I don't believe that apps *have to* use the new API,
to realize the benefits of ILNP, at a minimum I think the current socket
API implementation needs to change).

Another point I made, in response to a question as to how two nodes
simultaneously moving could maintain communication, is that the DNS can
be thought of as a mobility rendevous service.

So in this instance, feel free to blame the messenger!

More comments below.

On Sat, 2008-10-04 at 14:56 -0400, RJ Atkinson wrote:

[snip]

> % I recall a lot of discussion about the problem of ensuring 64 bit
> % identifiers are unique in the world.  Your proposal (page 4) does
> % not ensure an identifier is unique, except in the scope of a 64 bit
> % identifier.
> 
> [draft-rja-ilnp-intro-01, pages 4 and 5]
> 
> I have consistently said for ~15 years now that identifiers
> are not required to be globally unique, but that instead the
> functional requirement is to have "probably unique" IDs.
> 
> HIP is taking roughly the same position.  HIP identifiers can
> collide (e.g. due to a hash collision).  As with ILNP IDs,
> such a collision is unlikely.
> 
> If one wants a globally-unique ID, this is straight forward to
> obtain from any system with an IEEE Ethernet or Firewire
> interface. In this case the scope bit of the EUI-64 is set to
> "global".  [draft-rja-ilnp-intro-01, pages 4 and 5]
> 
> If one wants anonymous IDs, with the increased probability of
> collision manual selection implies, that can be done by setting
> the scope bit to "local" and generating 62 bits in whichever way
> one chooses.

aka RFC 3041.

> Similarly, one can have an ID that is derived from the hash of a
> public-key, as HIP does, by setting the scope bit of the EUI-64
> to "local".  Again, since there are 2 reserved bits in an EUI-64,
> one has 62 user-selected or hash-output bits left.
> 
> (In fact, I think ILNP can be engineered to provide all of the
> capabilities of HIP as a deployment option.  Both HIP and ILNP
> were born in the IRTF Namespace RG.  Both were significantly
> influenced by the earlier GSE work by O'Dell.  So the
> similarities between ILNP and HIP are not at all surprising.
> There are also some obvious design differences. :-)

As we have discussed, I don't think the major concern is the probability
of accidental identifier collision, but instead the possibility of
identifier spoofing as a means to launch DoS attacks.  In ILNP
identifiers are much easier to spoof than addresses in IPv4 or IPv6.

With that said, there is more than one way to protect against this, some
of which might affect the protocol specification, and some of which are
purely implementation tricks.

[snip]

> % I think this means that you can't support multihoming or
> % whatever benefits for communications with non-upgraded hosts.
> 
> (I am unable to really understand/parse/lex the quoted sentence
> above.  Terribly sorry.)
> 
> Communications with existing nodes works the same as it does
> today.  Communications with existing nodes is no worse than at
> present, which is the functional requirement here.

Well, to be fair, communication between an ILNP node and a non-ILNP
node, where the ILNP node has PA locators, wouldn't work as well as
communication between two nodes each with PI addresses.

The aspect that I especially appreciate about ILNP, however, is that,
like TCP SACK, or ECN, or SHIM6, or HIP, it is relatively cheap to
deploy locally, and benefits accrue to any two communicating hosts which
both support it, without requiring changes in the core infrastructure,
and without degrading communications with non-ILNP nodes. This was not
true of GSE.


Regards,

// Steve


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg