Subject: [DNSOP] Consensus suggestion for EDE and the TC bit

From: Wes Hardaker <[email-masked]>
Date: Wed, 20 Nov 2019 22:53:14 -0800

During the first DNSOP meeting at IETF 106 there was a discussion that
had multiple opinions about what to do with setting the TC bit for EDE
information, which is generally supplemental.  During my presentation I
mentioned that an associate of Viktor suggested creating a new bit, and
during the conversation there was discrepancy about whether or not that
was a good idea.  Brian Dickson then proposed that the new bit only
modify future clients that wanted to use it, thus leaving the EDE spec
setting the TC bit.  A future bit could be defined that would indicate
that only supplemental information was dropped.

My proposal for EDE is that we follow this train of thought, which seems
to be the widest idea accepted from what I could tell.  TLDR for things
to do:

1. We have the EDE document say to set the TC bit (which it already did)
2. We create a new document that defines an extra bit for indicating
   that the dropped information was supplemental and didn't contain
   operationally important information.

If this sounds like a good compromise, great!  If you would like to
propose an alternative, great!  do so!

In the mean time, I threw together a quick ID for the new bit as well:

https://datatracker.ietf.org/doc/draft-hardaker-dnsop-drop/

-- 
Wes Hardaker
USC/ISI

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 21 Nov 2019 15:37:49 +0800

I think we are talking about performance in a situation that (a) is so
pathological that it will almost never happen and (b) at worst, will only
slow down failure, not success.  For that reason, I would avoid introducing
any additional protocol complexity in pursuit of optimization.  I think our
simplest and most appealing option would be to treat EDE exactly like any
existing EDNS Option (i.e. set the TC bit).

To be clear, we are talking only about the case where a response "fits"
until the EDE is added, after which it exceeds the limit and is truncated.
If optimizing this situation is important, I would suggest adding a
requirement to the EDE draft that EDE be the last option in OPT.  Then as a
client, I can easily detect this situation, because the truncation point is
in the middle of the EDE option.  The client logic then is very simple: if
I don't care about EDE, I can ignore the TC bit.

On Thu, Nov 21, 2019 at 2:53 PM Wes Hardaker <[email-masked]> wrote:

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 21 Nov 2019 03:10:24 -0500

> On Nov 21, 2019, at 2:37 AM, Ben Schwartz <[email-masked]> wrote:
> 
> To be clear, we are talking only about the case where a response "fits" until the EDE is added, after which it exceeds the limit and is truncated.  If optimizing this situation is important, I would suggest adding a requirement to the EDE draft that EDE be the last option in OPT.  Then as a client, I can easily detect this situation, because the truncation point is in the middle of the EDE option.  The client logic then is very simple: if I don't care about EDE, I can ignore the TC bit.

Not sure what you mean by "in the middle of the EDE option", IIRC
truncation IIRCin DNS is never "in the middle" of an element, we
either send the whole element or don't send it.

For the OPT RR, I think that means that it includes a set of
complete options.

I do agree that truncation due to EDE should be rare, and therefore
also TCP failover as a result of such truncation, so if the consensus
is to keep it simple, so be it, but I don't see how how the client
could figure out what was left out...

-- 
	Viktor.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 21 Nov 2019 00:39:16 -0800

> I think our simplest and most appealing option would be to treat EDE
> exactly like any existing EDNS Option (i.e. set the TC bit).

For the record, I'm just fine with this.  People that *want* a separate
signal should speak up please and voice their reasons why having just
the TC bit is unacceptable too.

We need to come to a decision about this, and that will require everyone
with an opinion to chime in.
-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 21 Nov 2019 00:49:39 -0800

> with an opinion to chime in.

Actually, I forgot that one of the primary reasons for separating it was
that EDE can go forward and the need for TC/DP bits can be debated
longer if need be.

So...  anyone that thinks something like the DP bit is needed *and*
should be tied to EDE should speak up.  Please.

-- 
Wes Hardaker
USC/ISI

---

From: Petr Špaček <[email-masked]>
Date: Thu, 21 Nov 2019 10:19:37 +0100

> should be tied to EDE should speak up.  Please.

I will provide the opposite opinion:
DP bit is not *needed* for EDE.

If I'm proven wrong in future we can specify DP bit in a separate document and update EDE RFC.

(Also I've changed my mind when it comes to TC bit - now I believe that normal DNS processing is fine and EDE does not need a special case.)

-- 
Petr Špaček  @  CZ.NIC

---

From: Bob Harold <[email-masked]>
Date: Thu, 21 Nov 2019 08:44:18 -0500

On Thu, Nov 21, 2019 at 4:19 AM Petr Špaček <[email-masked]> wrote:

> (Also I've changed my mind when it comes to TC bit - now I believe that
> normal DNS processing is fine and EDE does not need a special case.)
>
> --
> Petr Špaček  @  CZ.NIC
>

Thanks for the discussion and the idea of a separate bit.

My opinion:

Keep TC bit in EDE and move it forward.

I would prefer not to create a DP flag bit yet, until actual measurements
tell us that it makes a measurable difference - let's wait until EDE is
deployed and someone can measure the occurrence of truncating just EDE.
Then we can discuss if the percentage is worth the complexity.

-- 
Bob Harold

---

From: Ray Bellis <[email-masked]>
Date: Fri, 22 Nov 2019 01:03:42 +0800

On 21/11/2019 15:37, Ben Schwartz wrote:

> I would suggest adding a requirement to the EDE draft that EDE be
> the last option in OPT

And what if some other future option wants to lay claim to that requirement?

> Then as a client, I can easily detect this situation, because the 
> truncation point is in the middle of the EDE option.

A conformant server should never crop a packet in the middle of an RR
when truncating such that the resulting packet is unparsable (implied by
RFC 1035 §6.2)

Also, an EDNS conformant server MUST include an OPT RR in its
response to a query that contained an OPT RR, even when truncating.
(RFC 6891 §6.1.1, §7).

Ray

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 21 Nov 2019 22:42:12 -0800

> document and update EDE RFC.

That's actually what we did Petr (DP is in a separate draft and may or
may not even try for adoption).  But thanks, your voice matches what
looks to be the rest to the norm.
-- 
Wes Hardaker
USC/ISI

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 29 Nov 2019 12:19:23 +0100

On Thu, 2019-11-21 at 15:37 +0800, Ben Schwartz wrote:
> I think we are talking about performance in a situation that (a) is so pathological that it will almost never happen and (b) at worst, will only slow down failure, not success.  For that reason, I would avoid introducing any additional protocol complexity in pursuit of optimization.  I think our simplest and most appealing option would be to treat EDE exactly like any existing EDNS Option (i.e. set the TC bit).
> 

Please do not write specifications that require software to receive a corrupt packet (in this case, one where the RDLEN of the last record extends beyond the end of the packet) and draw any conclusion from it other than 'this is a corrupt packet'. Also, please do not truncate packets on arbitrary byte boundaries.

In other words, please always send well-formed packets that contain what they say they contain in terms of Answer/Additional/Auth counts, and the sizes of those individual records.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/