Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-05.txt

Richard Gibson <richard.j.gibson@oracle.com> Thu, 01 March 2018 03:52 UTC

Return-Path: <richard.j.gibson@oracle.com>
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 2CAF712E054 for <dnsop@ietfa.amsl.com>; Wed, 28 Feb 2018 19:52:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level:
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
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 Vkluyvm0daZj for <dnsop@ietfa.amsl.com>; Wed, 28 Feb 2018 19:52:19 -0800 (PST)
Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27A9120454 for <dnsop@ietf.org>; Wed, 28 Feb 2018 19:52:19 -0800 (PST)
Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w213qHLq186579; Thu, 1 Mar 2018 03:52:17 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=yT8/ccWwBEAy6KuK9B10V2m0R5H4jHx1DUATVxTulLg=; b=BnY3NS81fDJOVJ6cYj326kNvtOE+bnsw2rszLvNUMFwvFgv1Qs2ky16PUNv48wZMRW5j kdAPXfpb6XxMU3rGqVVQ+uG6C1Is/QB2bAnNCWJAwVODB+aWxwil8kJCnzl5w0cOQZQU FoMxXWC0S3B3Nx52zenZEgR+uWSMOI9PX4Y2K3KD7O6RjQTCPk1Y0ItsVdPvBVsWRFax wiM85YQsDTinQhgMz7ZW4HcnQXfbI/rOtPziktLw7tt4YJCiKIQ17es8pIcE4vdta1xJ atU0hjrfMo6h9TGarJstGdLjgo+xpvANhSrjl8gYIDoxDBY61vZc3KxQSyj6OAA6QH8s GQ==
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2ge8xgr51w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 01 Mar 2018 03:52:17 +0000
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w213qGqx022222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 1 Mar 2018 03:52:16 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w213qE0I023023; Thu, 1 Mar 2018 03:52:14 GMT
Received: from [172.19.128.110] (/216.146.45.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Feb 2018 19:52:14 -0800
To: Jim Hague <jim@sinodun.com>, Sara Dickinson <sara@sinodun.com>, IETF DNSOP WG <dnsop@ietf.org>
References: <151930246857.21149.14743687777831082425@ietfa.amsl.com> <522CCFCA-F01F-4D68-A7FB-D14B0F14C07D@sinodun.com> <2a60a875-0f5a-3586-097d-12ec711af5cf@oracle.com> <376b9d26-edc0-f521-be2e-7ed278850abc@sinodun.com>
From: Richard Gibson <richard.j.gibson@oracle.com>
Message-ID: <96b94dc5-223a-070d-9b59-fd702f0cac9a@oracle.com>
Date: Wed, 28 Feb 2018 22:52:13 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <376b9d26-edc0-f521-be2e-7ed278850abc@sinodun.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8818 signatures=668682
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803010048
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/YacobWuNTAM-yWP6SYTegTX0C4I>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-05.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, 01 Mar 2018 03:52:21 -0000

On 02/28/2018 12:21 PM, Jim Hague wrote:
> We'll discuss this. We absolutely meant for negative keys to be
> restricted to closed systems. Allowing string keys in addition is an
> interesting idea; off the cuff, I wonder whether folk will want to pay
> the file space penalty.
The cost of interoperability. An understandable concern for raw files, 
but repetitions of the same string keys would compress extremely well.
>> * Section 7.4.1.1: StorageParameters fields "opcodes" and "rrtypes"
>> could be defined better... are they values /recorded/ (i.e., that were
>> actually observed) or values that are /recordable/ (i.e., that the
>> collection application was looking for)? And shouldn't they be optional
>> (in either case, but *especially* the latter, lest implementations write
>> out every possible rrtype value).
> The intention is that they should be /recordable/ values - in line with
> the rest of the StorageParameters fields, they let a reader distinguish
> values that aren't present because the writer didn't understand them and
> values not present because they didn't occur in the data stream. And
> yes, we're thinking implementations should explicitly write each opcode
> and rrtype they understand.
Especially in our closed system, I don't see us keeping current another 
list of supported RR types. So we'd probably leave the array empty, 
violating the spirit of the spec if not the letter of it. But on the 
plus side, the size of the complete list in CBOR was smaller than I 
anticipated—less than 100 bytes.
> The thinking here is that
> if, say, an rrtype the writer does not know how to decode contains a
> compressed label, it's not going to be correctly handled, and we should
> not be recording potentially known-broken data in the file as not malformed.
I sure hope that no new types violate RFC 3597 section 4. The problems 
with corrupted data in captures pale in comparison to the problems with 
corrupted data in live messages.
> We need to clarify the language. qr-transport-flags is a single bit
> IPv4/v6, a 4 bit number indicating the protocol, and a final single bit
> indicating the presence of trailing data in the query. The protocol
> values are (currently) UDP=0, TCP=1, TLS=2, DTLS=3. We did consider a
> UDP/TCP bit and a !TLS/TLS bit, but felt this (a) might imply a closer
> connection between TLS and DTLS than is the case, and (b) would not
> easily extend to possible future schemes like DOH and DNS over QUIC. So
> we went for a number with sufficient range to add another 12 options
> before trouble happens. We considered breaking the number out to a
> separate integer, but felt that this was likely, in practice, to be
> unnecessary and so space efficiency considerations took precedence.
Thank you, that explanation greatly clears things up and the reasoning 
is sensible. I would recommend updating the text to something like "Bit 
1-4. Transport. 0000 = plain-text UDP, 0001 = plain-text TCP, 0010 = TLS 
[over TCP?], 0011 = DTLS [over UDP?]" (with a note in Section 7.2 that 
bit sequences are presented in descending significance).