Re: [DNSOP] draft-tale-dnsop-edns-clientid
On 31 Mar 2017, at 16:09, Peter van Dijk wrote: On 28 Mar 2017, at 23:27, Dave Lawrence wrote: Peter van Dijk writes: Please note that neither draft handles the use case of also passing the port number, which in a world of growing CGN deployment, may soon prove quite important. I agree that neither handles it explicitly. Ray's singular use case doesn't really need it, and our draft can handle ports through the DNS address family mechanism if needed, albeit less compactly that could be otherwise envisioned. If this were something that others think should somehow be made explicit via some other mechanism, I could see incorporating that. How would you do it in the DNS address family? Sorry, I see it now, the DNS address family has an opaque field (‘custom token’) behind it. Would prefer standardisation of port still! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
On 28 Mar 2017, at 21:56, Barry Raveendran Greene wrote: On Mar 28, 2017, at 12:31 PM, Peter van Dijk wrote: Please note that neither draft handles the use case of also passing the port number, which in a world of growing CGN deployment, may soon prove quite important. Can you elaborate? Both drafts (xpf and clientid) allow the resolver to identify the client even if the IP header does not provide enough information for it. xpf does this for the case of a generic proxy, clientid does it for that case plus the case of a CPE that does NAT but can pass on the client’s MAC or another token, allowing the resolver to identify the individual device at the customer. However, if the client to such a proxy is itself behind a CGN gateway, we may need both client IP + port number to identify the specific client. If the proxy only tells us the IP, we just know this might be any of a hundred different clients, because we do not have the port number that can help us distinguish these clients. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
On 28 Mar 2017, at 23:27, Dave Lawrence wrote: > Peter van Dijk writes: >> Please note that neither draft handles the use case of also passing the >> port number, which in a world of growing CGN deployment, may soon prove >> quite important. > > I agree that neither handles it explicitly. Ray's singular use case > doesn't really need it, and our draft can handle ports through the DNS > address family mechanism if needed, albeit less compactly that could > be otherwise envisioned. If this were something that others think > should somehow be made explicit via some other mechanism, I could see > incorporating that. How would you do it in the DNS address family? Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
On 30/03/2017 16:48, Mark Andrews wrote: > > I'm going to assume these two proposals can be merged. > > The simple way to do this is to *always* add a OPT record that only > contains this option to the end of the packet adjusting the additional > section count. This OPT record is removed and the additional section > count is adjusted prior to TSIG / SIG(0) verification. > > When replying via the front end, you always add a OPT record to the > end of the packet after TSIG / SIG(0) computation adjusting the > additional section count. This is removed by the front end adjusting > the additional section count. > > This allows for TSIG, SIG(0) and plain DNS to be handled gracefully. > Any other options like destination address can be added to this OPT > record. > > If people really object to two OPT records we can do a OPT clone. Interesting, although I'd be curious how we'd avoid and/or change the rules for TSIG that say it MUST always come last in the packet. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
I'm going to assume these two proposals can be merged. The simple way to do this is to *always* add a OPT record that only contains this option to the end of the packet adjusting the additional section count. This OPT record is removed and the additional section count is adjusted prior to TSIG / SIG(0) verification. When replying via the front end, you always add a OPT record to the end of the packet after TSIG / SIG(0) computation adjusting the additional section count. This is removed by the front end adjusting the additional section count. This allows for TSIG, SIG(0) and plain DNS to be handled gracefully. Any other options like destination address can be added to this OPT record. If people really object to two OPT records we can do a OPT clone. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
Catching up with the discussion I like having two, well documented options. I do see where the option in David's draft has too many moving parts. On Thu, Mar 30, 2017 at 11:20 AM, Dave Lawrence wrote: > On 30/03/2017 09:52, Bob Harold wrote: > >> Just a thought - would it be better to have two different EDNS0 options > >> that carry an IP, or to have one EDNS0 option that carries both an IP > >> and a 'type', and allow multiples of that option in a packet? > > Ray Bellis writes: > > IMHO, two options is better. > > I'm with Ray on this, both because of his earlier observation re: TXT, > and also because this complicates the option design and adds yet< > another number registry. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
On 30/03/2017 09:52, Bob Harold wrote: >> Just a thought - would it be better to have two different EDNS0 options >> that carry an IP, or to have one EDNS0 option that carries both an IP >> and a 'type', and allow multiples of that option in a packet? Ray Bellis writes: > IMHO, two options is better. I'm with Ray on this, both because of his earlier observation re: TXT, and also because this complicates the option design and adds yet< another number registry. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
On 30/03/2017 09:52, Bob Harold wrote: > Just a thought - would it be better to have two different EDNS0 options > that carry an IP, or to have one EDNS0 option that carries both an IP > and a 'type', and allow multiples of that option in a packet? IMHO, two options is better. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
On Wed, Mar 29, 2017 at 11:47 AM, Ray Bellis wrote: > > > On 29/03/2017 10:41, Dave Lawrence wrote: > > > Well yes, but there's another simple test, the limited Expert Review > > guidance against duplicate functionality. Both xpf and clientid > > provide the functionality of conveying an IP address in an EDNS0 > > option. > > Whilst you're correct that they both carry information that happens to > have the same format, they have different semantic intent, and it would > IMHO cause confusion if both were carried in a packet with the same > option code. > Just a thought - would it be better to have two different EDNS0 options that carry an IP, or to have one EDNS0 option that carries both an IP and a 'type', and allow multiples of that option in a packet? -- Bob Harold (Thinking separate options are probably simpler, but wanted to ask.) > > It's effectively the same argument about TXT records - there's plenty of > things that use TXT format, but it's preferred that separate RRTYPEs are > used to indicate the use case. > > Ray > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
Ray Bellis writes: > It's effectively the same argument about TXT records - there's plenty of > things that use TXT format, but it's preferred that separate RRTYPEs are > used to indicate the use case. If that's the position the WG would like to take, I'd be fine with that. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
On 29/03/2017 10:41, Dave Lawrence wrote: > Well yes, but there's another simple test, the limited Expert Review > guidance against duplicate functionality. Both xpf and clientid > provide the functionality of conveying an IP address in an EDNS0 > option. Whilst you're correct that they both carry information that happens to have the same format, they have different semantic intent, and it would IMHO cause confusion if both were carried in a packet with the same option code. It's effectively the same argument about TXT records - there's plenty of things that use TXT format, but it's preferred that separate RRTYPEs are used to indicate the use case. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
Ray Bellis writes: > I therefore think there's a simple test here: [...] Well yes, but there's another simple test, the limited Expert Review guidance against duplicate functionality. Both xpf and clientid provide the functionality of conveying an IP address in an EDNS0 option. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
On 28/03/2017 16:02, Dave Lawrence wrote: > Understandable. I honestly have similar reservations. > > One thing that clouds this a little, as far as our draft is concerned, > is that the ISP's CPE already knows this information so in a sense it > isn't that a different party is being informed. > > What I'm trying to accomplish with this draft is acknowledge the > practical realities that this sort of option is already in use on the > Internet and will continue to be used no matter what the WG does about > either of our drafts. I also wanted to drag the PII issues out into > the open, into one place where they would have to be confronted by > implementers and operators. > > I fear that a splintered effort on including full client-identifying > information in several different ways is going to lead to problematic > fragmentation and harder management. The examples in your draft appear focused on identifying specific end user devices, e.g. to selectively enable parental controls on a per-device basis. Mine is intended to identify clients based on their presented IP address (whether that be the public IP address of multiple NATed end users talking to a recursor, or the external IP address of a recursor talking to an authoritative server). The primary purpose is for admission control (i.e. ACLs). I therefore think there's a simple test here: If we can imagine scenarios in which an auth or recursive server that is behind e.g. a load-balancing proxy needs to know *both* the internal "client ID" (per your draft) and the client's effective external source IP address (per mine) then both drafts serve their own distinct purpose and shouldn't be merged. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
Peter van Dijk writes: > On 28 Mar 2017, at 16:35, Dave Lawrence wrote: > > I grant that there is reason for pause because both Nominum and > > OpenDNS have squatted code points which have duplicate functionality. > > Should this squatting perhaps be documented in the style of RFC 8093 to > avoid future surprises? Yes, I think that's a good idea. > > Speaking of Ray's draft, our proposal is able to handle his use case > > but unfortunately our use cases are not achievable in his. > Please note that neither draft handles the use case of also passing the > port number, which in a world of growing CGN deployment, may soon prove > quite important. I agree that neither handles it explicitly. Ray's singular use case doesn't really need it, and our draft can handle ports through the DNS address family mechanism if needed, albeit less compactly that could be otherwise envisioned. If this were something that others think should somehow be made explicit via some other mechanism, I could see incorporating that. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
Ray Bellis writes: > I'm somewhat philosophically opposed to anything that injects client > related information such that it's shared between different parties. Understandable. I honestly have similar reservations. One thing that clouds this a little, as far as our draft is concerned, is that the ISP's CPE already knows this information so in a sense it isn't that a different party is being informed. What I'm trying to accomplish with this draft is acknowledge the practical realities that this sort of option is already in use on the Internet and will continue to be used no matter what the WG does about either of our drafts. I also wanted to drag the PII issues out into the open, into one place where they would have to be confronted by implementers and operators. I fear that a splintered effort on including full client-identifying information in several different ways is going to lead to problematic fragmentation and harder management. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
> On Mar 28, 2017, at 12:31 PM, Peter van Dijk > wrote: > > Please note that neither draft handles the use case of also passing the port > number, which in a world of growing CGN deployment, may soon prove quite > important. Can you elaborate? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
Hello, On 28 Mar 2017, at 0:49, Dave Lawrence wrote: Speaking of Ray's draft, our proposal is able to handle his use case but unfortunately our use cases are not achievable in his. I'd welcome joining up. Please note that neither draft handles the use case of also passing the port number, which in a world of growing CGN deployment, may soon prove quite important. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
Hello, On 28 Mar 2017, at 16:35, Dave Lawrence wrote: I grant that there is reason for pause because both Nominum and OpenDNS have squatted code points which have duplicate functionality. Should this squatting perhaps be documented in the style of RFC 8093 to avoid future surprises? Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
On 27/03/2017 17:49, Dave Lawrence wrote: > As Sara commented on Ray's draft that proposes a very similar option, > draft-bellis-dnsop-xpf, this sort of thing clearly needs a close look > at privacy, and I whole-heartedly agree. I've already been directly > poking privacy-concerned individuals for feedback. > > Speaking of Ray's draft, our proposal is able to handle his use case > but unfortunately our use cases are not achievable in his. I'd > welcome joining up. Let's see how it goes first :) I'm somewhat philosophically opposed to anything that injects client related information such that it's shared between different parties. A large point of my draft is that it's *not* designed to be used that way (but I accept Sara's point that the text around this could be stronger). It's only intended for use within a single network, to allow _already known_ client related information that would otherwise be obscured by an L3 proxy to be carried through to the end server. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
Olafur Gudmundsson writes: > Strictly speaking the draft was never formally submitted via IANA. This is part of the problem with documentation. At least one natural entry point for the process, the IANA assignments page, doesn't indicate how to initiate expert review. https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-11 It does link to RFC 6891 and to RFC 3604 Errata, but that's poor usability even if those documents described how to initiate review, which they don't. > As expert I do not have any formal guidelines to tell me how to > judge options. My rule after implementing ClientSubnet is $,1r|(Bnever > again$,1r}(B allow complex type. Agreed that you have poor guidance, the closest thing is from the RFCs mentioned above, which only says: "Assignment of Option Codes should be liberal, but duplicate functionality is to be avoided." I grant that there is reason for pause because both Nominum and OpenDNS have squatted code points which have duplicate functionality. There is a larger philosophical discussion that should be had about this, though, given that it seems to encourage just totally circumventing IETF/IANA. It is ironic to me that I was trying to do the right thing, yet the process which is supposed to have made getting option code assignments easier and not require action by the working group has seemingly failed at that task. The feeling of failure is exacerbated by not being able to have expectations properly set by documentation other than "be liberal". As for whether this is a complex type, that's a whole separate discussion to have if the draft itself gets more discussion. Mostly here in this message I'm focused on process. > As Expert I do not want to write the rules for myself :-) > I will be happy to comment on any suggested rules/advise. Fair enough. Anyone else interested in working on better guidance? To be clear, I'm totally okay if the result of that is something that would have still resulted in an initial denial for this option assignment under Expert Review. It's the process I want to see improved. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
> On Mar 27, 2017, at 5:49 PM, Dave Lawrence wrote: > > One of the two drafts I wanted to talk about at dnsop today for WG > adoption was "Client ID in Forwarded DNS Queries": > https://datatracker.ietf.org/doc/draft-tale-dnsop-edns0-clientid/ > > The core idea of this document is to be able to provide > device-specific identification in an EDNS option sent to a > full-service resolver, with the principal motivation to be for > filtering products. It uses an IANA Address Family value to indicate > the format of the identifier that is being sent. One of the design > goals was to avoid creating any new registries. > > This document treads on controversial grounds because of the obvious > privacy implications. It must be noted that both Nominum and Cisco > are already doing this via EDNS options, and so the general idea > confronts some similar issues we've encountered before about whether > to document in-use protocols or let them just continue on with little > to no public documentation. > > As Sara commented on Ray's draft that proposes a very similar option, > draft-bellis-dnsop-xpf, this sort of thing clearly needs a close look > at privacy, and I whole-heartedly agree. I've already been directly > poking privacy-concerned individuals for feedback. > > Speaking of Ray's draft, our proposal is able to handle his use case > but unfortunately our use cases are not achievable in his. I'd > welcome joining up. > > The one other thing I wanted to mention in the WG is that I tried to > get an EDNS code point assigned through the "Expert Review" process, > which it turns out is very poorly documented for either process or > review criteria. The Expert Reviewer, Olafur Gudmundsson, has > initially denied the request pending feedback from the WG. I'll leave > it to him to state what gave him pause, and to request the feedback he > seeks. Strictly speaking the draft was never formally submitted via IANA. Rather I was giving David advise on how I would rule if he submitted the draft. As expert I do not have any formal guidelines to tell me how to judge options. My rule after implementing ClientSubnet is “never again” allow complex type. So I told David et. al. that the type requested had 4 sub-types one already allocated, so stop sub-typing and ask for 3 extra types. I did not judge anything about the privacy issues that those 4 types may have, as that is not in scope. It is up to the working group to give advice to either editor or expert to change approach. > > The denial triggered a bit of a philosophical debate between us, but > no matter which side of that debate you line up on it's very clear > that Expert Review really needs documentation to appropriately set > everyone's expectations. I'm hoping that he and I will be > collaborating on a draft. > As Expert I do not want to write the rules for myself :-) I will be happy to comment on any suggested rules/advise. Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
