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

Ray Bellis <ray@bellis.me.uk> Thu, 27 April 2017 09:11 UTC

Return-Path: <ray@bellis.me.uk>
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 CB88C1243FE for <dnsop@ietfa.amsl.com>; Thu, 27 Apr 2017 02:11:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 GK-JkAuAhvMM for <dnsop@ietfa.amsl.com>; Thu, 27 Apr 2017 02:11:12 -0700 (PDT)
Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAC461204DA for <dnsop@ietf.org>; Thu, 27 Apr 2017 02:11:11 -0700 (PDT)
Received: from [46.227.151.81] (port=55357 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1d3fS8-0001wf-LB (Exim 4.72) for dnsop@ietf.org (return-path <ray@bellis.me.uk>); Thu, 27 Apr 2017 10:11:08 +0100
To: dnsop@ietf.org
References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> <A1F0201F-B081-4D36-A1A9-4811250CDB12@cisco.com> <241ada25-4005-403f-0c1a-ce332a58e901@nic.cz>
From: Ray Bellis <ray@bellis.me.uk>
Message-ID: <52b94a85-d0af-ca3c-3c52-2255c1aa73b9@bellis.me.uk>
Date: Thu, 27 Apr 2017 10:11:09 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <241ada25-4005-403f-0c1a-ce332a58e901@nic.cz>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mvybYhAgI3Z_szMfMxi6A8n6UqU>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.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: Thu, 27 Apr 2017 09:11:14 -0000


On 27/04/2017 08:40, Petr Špaček wrote:

> Other people already commented on semantics so I will focus on message
> format:
> 
> My attempts to find reasoning for the new TLV format in archives did not
> yield an elaborate explanation. Assuming I did not miss anything, it
> seems to me that the current TLV format (placed outside of standard DNS
> RR) is going to require brand new code and logic and makes imlementation
> harder than necessary.
> 
> Every DNS server and resolver already has own code to parse DNS RRs do
> various operations with them but this could cannot be reused for the
> current TLV format.
> 
> It would be much easier to implement if we had new RRs like (e.g.)
> "SSOP" and "SSMOD" and placed them inside additional section. We could
> get the same semantics by creating a DNS message with all sections empty
> except "SS*" RRs in additional section. Overhead on wire is negligible
> and it makes implementation much easier and safer (because the normal RR
> handling code is battle-tested already).
> 
> For these reasons I propose to move to standard RR format to enable code
> re-use. Thank you for considering this.

The break from standard RR format is intentional, and in large part to
avoid the tendency to overload the existing meaning of RR fields as was
done with EDNS (i.e. the use of the CLASS field to carry buffer size,
and putting bit fields and extended RCODEs into the TTL field).

It also (intentionally) prevents *mixing* of SS* TLVs and normal RRs
within a session signalling message (or indeed vice versa, putting SS
TLVs into a standard QUERY message).

Yes, it'll need some new code, but it's not difficult code (indeed it'd
be very similar to the code for parsing the RDATA of an OPT RR).

I think the cost of that extra bit of code is outweighed by *not*
needing extra code in the standard packet handling path to cope with
rejecting mixed packets.

Ray