Re: [VIPR] VIPR privacy issue

Mary Barnes <mary.ietf.barnes@gmail.com> Thu, 26 January 2012 21:49 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: vipr@ietfa.amsl.com
Delivered-To: vipr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2235921F8794 for <vipr@ietfa.amsl.com>; Thu, 26 Jan 2012 13:49:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.71
X-Spam-Level:
X-Spam-Status: No, score=-103.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hCUmhxrbK64 for <vipr@ietfa.amsl.com>; Thu, 26 Jan 2012 13:49:25 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4709821F8792 for <vipr@ietf.org>; Thu, 26 Jan 2012 13:49:25 -0800 (PST)
Received: by vcbfk14 with SMTP id fk14so842679vcb.31 for <vipr@ietf.org>; Thu, 26 Jan 2012 13:49:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZEENhQ4ffjRj3q9Zh5uScDhyzofdcLoW9rssUgD7g48=; b=JVGjJh0V2FzZV12nMWjb7uo/vKJAtLwEyznN0tF16Xitqr6wruyUehllBTzZ65AYRW R0j/SIlx68JrArTIICpEKsy71alynjpxQucibF+bhXOoLfBkmvjyhlaZcv+wrSBNzfiK da4L3dsdbBLmwJ5xPjKuLtMayQb4yPU3s5K84=
MIME-Version: 1.0
Received: by 10.220.148.138 with SMTP id p10mr2143782vcv.28.1327614562921; Thu, 26 Jan 2012 13:49:22 -0800 (PST)
Received: by 10.52.108.196 with HTTP; Thu, 26 Jan 2012 13:49:22 -0800 (PST)
In-Reply-To: <4F21C7EC.2000201@acm.org>
References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <92E46A75-E370-4A52-BF04-F2D811D3C0C0@softarmor.com> <4F21C7EC.2000201@acm.org>
Date: Thu, 26 Jan 2012 15:49:22 -0600
Message-ID: <CAHBDyN5k80ijGBR4LuA+4E-XsA4Sxe=Hv-VWt5tZH6JHd9DLhw@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Marc Petit-Huguenin <petithug@acm.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "vipr@ietf.org" <vipr@ietf.org>, Dean Willis <dean.willis@softarmor.com>
Subject: Re: [VIPR] VIPR privacy issue
X-BeenThere: vipr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Verification Involving PSTN Reachability working group <vipr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vipr>, <mailto:vipr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vipr>
List-Post: <mailto:vipr@ietf.org>
List-Help: <mailto:vipr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vipr>, <mailto:vipr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jan 2012 21:49:26 -0000

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