Re: [dns-privacy] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10

[Lanlan Pan]

Hugo Connery 于2018年12月1日周六 下午8:41写道：

> Hi Karl and list,
>
> No and Yes.
>
> The introduction section says "out of scope" not "there are
> different attack vectors and operational concerns".
>
> ... and then I got to thinking.  (sorry about that)
>
> But, I do agree that there are differences between the types
> of attackers for recursers and authoritatives based on the
> different outcomes of complete loss of service.
>
> Recursive resolvers serve a wide variety of stub resolvers
> over varying operating systems from some network(s), which the
> operator gets to choose, but the resolvers need to be within those
> network(s).  Some companies choose to offer recursive resolvers
> that serve the entire internet (8.8.8.8, 1.1.1.1 etc.), but these
> are currently the tiniest minority of recursive resolvers (*),
> though this is likely to change with "recurser as a service".
> The consequence of total failure of these resolver services for
> the community within those network(s) is "the internet does
> not work" (for them).
>
> So, a recursive operator chooses which community (via networks)
> they serve, must be amongst those networks, and the consequence
> of loss of service is "the internet does not work" for clients
> within those networks.
>
> An authoritative server is different.  It does not get to choose
> its community.  Ostensibly it is serving recursive resolvers (**),
> but they could be anywhere, so this amounts to serving the
> global internet.  But, the authoritative servers can be in any
> reachable network.  The consequence of loss of all authoritative
> resolvers for a collection of zones is that the services described
> in its zones become increasingly globally unavailable as caches
> of its records expire.
>
> So, an authoritative operator must serve the entire internet,
> can be anywhere, and the loss of service is "these sites dont
> work" progressively for everybody.
>
> >From this we can see who is motivated to attack what.  By attack
> I mean limit or completely prevent service delivery by
> non-military actors.
>
> Notably, recursive resolvers that serve networks that are
> limited geographically to a nation state have no defence
> against the government of that nation state, but authoritatives
> can skip around to avoid government attacks (aka laws).
>
recursive should send less sensitive data to authoritative servers.

>
> Many governments and corporations attack recursors for censorship
> purposes with political and/or cultural motives (see "Pirate Bay").
> Authoritative regimes may wish to remove all (public) recursors
> to create an internet blackout, but this is countered by (*)
> above so they have to prevent access to the globally reachable
> resolvers too (see "Great Firewall").
>
> Authoritative resolvers may be attacked by extortionists for
> money or miscreants for fame (see DDOS), or by competitors of
> services described in the zone(s) for competitive advantage (see
> "this is never published/I've got a furtive imagination").
>
> So, yes the threat landscape is different because the consequences
> of loss of service are different.
>
> Note that adding encryption or session based query services
> for authoritatives changes none of this and is countered by
> money (more CPU/RAM etc.).  Obviously, authoritative operators
> are legitimately motivated to minimize this burden (and should
> carefully review proposed changes so that no new attacks methods
> are admitted by new standards).
>
> One of the defences for authoritatives is to prioritise serving
> recursive resolvers, as they are their legitimate clientele (**).
>
yes,  authoritative can caculate a trust level  to the query clients, to
prior serve the "truely" recursive resolvers, which is learned from the
query log.

>
> One can identify recursive resolvers because they will honour
> your TTL values and will be a sparse collection of addresses
> within network(s).  This is not a perfect protection because
> recursers can "go rogue" (cracked) or deliberately behave nicely
> for a while (planned attack), but it should help with DDOS type
> attacks that are not well planned.  Similarly, you can grade
> your deliberate refusal of service to network(s) when under attack
> from them.  Refuse service to all not already known recursers
> for a while before refusing service to the entire network(s)
> if the initial service restriction doesn't help.  But, if that's
> the case, you have a good idea who is attacking you from those
> network(s).
>
> Regards,
>
>   Hugo Connery
>
> On Fri, 2018-11-30 at 19:13 +, Henderson, Karl wrote:
> > Hi Paul,
> >
> > The attack vectors and operational concerns are different for
> communication between the recursive-to-authoritative than for communication
> between the stub-to-recursive. For instance, a stub will
> > typically communicate with one or two recursive resolvers while
> recursive resolvers may communicate with many authoritative resolvers -
> thus changing the nature of persisten

