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

[Petr Špaček <[e-mail]>]

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

On 4.7.2017 01:40, [e-mail] wrote:
> 
> 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/