From: Moe Trin on
On Tue, 2 Feb 2010, in the Usenet newsgroup comp.os.linux.networking, in article
<hk9ttn$urc$2(a)usenet01.boi.hp.com>, Rick Jones wrote:

>It should be up to the client whether or not some portion of his IP
>address is given up the chain, not a server.

1. This is a _draft_ of a proposed RFC - it's a work in progress, and
must not be considered as anything solid. It's for hand-waving.
2. Have you read the draft? See section 8.1, specifically the second
and third paragraphs.

To protect users' privacy, Recursive Resolvers are strongly
encouraged to conceal part of the IP address of the user by
truncating IPv4 addresses to 24 bits. No recommendation is provided
for IPv6 at this time, but IPv6 addresses should be similarly
truncated in order to not allow to uniquely identify the client.

Users who wish their full IP address to be hidden can include an
edns-client-ip option specifying the wildcard address 0.0.0.0/0 (i.e.
FAMILY set to 1 (IPv4), NETMASK to 0 and no ADDRESS). As described
in previous sections, this option will be forwarded across all the
Recursive Resolvers supporting edns-client-ip, which MUST NOT modify
it to include the network address of the client.

Now, if your resolver or the immediate name server you are using
doesn't include this option (or set things to the designated wild
card), your address indications won't be included. I suspect the
kernel authors will include a flag in /proc/net/some_where/or/another
to control this.

Old guy
From: Moe Trin on
On Wed, 03 Feb 2010, in the Usenet newsgroup comp.os.linux.networking, in
article <4b69548d$0$26305$8404b019(a)news.wineasy.se>, David Brown wrote:

>Moe Trin wrote:

>> It certainly is a benefit to the advertising service, and the
>> company that is paying them to get the word of their products/
>> services to customers who may be interested.

>That's correct. And while I have no more love for the advertising
>industry than the average person, I have no objection to something
>that helps them if it does no harm to anyone else.

A lot of people don't understand a fundamental concept of the Internet.
It's a shared mechanism - but it has costs, and those costs must be
paid somehow. Using google as one example, _someone_ has got to be
paying the electricity, water, telephone, and Internet connectivity
bills, never mind paying for the hardware, building rent/mortgage,
and the cost of the staff. Money does not come out of mid-air. Even
the cost of the web-site run by your city library, or the pizza joint
down the street has to come from somewhere - increased cost of a pizza
or a lesser number of articles to lend out, somewhere!

>The only disadvantage is perhaps that it will lower the cost of
>advertising, and that might lead to more adverts.

Probably. It certainly won't be spent improving the quality of
the product, or the advertising.

>> Even the authors admit it's going to increase the caching load on
>> those DNS servers that may "support" clients in more than one
>> geographical area - the "OpenDNS" being one example. Depending on
>> what this service is actually used for, it can impact multi-national
]] networks.

>I can see it being a particular issue for OpenDNS. Since google has
>a rival system to OpenDNS, I suppose they are not going to be too
>concerned about that...

Hard to say - in the 'Attack scenarios' section of the 'Security
Considerations' section, they seem to be aware of abuse/problems.

>Surely in cases like this, you could simply continue to use your
>existing DNS servers and caches - you would then see no difference
>from the current situation. But if you decided to move to new DNS
>software with support for client IP tracking (perhaps to improve
>locality when accessing websites that run through big proxying
>companies), you'd need to arrange for it to work in your wide network.

o Recursive Resolvers implementing edns-client-ip should only enable
it in deployments where it is expected to bring clear advantages
to the end users. For example, when expecting clients from a
variety of networks or from a wide geographical area. Due to the
high cache pressure introduced by edns-client-ip, the feature must
be disabled in all default configurations.

I think one major unanswered question is what will the feature be used
for _besides_ delivering advertisements. "Regional" updates of software
doesn't sound likely - but what else is there?

>I don't expect that this will be a quick change - even if it gains
>popular support and the concept is refined so that "everyone" agrees
>on it,

[compton ~]$ zcat rfcs/rfc-index.01.15.10.txt.gz | sed 's/^$/\%/' | tr
-d '\n' | tr '%' '\n' | grep '^[0-9]' | tr -s ' ' | grep -v 'Not Issued'
| sed 's/.*Status: //' | tr -d '\)' | sort | uniq -c | column
172 BEST CURRENT PRACTICE 1732 INFORMATIONAL
141 DRAFT STANDARD 1974 PROPOSED STANDARD
321 EXPERIMENTAL 89 STANDARD
216 HISTORIC 909 UNKNOWN
[compton ~]$ zgrep -c 'draft-' rfcs/drafts/1id-index.01.15.10.txt.gz
1680
[compton ~]$

A lot of drafts get proposed, discussed, modified, and so on, and some
eventually get adopted while others silently time out and disappear.
But I think I need to see more about this before I reach any decision.
I especially want to see where this feature is going to be a benefit to
_me_ (selfish, I know).

Old guy
From: Rick Jones on

If a portion of the end-client IP address is filtering past the first
recursive server, isn't that giving somone watching the traffic that
much more information about where people are going and what they are
interested in? Not necessarily just advertisers.

rick jones
--
portable adj, code that compiles under more than one compiler
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Rick Jones on

If it actually requires an active opt-in on the part of the end user
before this functionality kicks-in, then my concern is addressed.

rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Pascal Hambourg on
Hello,

Moe Trin a �crit :
>
> Now, if your resolver or the immediate name server you are using
> doesn't include this option (or set things to the designated wild
> card), your address indications won't be included. I suspect the
> kernel authors will include a flag in /proc/net/some_where/or/another
> to control this.

Huh ? What does the kernel have to do with DNS ?
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: NAT hole punching
Next: Possible iptables logging trojan?