Subject: Re: [homenet] privacy vs subnet-id

From: Randy Turner <[email-masked]>
Date: Mon, 14 Nov 2011 22:54:15 -0800

Homenet admin?

Randy

-------- Original message --------
Subject: Re: [homenet] privacy vs subnet-id 
From: Brian E Carpenter <[email-masked]> 
To: Tim Chown <[email-masked]> 
CC: "[email-masked] Group" <[email-masked]> 

On 2011-11-15 16:03, Tim Chown wrote:
> So at the moment all the arch text says on privacy is:
>    Privacy considerations
> 
>       There are no specific privacy concerns for this text.  It should
>       be noted that most ISPs are expected to offer static IPv6 prefixes
>       to customers, and thus the addresses they use would not generally
>       change over time.
> What would you like to say here instead?

Maybe point out that a homenet can be protected against external privacy
threats (possibly citing 4864 etc) but that whatever hosts do, the homenet
admin has the capability to perform traffic analysis down to the subnet level.

    Brian

> 
> Note 4941 isn't just about source address from location to location but also source address over time.
> 
> The LNP for IPv6 text (RFC4864) talks about this issue a bit, but this is more about obfuscating the topology externally to the user's network, rather than internally.   In my view we should probably only consider a similar perspective here?
> 
> Tim
> 
> On 15 Nov 2011, at 02:53, Brian E Carpenter wrote:
> 
>> On 2011-11-15 15:26, Michael Richardson wrote:
>>> Brian Carpenter raised the point at the mic that we have to pay
>>> attention to privacy when it comes to the subnet-id.  We shouldn't make
>>> it possible for members of the household to spy on each other.
>>>
>>> My understanding of the purpose of RFC4941 privacy extensions is to make
>>> is hard for an (off-path) observer (including web server operator) to
>>> trivially track a user from location to location by their EUI-64. 
>>>
>>> The question is, do we have any similar requirements that we want to
>>> apply to subnet-id.  The example that Brian gave in XMPP was:
>>>
>>> BEC> And if you have a separate subnet for the kids' bedroom...
>>> BEC> 'Honey, one of the kids is using Facebook again'
>>>
>>> if there is only one possible host on a particular subnet, then RFC4941
>>> can't help disguise who is doing what.  
>>>
>>> My question is: what is the real issue here.  It seems that the kind of
>>> things that 4941 deals with, are neither better nor worse.  But maybe
>>> there are other things that we need to concern ourselves with.
>> Waxing philosophical, you can obfuscate an ID but you can't obfuscate
>> a locator. I really don't see a way out of this. If the admin can
>> run Wireshark, she can see the locator.
>>
>>    Brian
>> _______________________________________________
>> homenet mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/homenet
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/homenet

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Nov 2011 20:57:01 +1300

The responsible parent, for example, who does not want to
be fined for their kid's illegal downloads.

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Nov 2011 10:36:23 -0500

>>>>> "Brian" == Brian E Carpenter <Brian> writes:
    Brian> The responsible parent, for example, who does not want to
    Brian> be fined for their kid's illegal downloads.

So, something that we could specify is some way to name the subnets,
and to communicate from the CPE router to the ISP about what is what,
particularly in the case where the CPE router is provided by and/or
partially managed by the ISP.

The goal here is to give the ISP some information the network topology
so that the ISP and the responsible parent can more easily work out who
is being complained about.  

Said communication doesn't necessarily mean a protocol between the CPE
router and ISP (although it could via INCH or MILE).  It could be as
simple as deciding upon a clear human readable textual description of the
network, something the responsible parent can copy&paste from a web
interface to an email with the ISP.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Randy Turner <[email-masked]>
Date: Tue, 15 Nov 2011 08:26:23 -0800

Once HomeNet is "figured out", a real subsequent challenge will be to address how to translate any leftover configuration required for the end user.  This would be anything we couldn't figure out how to auto-configure. By "translate" I mean translating any geek-speak config concepts into equivalent mass market concepts that can be easily grasped by the average consumer. If we can't figure this out, and the resulting model has too much policy or buttons and levers to manipulate, then we're probably setting up a nice managed service offering for an NSP.

Randy

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Nov 2011 13:49:42 -0500

{why am I top-quoting?}

So, I agree with you about translating terminology, or at least, picking
sufficiently unique (and multicultural) terminology such that the terms
can be used unambiguously.

The scenario I have in mind is:
    1) ISP gets an abuse complaint about IP 
         2001:DB8:f00d:5634:0243:60ff:fefa:8842

    2) ISP maps this via 2001:DB8:f00d:56/56 to customer FOO.
    3) ISP contacts customer FOO about this issue, noting that
       it's on subnet-id "34".  No end-user is going to know 
       what "34" is, nor what "0243:60ff:fefa:8842" is, and
       given privacy extensions, that might be more random.

So the question is, can we have a way for CPE router to unambiguously
record/communicate that subnet-id is "34" was assigned to "wifi guest
network" on ESSID "garage-party".

Customer then says, "Oh, yeah, last Tuesday, my friend Bob was over,
but he is gone now", or "the garage? Oh wait.  Is that my new PEV Volt?
I guess I need to take it to shop for trojan removal"

>>>>> "Randy" == Randy Turner <[email-masked]> writes:
    Randy> Once HomeNet is "figured out", a real subsequent challenge
    Randy> will be to address how to translate any leftover
    Randy> configuration required for the end user.  This would be
    Randy> anything we couldn't figure out how to auto-configure. By
    Randy> "translate" I mean translating any geek-speak config concepts
    Randy> into equivalent mass market concepts that can be easily
    Randy> grasped by the average consumer. If we can't figure this out,
    Randy> and the resulting model has too much policy or buttons and
    Randy> levers to manipulate, then we're probably setting up a nice
    Randy> managed service offering for an NSP. 

    Randy> Randy

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Nov 2011 06:41:24 +0800

> {why am I top-quoting?}
I don't know. 

> network" on ESSID "garage-party".

It would certainly be handy if the homenet populated a reverse DNS tree that could be queried.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Nov 2011 18:00:13 -0500

>>>>> "Ted" == Ted Lemon <[email-masked]> writes:

    Ted> It would certainly be handy if the homenet populated a reverse
    Ted> DNS tree that could be queried.  

I (you should well remember), as the author of RFC4025, am the biggest
fan of reverse DNS(sec).  (No sarcasm here!!!)   I very very very much
want this tree delegated and populated for home networks.

However, a fully populated reverse DNS, but won't help us when we have
systems with privacy extensions enabled.  

Worse, it won't help us if the machine has moved on, and the DNS has
been updated.  What we have is a locator for the network, and we need
to be able to translate that to human comprehensible form.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Nov 2011 07:15:50 +0800

> systems with privacy extensions enabled.  

True

> to be able to translate that to human comprehensible form.

The IP address came out of a log. Presumably the log could have done an RDNS lookup...

But yeah, I don't claim this is a panacea; just potentially interesting, and a possible motivator for populating the RDNS tree.