Subject: [DNSOP] draft-tale-dnsop-edns-clientid

From: Dave Lawrence <[email-masked]>
Date: Mon, 27 Mar 2017 18:49:30 -0400

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.

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.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 27 Mar 2017 23:35:05 -0500

> On Mar 27, 2017, at 5:49 PM, Dave Lawrence <[email-masked]> wrote:
> 

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. 

> 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

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 28 Mar 2017 10:35:17 -0400

> 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.

> 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.

---

From: Ray Bellis <[email-masked]>
Date: Tue, 28 Mar 2017 11:38:37 -0500

> but unfortunately our use cases are not achievable in his.  I'd

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

---

From: "Peter van Dijk" <[email-masked]>
Date: Tue, 28 Mar 2017 19:30:34 +0200

Hello,

> 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/

---

From: "Peter van Dijk" <[email-masked]>
Date: Tue, 28 Mar 2017 19:31:47 +0200

Hello,

> but unfortunately our use cases are not achievable in his.  I'd

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,

---

From: Barry Raveendran Greene <[email-masked]>
Date: Tue, 28 Mar 2017 14:56:23 -0500

> On Mar 28, 2017, at 12:31 PM, Peter van Dijk <[email-masked]> 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?

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 28 Mar 2017 17:02:09 -0400

> 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.

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 28 Mar 2017 17:27:35 -0400

> Should this squatting perhaps be documented in the style of RFC 8093 to 

Yes, I think that's a good idea.

> > but unfortunately our use cases are not achievable in his. 

> port number, which in a world of growing CGN deployment, may soon prove 

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.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 29 Mar 2017 00:25:15 -0500

> 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

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 29 Mar 2017 11:41:52 -0400

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.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 29 Mar 2017 10:47:43 -0500

> provide the functionality of conveying an IP address in an EDNS0

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

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 29 Mar 2017 11:54:29 -0400

> used to indicate the use case.

If that's the position the WG would like to take, I'd be fine with that.

---

From: Bob Harold <[email-masked]>
Date: Thu, 30 Mar 2017 10:52:59 -0400

> IMHO cause confusion if both were carried in a packet with the same

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.)

---

From: Ray Bellis <[email-masked]>
Date: Thu, 30 Mar 2017 09:54:26 -0500

On 30/03/2017 09:52, Bob Harold wrote:

> 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

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 30 Mar 2017 12:20:50 -0400

> 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.

---

From: tjw ietf <[email-masked]>
Date: Thu, 30 Mar 2017 11:52:19 -0500

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 <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 31 Mar 2017 08:48:50 +1100

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: [email-masked]

---

From: Ray Bellis <[email-masked]>
Date: Thu, 30 Mar 2017 18:54:34 -0500

> 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

---

From: "Peter van Dijk" <[email-masked]>
Date: Fri, 31 Mar 2017 16:09:11 +0200

> should somehow be made explicit via some other mechanism, I could see

How would you do it in the DNS address family?

Kind regards,

---

From: "Peter van Dijk" <[email-masked]>
Date: Fri, 31 Mar 2017 16:14:10 +0200

On 28 Mar 2017, at 21:56, Barry Raveendran Greene 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,

---

From: "Peter van Dijk" <[email-masked]>
Date: Fri, 31 Mar 2017 16:15:33 +0200

On 31 Mar 2017, at 16:09, Peter van Dijk wrote:

>>> the

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,