Re: [dns-privacy] User Perspective

[Lanlan Pan]

clients hide on proxy,  but still get the specified network topological
close response.

Brian Haberman 于2018年7月20日周五 上午2:24写道：

> This thread is for discussion of the user perspective of DNS privacy
> between the recursive resolver and authoritative servers.
>
> - Focus on *what* is needed.
> - Avoid *how* to achieve it.
> - Consider both ends of DNS the exchange.
> - Scenarios will frame the discussion.
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Still interested in recursive-to-authoritative

[Lanlan Pan]

Support, :-)


*”Encryption does not protect against a rogue server that will capture you
requests and use them for evil purposes.It must therefore be combined with
data minimization techniques.“*

Paul Hoffman 于2018年5月17日周四 上午4:03写道：

> While we wait for the charter update, I'd still like to find out who is
> interested in pursuing draft-bortzmeyer-dprive-resolver-to-auth.
> Personally, I think it is a good start on an important topic, but I
> don't hear others supporting it on the list...
>
> --Paul Hoffman
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Oblivious DNS

[Lanlan Pan]

Christian Huitema 于2018年4月10日周二 上午2:44写道：

> On 4/9/2018 11:00 AM, Warren Kumari wrote:
>
> On Mon, Apr 9, 2018 at 1:53 PM Christian Huitema 
> wrote:
>
>> At first sight, it seems that this moves the logging hole from the DNS
>> recursive to the ODNS recursive, and that's a meh.
>>
>> Also, instead of using a complicated tunneling through the recursive
>> resolver via name obfuscation, why not establish a secure connection to the
>> ODNS server in the first place?
>>
>
> The ODNS server doesn't know the client IP (it gets occluded by the
> rescursive server), and the rescursive doesn't know the question. This is
> kinda somewhat similar to the Tor model.
>
> This is a fairly common question - I think that the ODNS documents /
> people should clarify this better..
>
>
> They should really clarify the problem that they are addressing. As Shumon
> said, if the goal is to hide the source IP address from the recursive
> resolver, then it seems that "DNS over onion routing" would be easier to
> engineer and deploy than "oblivious DNS".
>
> They should also clarify the use of symmetric key encryption. Is the
> symmetric key specific to a client-server pair, or is shared by the server
> with a large group of clients? If the key is specific to a client, then it
> identifies the client even if the IP address is hidden. If the key is
> widely shared instead, then it takes only one bad client for the key to
> leak, and the traffic logs at the recursive DNS can be de-obfuscated.
>
> From an engineering point of view, I am concerned with applications of
> encryption to small size objects like name part or IP addresses. Modern
> symmetric algorithms operate on 128 bit blocks, with mainline AEAD
> encryption adding 16 bytes of overhead to the object. That's bad enough,
> but asymmetric algorithms are even worse. Even if you use Elliptic Curve
> crypto, the smallest practical key is 256 bits, or 32 octets. The overhead
> will make that impractical. If we happen to need longer keys it will just
> not fit in the 63 octets of a domain name part, even if we found a way to
> not require Base64 encoding. I am much more confident that we can solve the
> engineering issues if we develop an encrypted transport with onion routing.
>

I designed another EPT asymmetric tunnel extension in 2017:
https://github.com/abbypan/dns_test_ept

Use EDNS padding to lighten the length limit (but recursive must forward
the padding), use XOR_IP to obscure the A RR.

The problem I want to address seems similar to ODNS.


>
>
> -- Christian Huitema
>
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

[Lanlan Pan]

Hi Barry,

There are complex factors to optimize the datacenter connection of CDN.
I know every CDN need "Everything is in IP, RIPs, FIBs, AS Patch, system
load, content availability, etc." to measure better path calculations.
I understand that "Knowing that it is in Palo Alto California" is not
something useful for Data Provider path calculation, load balance
optimization, etc.
Note that, I *DON'T* mean that knowing  is
sufficient for CDN.

