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

P Vix <paul@redbarn.org> Tue, 11 July 2017 07:34 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EECE1319BB for <dnsop@ietfa.amsl.com>; Tue, 11 Jul 2017 00:34:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPBD6ExVavq1 for <dnsop@ietfa.amsl.com>; Tue, 11 Jul 2017 00:34:16 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFCBD124D37 for <dnsop@ietf.org>; Tue, 11 Jul 2017 00:34:16 -0700 (PDT)
Received: from [10.40.6.70] (unknown [111.205.113.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 2EFBC61FF3; Tue, 11 Jul 2017 07:34:14 +0000 (UTC)
Date: Tue, 11 Jul 2017 07:34:12 +0000
User-Agent: K-9 Mail for Android
In-Reply-To: <89e8d29c-1692-732c-df3b-8b7915415629@nic.cz>
References: <149912520399.16222.12738253224617069728@ietfa.amsl.com> <89e8d29c-1692-732c-df3b-8b7915415629@nic.cz>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----HPOXWAIERH5PWOXF9I1SKCYU4X06LC"
Content-Transfer-Encoding: 7bit
To: dnsop@ietf.org,=?UTF-8?Q?Petr_=C5=A0pa=C4=8Dek?= <petr.spacek@nic.cz>
CC: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= <ondrej@sury.org>
From: P Vix <paul@redbarn.org>
Message-ID: <757B489C-2CA5-4B92-B8BF-71991E0A7B68@redbarn.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/AgHChvgmZChkXh75gsvgOPsHVwQ>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-03.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jul 2017 07:34:20 -0000

+1

On July 11, 2017 3:17:57 PM GMT+08:00, "Petr Špaček" <petr.spacek@nic.cz> wrote:
>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, internet-drafts@ietf.org 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/
>
>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop

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