Subject: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-03.txt

From: [email-masked]
Date: Mon, 03 Jul 2017 16:40:04 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

        Title           : DNS Session Signaling
        Authors         : Ray Bellis
                          Stuart Cheshire
                          John Dickinson
                          Sara Dickinson
                          Allison Mankin
                          Tom Pusateri
	Filename        : draft-ietf-dnsop-session-signal-03.txt
	Pages           : 27
	Date            : 2017-07-03

Abstract:
   This document defines a new Session Signaling OPCODE used to
   communicate persistent "per-session" operations, expressed using
   type-length-value (TLV) syntax, and defines an initial set of TLVs
   used to manage session timeouts and termination.  This mechanism is
   intended to reduce the overhead of existing "per-packet" signaling
   mechanisms with "per-message" semantics as well as defining new
   signaling operations not defined in EDNS(0).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-03
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-session-signal-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Petr Špaček <[email-masked]>
Date: Tue, 11 Jul 2017 09:17:57 +0200

Hello dnsop,

reading throught the latest version, I object to the proposed TLV format.

I feel that implications from switch to non-RR format are underestimated
and following e-mail attempts to explain why I believe it is a bad idea.
Please accept my apology for such long e-mail.

Overview
--------
1. Parsing the new format itself is not the hard because it is similar
to other rdata, even though not very same (see below).

2. The hard part is integration into rest of the program and "wider
ecosystem" including all the bells and whistles.

This includes:
- from_wire/to_wire conversion
- from_string/to_string conversion
- ability to log and process those logs
- support in traffic analysis tools
- support in data formats used for storing DNS messages

It is *very important* to consider that there is plenty of software
which do not need to understand DNS semantics but just DNS message
format (message collectors, statistic tools etc.).

3. We need to keep in mind that introducing very new format (instead of
using <owner,class,TTL,rrtype,rdata> structure) change affects not only
servers and resolvers but everything in DNS ecosystem, *including data
formats* used to store messages.

Can we represent messages with the new format in dnstap, C-DNS, and all
the DNS_in_JSON flavors? If not, how should we handle this problem?

Why it is harder to implement it everywhere that it seems
---------------------------------------------------------
The main reason is that every DNS software already has its own set of
utility functions for operating on RR format. Switching over to a TLV
format gets more complicated when we start speaking about
logging/filtering and other integration aspects because will have to
include new conditions in all code paths as well.

Why is this so different from adding new RR type? New RR type and new
TLV format surely need new code for en/decoding, but again, this is the
easy part.

The main problem integration with everything else. Normal RR processing
already has all the abstraction and APIs ready, including all sorts of
utility functions.

I.e. existing message matching code will have to be extended with
if (opcode == SESSION_SIGNALING) {
    // comparison function for SS
} else {
    // comparison function for normal data
}

Similarly when it comes to logging, it is not just calling log_rr()
anymore. It is now
if (opcode == SESSION_SIGNALING) {
    // log function for SS
} else {
    // log function for normal data
}

I will try to describe an example with python-dns library (because it is
small and easy to read, it would be the very same for e.g. Knot resolver):

If we used normal RR format, it is just matter of dropping one file
(e.g. rdtypes/class/SS.py) with methods for en/decoding. The existing
infrastructure of the library would take care of all the message parsing
(incl. handling of malformed/truncated messages etc.), printing,
comparison, logging etc. and all this "integration" is "for free"
because the libraries already have it for everything in RR format.

[In fact, when we talk about normal RR format, we might not even need to
write the en/decoders! Right now we are working on an prototype
implementation of https://tools.ietf.org/html/draft-levine-dnsextlang-07
which generates en/decoders "for free".]

By diverting from RR format we will lose all this.

For example in CZ.NIC we are maintaining several tools which do not need
to "understand" semantics of DNS messages but have to parse them. All
these would have to be modified. RR-based format will "just work" with
these because support for uknown RR types is already there.

Of course, there needs to be code to do the actual session logic, but
re-use of existing infrastructure allows developers to focus on the
session logic and not on re-inventing the integration.

Why TLV format is not effective as fool-proof measure
-----------------------------------------------------
DNS servers should already be returning NOTIMP for unknown opcodes
already so it should be sufficient counter-measure to avoid getting
records into caches etc.

In any case, the new TLV format does not prevent people from doing
mistakes (or attacks) and sending SS data along with non-SS data, i.e.
there has to be code to handle these error cases regardless of format.

If we can agree on the previous point, i.e. necessity to handle bad
messages anyway, we are left with problems related to caching/AXFR. This
gets us to the very same situation as with OPT RR which has similar
semantics and definitelly should not get into cache/AXFR, etc. I.e.
similar measures can be re-used insted of inventing new ones.

Conclusion
----------
If we consider that there is plenty of software reading DNS traffic,
e.g. for doing statistics, testing software which read/generate DNS
messages etc., the new TLV format is unnecessairly hard to implement in
rest of the DNS ecosystem. Sticking to standard
<owner,class,TTL,rrtype,rdata> format would solve this particular problem.