But, as you methioned in last mail:
*>  Once the connection to the client to the CDN is made, the CDN
operator has the full details of the client. *
CDN can known "Everything is in IP, RIPs, FIBs, AS Patch, system load,
content availability, etc." without ECS.
CDN can do the BGP optimization and datacenter load balance without ECS.

*Sperate the consideration of datacenter path calculation (Data Provider)
and dns response (AUTH).*

   - Data provider can make datacenter path calculation without ECS because
   all clients will connect.
   - ECS is help AUTH to return the satisfied dns response to client.

Therefore, the question is, *what can help AUTH to decide the response* ?
I mean that, most of time, knowing  is sufficient
for AUTH make dns response.

My statement Is, for example:
the subnets (subnet_1 ... subnet_100) in the same 
geolocation, always visit the same CDN datacenter sets (DC_1 .. DC_2) .
datacenter sets can be changed when network status is varied, network path
connection latency become larger, load balance adjustment, etc...
EIL is sufficient if AUTH make dns decison on 
geolocation pricise level.

If your operational realities is:
subnet_1 ... subnet_100 in the same  geolocation,
you apply subnet_1 ... subnet_50 visit DC_1, subnet_51 .. subnet_100 visit
DC_2
ECS is satisfied with your statement, because your AUTH make dns decision
down to subnet pricise level.

Barry Raveendran Greene 于2017年3月24日周五 上午2:06写道：

>
> > On Mar 21, 2017, at 11:38 PM, Lanlan Pan  wrote:
> >
> > However, if you know about the geolocation ,
> you can make a better response, most of time, is the best response too.
>
> Your statement is not matching the operational realities I live in. I
> understand how mapping is done in my current environment. I understand how
> it is done in many of my peer CDNs. I also understand the tools I would
> need to measure better path calculations. Everything is in IP, RIPs, FIBs,
> AS Patch, system load, content availability, etc. Knowing that it is in
> Palo Alto California is not something useful.
>
> What is needed is the allocated IP block to start the mapping
> determination. Then every CDN does their “secret sauce” to delver the best
> customer experience. Geographic location is just not one of those factors.
> ECS delivers this now.
>
>
>
>
>
> --
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

[Lanlan Pan]

on more and more. They call that geolocation
lookup, geolocation routing, geolocation delivery, and so on.

I AGREE WITH this sentence of your post :
*it has never been wise to assume that a DNS request's IP source address
gives any hint of an end-system Web browser's network location.*
This assumption is not correct in theopy, but the reality is that almost
all smart-auth-dns-resolution working based on this assumption.
So I support ECS's idea : give more precisely information to AUTH.

In the mid-1990's,  DNS is pure. Not work with CDN that contains 50+
datacenters to choose for dns response.
In the mid-1990's,  there is not public recursive resolver. Not increase
the distance between client ip and resolver ip.
Consider about these nowadays problem,  ECS is designed, partly change
traditional dns query, *give addtional subnet information for AUTH to make
a better decision*.
ECS can make DNS query & response more satisfied with nowadays content
delivery ( one domain -> multiple servers distributed in different location
datacenters ), if they don't deploy ip anycast.

Again, as I methioned above, AUTH actually use ECS subnet information
mapped into geolocation information, then make dns decision.



