Subject: [DNSOP] Suresh Krishnan's No Objection on draft-ietf-dnsop-dns-capture-format-08: (with COMMENT)

From: Suresh Krishnan <[email-masked]>
Date: Wed, 21 Nov 2018 06:43:47 -0800

Suresh Krishnan has entered the following ballot position for
draft-ietf-dnsop-dns-capture-format-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Section 7.4.1.1.

Looks like you can limit the {client,server}-address-prefix-{ipv4,ipv6} fields
to one byte to restrict the range. e.g.

client-address-prefix-ipv6 => uint .size 1

Similar restrictions can be used for port (2) and TTL/hop limit (1) fields.

---

From: Jim Hague <[email-masked]>
Date: Thu, 22 Nov 2018 12:53:15 +0000

> draft-ietf-dnsop-dns-capture-format-08: No Objection

Thanks for the review.

We already specify IPv4 and IPv6 addresses with a size:

IPv4Address = bstr .size 4
IPv6Address = bstr .size 16

so we think that similarly emphasising the constraints on the address
prefix lengths would be consistent. Rather than .size, we think a range
more appropriate, i.e.:

OLD: "? client-address-prefix-ipv4 => uint,
      ? client-address-prefix-ipv6 => uint,
      ? server-address-prefix-ipv4 => uint,
      ? server-address-prefix-ipv6 => uint,"

NEW: "IPv4PrefixLength = 1..32
      IPv6PrefixLength = 1..128"

     "? client-address-prefix-ipv4 => IPv4PrefixLength,
      ? client-address-prefix-ipv6 => IPv6PrefixLength,
      ? server-address-prefix-ipv4 => IPv4PrefixLength,
      ? server-address-prefix-ipv6 => IPv6PrefixLength,"

As to whether there is value in applying size or range restrictions
throughout the rest of the fields, we're not so sure. As well as port
and hoplimit, many of the DNS items (e.g. opcode, rcode) could also be
allocated a maximum size. Or possibly we should only put a range on
user-specified items such as VLAN IDs or opcodes to capture.

We'll ask the CBOR WG mailing list if there is a preferred CDDL style
for these cases.
-- 
Jim Hague - [email-masked]          Never trust a computer you can't lift.

---

From: Jim Hague <[email-masked]>
Date: Thu, 29 Nov 2018 12:57:43 +0000

On 22/11/2018 12:53, Jim Hague wrote:
>> Looks like you can limit the
{client,server}-address-prefix-{ipv4,ipv6} fields
>[....]
 The CBOR WG report there is as yet no received style, or in this case
right answer.

In the context of C-DNS, I am inclined to express ranges where values
stored are generated by the C-DNS application, but not for values of DNS
traffic items. C-DNS is storing traffic collected by one means or
another, and I think it should be storing what's reported. Expressing
validity ranges moves towards C-DNS being required to validate the
traffic. We intend C-DNS to be a storage mechanism, not a validation one.

So I suggest we specify validity ranges only for the following
configuration items:

StorageParameters:
* IPv6 prefix length. 1..32.
* IPv4 prefix length. 1..128.
* OPCODE (in list of OPCODEs to collect). 0..15.
* RR TYPE (in list of RR TYPEs to collect). 0..65535 or uint .size 2.

CollectionParameters:
* Promiscuous mode. Make this a boolean, holding CBOR true or false.
* VLAN ID (in list of VLAN IDs to collect). 1..0xffe.
-- 
Jim Hague - [email-masked]          Never trust a computer you can't lift.

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 30 Nov 2018 05:37:17 +0000

> On Nov 29, 2018, at 7:57 AM, Jim Hague <[email-masked]> wrote:
> 

Thanks Jim. That works for me.

Regards
Suresh