Re: draft-gont-6man-managing-privacy-extensions

Carlos Martinez-Cagnazzo <carlosm3011@gmail.com> Fri, 01 April 2011 07:57 UTC

Return-Path: <carlosm3011@gmail.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFEE328C103 for <ipv6@core3.amsl.com>; Fri, 1 Apr 2011 00:57:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePZVEAHtHGsD for <ipv6@core3.amsl.com>; Fri, 1 Apr 2011 00:56:43 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8247528C0EE for <ipv6@ietf.org>; Fri, 1 Apr 2011 00:56:43 -0700 (PDT)
Received: by iwn39 with SMTP id 39so3740523iwn.31 for <ipv6@ietf.org>; Fri, 01 Apr 2011 00:58:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=skRADLSo1ZjaUj89j/MJa1HTzaXggDDJtXydf0HK720=; b=QoWkbXorizik+dZYJlIQYObfaWhnJyJMLrTzjL3vr6P/78y2GAb2u+bTGKOPF6ygo/ Q+fOSciWbCAlfSAA+OYVcempeYq0opOOCI5nwMcb+6AIJLb9CylbeesKzXo8IAX/QUIw KCQR+vYBfF226v7QBgrcgaQdvPdkB7dzGYoSY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=VBUmBoSwZZzHB47QDpOwoOTmZ5yU3+IygRiRPBv3O8mqPvDI+TPdvI9j7Scw6idmFn MSzk+yWzPNn4fE6vyaq1P1ibzxJFUzzvY1PMiF+mYBF5G3x7CtTKB0RWSkQHMJTe+8Vn uTPwNBiT2gzOZVAocLG4+8T594IgpsnNLaTbE=
MIME-Version: 1.0
Received: by 10.43.53.133 with SMTP id vq5mr4262753icb.527.1301644703410; Fri, 01 Apr 2011 00:58:23 -0700 (PDT)
Received: by 10.42.211.10 with HTTP; Fri, 1 Apr 2011 00:58:23 -0700 (PDT)
In-Reply-To: <4D9361F8.60203@gont.com.ar>
References: <4D9361F8.60203@gont.com.ar>
Date: Fri, 1 Apr 2011 07:58:23 +0000
Message-ID: <AANLkTi=fPWLVJ4tF2oZMH_AEiWW_DTOXrgPae2tA6+R-@mail.gmail.com>
Subject: Re: draft-gont-6man-managing-privacy-extensions
From: Carlos Martinez-Cagnazzo <carlosm3011@gmail.com>
To: Fernando Gont <fernando@gont.com.ar>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: carlos@lacnic.net
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Apr 2011 07:57:01 -0000

Hi all,

I do agree with Fernando that we need to be more clear on the trust
models that we apply ( I don't think this is an issue only on 6man,
it's a general thing ).

If we distrust some network element, then we distrust it for *any*
purpose, not just for this or that bit. In this particular case, if we
distrust the router we need to consider that a rogue router could do
well, almost anything, including just capturing all your packets and
uploading them to some place.

I'm not saying that concerns on trust boundaries should then be
dismissed, but rather than we need to be more strict about them. We
trust the network element or we don't, we can't trust it for some
features but not for others.

regards

Carlos

On Wed, Mar 30, 2011 at 5:01 PM, Fernando Gont <fernando@gont.com.ar>; wrote:
> Folks,
>
> At the 6man wg meeting, the aforementioned I-D was deemed "as a very bad
> idea", because of its privacy implications.
>
> My question is: what's the trust model that leads to that conclusion?
>
> I mean, a host doing SLAAC trusts the router about the prefix to be
> configured, default route, various network parameters (Hop Count, MTU,
> etc.), recursive DNS resolver, etc.
>
> Why do folks consider that for some of this information, the router is
> to be trusted, while for other (the SAG bits that our I-D specifies)
> shouldn't?
>
> That aside, if a router is deemed as possibly malicious, even without
> the SAG bits it could claim that DHCPv6 is needed, and then have the
> DHCP server lease an address that embeds the source link-layer address
> of the DHCPv6 request...
>
> *And*, as noted in the upcoming version that I had posted, the final
> decision on which policy to apply is on de hands of the host (and not
> the router).
>
> Thanks,
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@acm.org
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=========================