*Why I think EIL can make some revisions to ECS ? *
EIL : We tell Authorative servers that, "*I want to know what is most
satisfied ip address for clients from (CHINA, BEIJING, UNICOM) at network
topology distance*".  The (CHINA, BEIJING, UNICOM) is geolocation,  but
AUTH decide dns response by network topology distance between the
geolocation nodes.

   - *Privacy*:  The biggest privacy concern on ECS is that client subnet
   information is personally identifiable. EIL adjust the sensitive client
   subnet information to aerial view geolocation information for user privacy
   protection.


   - *Operation*:  In P-model (details in my *Paper
   <https://drive.google.com/open?id=0B5gNT4RRJ0xPaG9nZ045VXRrZzg>*), EIL
   move back the "guess geolocation of client’s IP" work from authoritative
   server to public recursive resolver, lighten the burden of authoritative
   server. Anyway, the origin of user latency problem is the public recursive
   service providers couldn't deploy servers in every country and every ISP's
   network.
   - *Cache Size*:  The cache size of ECS grows up with the number of
   client subnets. under future IPv6 environment, huge number of subnet,  the
   cache size of EIL will be smaller than ECS.


Paul Vixie 于2017年3月22日周三 下午6:54写道：

> Lanlan Pan wrote:
> > ... Because ECS is also based on the map of
> > "*client subnet -> geolocation*" information.
>
> Paul Vixie 于2017年3月22日周
> > wait, what?
>
> Lanlan Pan wrote:
> > Hi Paul,
>
> hi.
>
> > https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/
>
> this web page is factually incorrect in that it presupposes that geo-ip
> is used. i have added a comment there to this effect.
>
> the original ECS web site
> (http://www.afasterinternet.com/howitworks.htm) is somewhat
> marketing-oriented, but says only that "With this more intelligent
> routing, customers will have a better Internet experience with lower
> latency and faster speeds." in other words, it expects that a CDN will
> apply its server-selection logic on an address basis, but using the
> truncated client subnet rather than to the DNS request source address.
> it does not dictate what the CDN's server-selection logic has to be or do.
>
> in RFC 7871 (http://www.afasterinternet.com/ietfrfc.htm) we see this
> definition:
>
> > Topologically Close:  Refers to two hosts being close in terms of the
> >   number of hops or the time it takes for a packet to travel from
> >   one host to the other.  The concept of topological distance is
> >   only loosely related to the concept of geographical distance: two
> >   geographically close hosts can still be very distant from a
> >   topological perspective, and two geographically distant hosts can
> >   be quite close on the network.
>
> there is an error on page 22 which is directly on-point:
>
> >o  Recursive Resolvers implementing ECS should only enable it in
> >   deployments where it is expected to bring clear advantages to the
> >   end users, such as when expecting clients from a variety of
> >   networks or from a wide geographical area.  Due to the high cache
> >   pressure introduced by ECS, the feature SHOULD be disabled in all
> >   default configurations.
>
> from context, it's clear that they meant "topological area".
>
> actual CDN technology, from as far back as Cisco Distributed Director in
> the mid-1990's, has usually ignored geography, for t

Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

[Lanlan Pan]

Hi Paul,

https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/

Paul Vixie 于2017年3月22日周三 下午4:00写道：

>
>
> Lanlan Pan wrote:
> > ... Because ECS is
> > also based on the map of  "*client subnet -> geolocation*" information.
>
> wait, what?
>
> --
> P Vixie
>
> --
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

[Lanlan Pan]

Hi Ask,

Ask Bjørn Hansen 于2017年3月22日周三 下午12:40写道：

>
> On Mar 21, 2017, at 21:30 , Lanlan Pan  wrote:
>
> See this example of ECS : Which CDNs support edns-client-subnet?
> <https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/>,
> they *map the ECS client subnet into the geolocation (what EIL give)*,
> and then make DNS decision. Because on AUTH side, they do not so care about
> each client subnet, but configure on aerial view geolocation level
>
>
> That’s a fundamental assumption of your proposal. What I’m offering (and I
> think what Warren said as well) is that it’s not true. The authoritative
> server will likely care as much or more about the subnet as it does the geo
> location.
>
> The geo location only is fine for smaller networks or CDNs. Consider for
> example several pops in one city or region with differing peering
> connections in each pop.
>
> First, I TOTALLY AGREE with you that there may be several pops in one city
or region with differing peering connections in each pop.

But, EIL has the *SAME fundamental assumption* of ECS. Because ECS is also
based on the map of  "*client subnet -> geolocation*" information.

So, imagine that,  AUTH gets the precise subnet, and then,  *what is the
accuracy of map the subnet into geolocation* ?

* 2) Is the IP geolocation database used by the authoritative server with
high quality?  ( details in my Paper
<https://drive.google.com/open?id=0B5gNT4RRJ0xPaG9nZ045VXRrZzg> )*

Most of time, AUTH's  geolocation database CAN NOT achieve this accuracy
level, expecially on foreign subnet: several pops in one city or region
with differing peering connections in each pop.
So, the point is ECS send the subnet to AUTH, and AUTH map the subnet into
EIL's aerial view geolocation, and then AUTH makes the DNS decision.

For example, some AUTH may use Maxmind IP geo database.
Maxmind can tell that a subnet is from CHINA, and distinguish Chinese TOP 5
ISP : TELECOM/UNICOM/MOBILE/EDUCATION/TIETONG.
But Maxmind can not distinguish different subnet peering connections in one
city, there are many small ISPs in China,  such as CHANGKUAN, GEHUA,
DIANXINTONG, JUYOU, YOUXIANTONG, etc...
Actually, when I was worked for Tencent, a local company which have
billions of clients at PC and Mobile in China, they DID NOT achieve this
accuracy level too.

However, if you know about the geolocation ,  you
can make a better response, most of time, is the best response too.

Moreover, IPv6 contains huge amount of subnet, the accuracy problem may be
even worse.


> Ask
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

[Lanlan Pan]

Hi Ask，

Ask Bjørn Hansen 于2017年3月21日周二 下午4:11写道：

>
> > On Mar 20, 2017, at 0:49, Lanlan Pan  wrote:
> >
> > Everyone has known that physical location and the topology of content
> delivery DO NOT MATCH.
> > As last mail reply to Warren, my proposal can offer the SAME critical
> information for authoritative server to make tailored response decision as
> ECS's client subnet.
> > Because in database such as maxmind,  ECS (client subnet) can be map
> into , which also guide network
> topology.
> > Therefore, if ECS has ANY value for optimizing content delivery on the
> Internet, then EIL has.
> >
> > For example，If ECS is tell AUTH :  the query is from 114.240.0.0/24.
> The AUTH knows that ECS(114.240.0.0/24) is indicated (CHINA, BEIJING,
> UNICOM), which is not only geolocation, but also contains network topology
> information. Then AUTH can return satisfied ip address according to the
> topology of content delivery.
>
> Except for very small networks, the network topology isn’t just the name
> of the provider. I suspect that if you took away all the geoip type lookups
> the larger content delivery systems would work fine; but if you did the
> opposite (what you are proposing with EIL) they would not.
>
> I believe Netflix has public information about how their OpenConnect
> system uses BGP and network topology information.
>

CDN providers configure their BGP with its AS neighbor, the network
topology optimization focus on, make their datacenters connect to more and
more important ISP (such as Level 3, Comcast, etc) , with faster and faster
connect speed.
Consider about DNS based delivery, as last mail I reply to brian, CDN can
work finer if resolver‘s IP nearby client’s IP.

See this example of ECS : Which CDNs support edns-client-subnet?
<https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/>,
they *map the ECS client subnet into the geolocation (what EIL give)*, and
then make DNS decision. Because on AUTH side, they do not so care about
each client subnet, but configure on aerial view geolocation level. AUTH no
need configure for each client subnet, geoip-level precision check is offen
took for IP connect speed sample test.

Therefore, EIL  can give the *SAME* *sufficent*
geolocation information as ECS for AUTH, to decide which is the best IP
addresses to response, because each CDN IP *serves many client subnets in
the same area*.

For example, all of these ECS can be map into*  EIL(CHINA, BEIJING, UNICOM)*

*: ECS(103.3.120.0/24 <http://103.3.120.0/24>), ECS(111.192.0.0/16
<http://111.192.0.0/16>),ECS(114.240.0.0/16 <http://114.240.0.0/16>),
ECS(120.132.0.0/16 <http://120.132.0.0/16>), ECS(123.112.0.0/16
<http://123.112.0.0/16>), ECS(124.64.0.0/16 <http://124.64.0.0/16>),
ECS(125.33.0.0/16 <http://125.33.0.0/16>), ECS(202.106.0.0/16
<http://202.106.0.0/16>), ECS(210.82.0.0/16 <http://210.82.0.0/16>),
ECS(219.158.128.0/24 <http://219.158.128.0/24>), ECS(221.216.0.0/16
<http://221.216.0.0/16>), ECS(222.128.0.0/16 <http://222.128.0.0/16>),
ECS(49.152.0.0/16 <http://49.152.0.0/16>), ECS(61.48.0.0/16
<http://61.48.0.0/16>),..*


>
> Ask (speaking only for myself)
>
> --
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

[Lanlan Pan]

Hi,

Thanks for Petr and Brian.

Brian Hartvigsen 于2017年3月21日周二 上午3:34写道：


>> For user privacy concern, we can revise  ECS(114.240.0.0/24
>> ) => EIL (CHINA, BEIJING, UNICOM)，give a
>> tradeoff between privacy and precise.
>
> Nice, this sounds like appropriate tradeoff to me.
>
>
> Side-effect of this is that it removes need to maintain copies of
> various Geo-IP databases all over the place, which is an improvement to
> operational practice.

I disagree.  Unless you get the clients to implement EIL, then you’ve
simply just pushed the need for geo-ip mapping from CDN to DNS provider.
Of course one would assume that an ISP already has this mapping, but 3rd
party DNS would not.  So either they have to build the mappings,  maintain
a copy of some Geo-IP database, or hope that all the clients have it
implemented.  With 3rd party DNS carrying double digit percentages of
traffic (iirc ~15% total from 2015 OARC presentation), that’s not something
to just brush away.


*AUTH*
ECS needs AUTH to do geo-ip mapping to decide most satisfied response.
There is Geo-IP database on the AUTH which is supporting ECS.  (ECS example
figures: Which CDNs support edns-client-subnet? )


Therefore, if AUTH support ECS, the AUTH can support EIL too.

*RECUR*

Return to the origin smart-dns-resolution problem, there are two critical
factors that affect the response accuracy of authoritative server: (details
wrote in my *Paper
*)
1) Is the resolver's IP address close to the client's IP address?
2) Is the IP geolocation database used by the authoritative server with
high quality?

Public recursive resolvers offer free DNS resolution services for global
users. But these servers are NOT CLOSE TO many users because the public
recursive service providers COULDN'T deploy servers in every country and
every ISP's network.
That is why public recursive service provider starved of ECS, which carried
client subnet to AUTH for geo-ip mapping.
Therefore, public recursive resolvers INCREASE the seperated distance of
client's IP and resolver's IP. Because on traditional ISP recurisve
resolver side, ISP are nearby the client's IP.

That is why I say the most recommend is P-Model, deploy EIL on public
recursive resolver, to partly lighten the burden of AUTH (as Petr pointed),
decrease the user privacy risk at PUB RECUR -> AUTH path.
EIL deploy on I-Model (ISP recursive resolver)  and L-Model (Local
forwarding resolver) is in long-term, the most realistic nowadays is the
P-Model (Public recursive resolver).

By the way，if 3rd party public recursive DNS are carrying double digit
percentages of traffic, there is a high probability that they have strong
technologies and rich resources to do geo-ip mapping for their client
queries.



— Brian

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

[Lanlan Pan]

Hi Barry,

Thanks for your comments.

Because the draft discussed the DNS privacy problem of ECS, and was
first presented in In NDSS 2017 DNS Privacy Workshop, so I cc the
email to dprive WG.


Barry Raveendran Greene 于2017年3月19日周日 上午2:22写道：

Hello Yu Fu,

I was not at the workshop. Warren already mentioned some issues. I second
what he is saying in a stronger terms:

+ What you are proposing has no value for optimizing content delivery on
the Internet. Physical location and the topology of content delivery do not
match. Also, Anycast is used. It is NOT expensive. The reason why so many
CDN operator use DNS based tools for content delivery is granularity of
action. An edge compute system (i.e. what many CDNs are) can do all sorts
of checks via DNS approach vs an Anycast approach.


Everyone has known that physical location and the topology of content
delivery DO NOT MATCH.
As last mail reply to Warren, my proposal can offer the SAME critical
information for authoritative server to make tailored response decision as
ECS's client subnet.
Because in database such as maxmind,  ECS (client subnet) can be map into
, which also guide network topology.
Therefore, if ECS has ANY value for optimizing content delivery on the
Internet, then EIL has.

For example，If ECS is tell AUTH :  the query is from 114.240.0.0/24. The
AUTH knows that ECS(114.240.0.0/24) is indicated (CHINA, BEIJING, UNICOM),
which is not only geolocation, but also contains network topology
information. Then AUTH can return satisfied ip address according to the
topology of content delivery.

For user privacy concern, we can revise  ECS(114.240.0.0/24) => EIL (CHINA,
BEIJING, UNICOM)，give a tradeoff between privacy and precise.



Also, the ECS security assessment if off. ECS from the resolver to the aDNS
is sending a subnet configured by the operator of the rDNS. Once the
connection to the client to the CDN is made, the CDN operator has the full
details of the client. The term “leak client subnet to AUTH” is misleading
from a “privacy risk.” Once the connection is made to my CDN, I know the IP
specifics.


Privacy risk of ECS:
1. If ECS is clear text in the resolution path => eavesdrop => encrypt the
dns traffic, in long term.
2. The passive DNS log analysis risk
   - avoid recursive dns analysis, reserve the optimization ECS, we can
send EIL query by some proxy tunnel.
   - avoid authoritative dns analysis. If CDN is ALSO the authoritative
server, AGREE WITH YOU. But to a third-party authoritative service, the
more domains publish their zones on the third-party authoritative server,
the more end user privacy information can be gathered by the authoritative
server according to the ECS queries from recursive.

ECS's security issue is described in DNS Privacy Workshop 2017 Background
<http://www.internetsociety.org/events/ndss-symposium/ndss-symposium-2017/dns-privacy-workshop-2017-call-papers>，
Understanding the Privacy Implications of ECS
<http://www.cc.gatech.edu/~ynadji3/docs/pubs/dimva16_ecs.pdf>.
And In RFC7871(ECS) <https://tools.ietf.org/html/rfc7871>'s abstract
section:

*Since it has some known operational and privacy shortcomings, a
revision will be worked through the IETF for improvement.*



+ What you are proposing has great value for Law Enforcement and State
Security. It would cut out the Operator as the middle man and eliminate the
need for a court order to release details on suspects.

This also is a tool for criminals. I can easily see bad guys who are
dropping ransomware use this as a tool to say “pay up or I’ll SWAT your
house” or move from E-mail exertion threats to phone based threats.

Barry

> On Mar 17, 2017, at 6:57 PM, Lanlan Pan  wrote:
>
> Hi all,
>
> In NDSS 2017 DNS Privacy Workshop, I presented a EIL option as an
alternative privacy improvement for ECS.
>
> The paper and slide are attached.  Test code in github :
https://github.com/abbypan/dns_test_eil
>
> Any comments or suggestions will be appreciated.
>
> Regards.
>
> Yu Fu 于2017年3月16日周四 上午10:37写道：
> Hi all,
>
> We have submitted a new draft as draft-pan-dnsop-edns-isp-location-00.
> This document is an improved solution for ECS(RFC7871), describes an EDNS
ISP Location (EIL) extension to address the privacy problem of ECS, find
the right balance between privacy improvement and user experience
optimization.  EIL is defined to convey ISP location information that is
relevant to the DNS message.  It will provide sufficient information for
the Authoritative Server to decide the response without guessing
geolocation of the IP address.
>
> Your comments are appreciated.
>
> Thanks
> Lanlan & Yu
>
> >-Original Message-
> >From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> >Sent: Monday, March 13, 2017 6:07 PM
> >To: Pan Lanlan; Lanlan Pan; Yu Fu
> >Subject: New Version Notification for
draft-pan-dnsop-e