Thank you for your time and attention.

Petr Špaček  @  CZ.NIC

---

From: P Vix <[email-masked]>
Date: Tue, 11 Jul 2017 07:34:12 +0000

+1

On July 11, 2017 3:17:57 PM GMT+08:00, "Petr Špaček" <[email-masked]> wrote:
>implementation of
>https://tools.ietf.org/html/draft-levine-dnsextlang-07
>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Jul 2017 07:23:47 -0400

> Please accept my apology for such long e-mail.

Petr, with all due respect, I did not see a counter-proposal here, and your comments seem to reflect a misunderstanding of what session-signaling is.

In fact, the opposite of what you said is true: if this were done as a normal query with EDNS0-like encapsulation, _then_ we would see problems, because session signaling messages would look more like DNS queries, and less like control messages.  This is not a desirable quality.

It's true that, for example, the DNS packet compression format would have to deal with this specially, but that would also be true if this were done EDNS0-style.   It's true that packet dumpers would have to deal with this specially, but that's also true if it's done EDNS0-style.   Etc.

It may be that there is a good point in your argument somewhere, but at the moment, I don't see one.   E.g., in your python example, yes, if this were an RR, not being able to plop it into your RR-handling switch would suck.   But it's not an RR, doesn't have the semantics of an RR, and if you plop it into your RR-handling switch, you're probably getting the semantics wrong.

So if you want to make this case, I think you need to be more specific about why this is a problem: when I think about how to implement this (which I have done, because I'm using it for dnssd), what you are advocating seems harder, not easier, than what is currently being proposed.

---

From: Petr Špaček <[email-masked]>
Date: Tue, 18 Jul 2017 15:02:47 +0200

On 11.7.2017 13:23, Ted Lemon wrote:
> On Jul 11, 2017, at 3:17 AM, Petr Špaček <[email-masked]
> <mailto:[email-masked]>> wrote:
> Petr, with all due respect, I did not see a counter-proposal here, and
> your comments seem to reflect a misunderstanding of what
> session-signaling is.
> 
> In fact, the opposite of what you said is true: if this were done as a
> normal query with EDNS0-like encapsulation, _then_ we would see
> problems, because session signaling messages would look more like DNS
> queries, and less like control messages.  This is not a desirable quality.
> 
> It's true that, for example, the DNS packet compression format would
> have to deal with this specially, but that would also be true if this
> were done EDNS0-style.   It's true that packet dumpers would have to
> deal with this specially, but that's also true if it's done EDNS0-style.
>   Etc.

Let me clarify that I'm not insisting specifically on EDNS0. From my
perspective anything which does not deviate from current wire format is
okay.

> It may be that there is a good point in your argument somewhere, but at
> the moment, I don't see one.   E.g., in your python example, yes, if
> this were an RR, not being able to plop it into your RR-handling switch
> would suck.   But it's not an RR, doesn't have the semantics of an RR,
> and if you plop it into your RR-handling switch, you're probably getting
> the semantics wrong.

This might be key to the the misunderstanding:

I'm not talking about semantics at all. What I object to is the proposed
wire format, not the semantics. The fact that bytes are stored in format
compatible with RR (RFC 1035 section 4.1.3) is not related to its semantics.

> So if you want to make this case, I think you need to be more specific
> about why this is a problem: when I think about how to implement this
> (which I have done, because I'm using it for dnssd), what you are
> advocating seems harder, not easier, than what is currently being proposed.
I'm trying to explain that deviance from RR format (RFC 1035 section
4.1.3) will force parties in the DNS ecosystem to implement support for
the new wire format even though they are not interested in session
signaling at all.

For a lot of cases it would be sufficient if SS data could be treated as
one of many "unknown RR types" (RFC 3597). For example tools for
statistics would work, the capture formats would not need special
extensions for SS, etc.

We can discuss this in depth during dnsop session today.

-- 
Petr Špaček  @  CZ.NIC

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Jul 2017 13:15:35 +1000

In message <[email-masked]>, =?UTF-8?B?UGV0ciDFoHBhxI1law==?= writes:
> > On Jul 11, 2017, at 3:17 AM, Petr paek <[email-masked]

Hogwash.  Servers which are unaware of the opcode will return NOTIMP
or FORMERR depending on how forward thinking the developer was.

If you have a packet dumper YOU ALREADY HAVE TO ACCOUNT FOR THIS.
There are ZERO guarentees that a packet addresses to/from port 53
is a DNS packet.  If your packet dumper can't handle these then
it is already broken.

If you are just proxying DNS messages this should be transparent. If
the proxy is parsing the message then it returns NOTIMP or FORMERR.

> Petr paek  @  CZ.NIC

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Petr Špaček <[email-masked]>
Date: Wed, 19 Jul 2017 15:45:15 +0200

>> We can discuss this in depth during dnsop session today.
WG decided to go forward with TLV format. I still think it is a mistake
but I'm going to respect WG decicion and thus I'm giving up. Further
discussion on this topic is pointless.

-- 
Petr Špaček  @  CZ.NIC