On Tue, Jul 8, 2008 at 7:33 PM, Tony Li <[EMAIL PROTECTED]> wrote:
> |> Agreed.  The ability escape to a crypto-generated ID seems
> |like a sufficient
> |> mitigation, IMHO.
> |
> |Disagree for reasons stated in my other post. A client-side ID which
> |is either constant or predictable day over day has terrible privacy
> |implications.
>
> Ok, but if you've got an ID that is tied to public/private key pair, it
> would seem reasonable that you could change IDs as rapidly as you change
> keys.  If you feel the need to do so daily (or hourly), I don't see that
> that creates any architectural difficulties.

Hi Tony,

Actually, there's no real reason that anything operating as a client
has to have just one identity. For privacy purposes, it's better if
the node doesn't.

Given an appropriate mapping system, the layer 7 applications could
register and release as many identities as desired on whatever
schedule desired and then provide an appropriately selected identity
to layer 4. The identities are only required to survive for the
duration of a communication session.

Also, while the identities in the mapping system have to be globally
unique, the session identities do not. A connection-oriented session
could, for example, mention the global ID's during setup, agree on a
shorter session ID at the time and then use that session ID for the
duration of that session.


> |You're not supposed to be aggregating the identifier. You're not
> |supposed to be using the identifier in a manner where aggregation
> |would even be helpful. The Locater is supposed to aggregate with
> |topologically nearby Locaters while the identifier doesn't. That's the
> |whole point of the split.
>
> If a particular proposal chooses to use a structured, administratively
> assigned identifier then there will need to be hierarchy for managerial
> purposes.

DNS.

Regards,
Bill Herrin



-- 
William D. Herrin ................ [EMAIL PROTECTED] [EMAIL PROTECTED]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to [EMAIL PROTECTED] 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

Reply via email to