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, Petr Špaček <petr.spacek@nic.cz>
CC: Ondřej Surý <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.
- [DNSOP] I-D Action: draft-ietf-dnsop-session-sign… internet-drafts
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-… Petr Špaček
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-… P Vix
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-… Ted Lemon
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-… Petr Špaček
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-… Mark Andrews
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-… Petr Špaček