Re: [VIPR] VIPR privacy issue

Are there viable candidates to displace RELOAD that could be shovel-ready within the acceptable event horizon?

Kurt Bergsbaken | Architect -SIP Voice Services | Univision Communications Inc. | 8550 NW 33rd Street, Miami, FL 33122
Direct: (305) 463-5745 | Fax: (786) 515-9229 | kbergsbaken@univision.net | www.univision.com

----- Original Message -----
From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: Thursday, January 26, 2012 04:49 PM
To: Marc Petit-Huguenin <petithug@acm.org>
Cc: vipr@ietf.org <vipr@ietf.org>; Dean Willis <dean.willis@softarmor.com>
Subject: Re: [VIPR] VIPR privacy issue

Unfortunately, options 2 and 3 introduce delays that decrease the
relevance/utility of VIPR , which in my view has significant near term
(i.e., now) value, but in the long term is likely to be far less
useful.

Mary.

On Thu, Jan 26, 2012 at 3:38 PM, Marc Petit-Huguenin <petithug@acm.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 01/26/2012 01:28 PM, Dean Willis wrote:
>>
>> On Jan 26, 2012, at 10:40 AM, Richard L. Barnes wrote:
>>>
>>>
>>> Like I said, the mitigation here is the same as any situation where you
>>> want to hide your IP address: Send packets from a different network.
>>
>>
>> So we should run a great big VPN in order to run RELOAD in order to run
>> ViPR?
>>
>> Great! Now all we need is a peer-to-peer VPN capable of obscuring the IP
>> addresses being used.
>>
>> I'm trying to imagine just how badly the universe would break if one tried
>> to run RELOAD over TOR. I don't think I have that good an imagination,
>> because scenes from the movie "2012" pale by comparison, and I'm sure the
>> real situation would be far worse than what I imagine.
>>
>> But this does all come back to why I haven't been able to convince myself
>> of the real-world utility of ViPR. We're layering vast complexity onto what
>> is basically a distributed  trust-anchor problem, where the easiest thing
>> to do in the real-world is to have a centralized anchor (which might itself
>> refer to the PSTN basis anchor).
>>
>> How about an alt-root DDNS/ENUM server that itself uses PSTN reachability
>> to verify registrations submitted via DDNS?
>
> That may be worth investigating, but the first thing that the WG should
> answer, IMHO, is do we want to 1) give up, 2) delay for RELOAD, or 3) replace
> RELOAD?
>
> - --
> Marc Petit-Huguenin
> Personal email: marc@petit-huguenin.org
> Professional email: petithug@acm.org
> Blog: http://blog.marc.petit-huguenin.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQIcBAEBCAAGBQJPIcfqAAoJECnERZXWan7E6sQP/2jBmenEmlsQ+Pe5V1F/qn7e
> kSQjw6EuUGKjz5oONhsbEw2N4kAHwtivQlfriJoT4NxeYspWWvg+13Btb4+OlTFU
> QNAU9rY0Zd+AZJvFBII70TGjKl5aRZ5G7LRmgfsyp88OAODs9FtHRVzTtQVSTbEV
> ZYWtzYXRWcYosH+9sML7vFn8gf5njDsR0pTEV1Xt+DVdVbec+MV35zHmX8gOtR84
> +s/LalXe8rPUdmDV7qAHHZir9gCj2FmSuJlb2KGr3IfEj+mD1FeRTfsN8bhtE0zZ
> cfg8yAYjLgvNy7O7ZXFN8GIQx40StJqRXCxuzrJ0CHHDlS3NJ8vv8IVM8mlMIt0d
> UaHnC4DcU3yQGFNGe+f3cG1KrtAIsDTUJyyppsra4Q41dP4eporG8uWZDbIJwDMI
> Jg7nwSJD6RJ8qL6zgWl1gNyfRXOKG3s3Wt8Oy/l00Q837N8+KxGRA7WeEu0PMjkR
> 8d1C/i4dPymKVA5FsdPatG+/dHee8FzbYKriGOmCXsGhx5+rcW3m3tVE+lpzqBZ9
> 0dysmnJmjNJUcsHIp+o+CWKd5FcSewxfNMHy762lmJME7srDVzENd8rWi5luHVWn
> k1KviQe82XaV6PhKb6/K3rSSotNAPKwkSiIvSsuaOeDv1Wmzi472Mp/BX0M2/s9p
> 5hv+PEtbfXzcNBh+zW3r
> =OqpG
> -----END PGP SIGNATURE-----
> _______________________________________________
> VIPR mailing list
> VIPR@ietf.org
> https://www.ietf.org/mailman/listinfo/vipr
_______________________________________________
VIPR mailing list
VIPR@ietf.org
https://www.ietf.org/mailman/listinfo/vipr

The information contained in this e-mail and any attached 
documents may be privileged, confidential and protected from 
disclosure.  If you are not the intended recipient you may not 
read, copy, distribute or use this information.  If you have 
received this communication in error, please notify the sender 
immediately by replying to this message and then delete it 
from your system.