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

We trust the router to transmit packets. We have to, otherwise we would not get connectivity. We can actually verify that by observing that packets are received by peers on the other side of the network. Depending on our level of paranoia, we can use various levels of end-to-end encryption to verify that we are indeed speaking to the right peer. We can elect to stop attempting to send packets through a particular router if we are not getting the forwarding service.

Configuring the prefixes is very linked to the routing function, so we can trust a router when it tells us that he will serve a particular prefix. Again, we can verify that using that prefix provides end-to-end connectivity.

Trusting the router to transmit packets does not mean trusting the router form something else, like configuring my security posture. 

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Carlos Martinez-Cagnazzo
Sent: Friday, April 01, 2011 12:58 AM
To: Fernando Gont
Cc: ipv6@ietf.org
Subject: Re: draft-gont-6man-managing-privacy-extensions

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
=========================
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------