Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-04.txt

Paul Wouters <paul@nohats.ca> Wed, 14 March 2018 22:07 UTC

Return-Path: <paul@nohats.ca>
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 B9003126E01 for <dnsop@ietfa.amsl.com>; Wed, 14 Mar 2018 15:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 FisTYMt5_7RB for <dnsop@ietfa.amsl.com>; Wed, 14 Mar 2018 15:07:34 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 38604124205 for <dnsop@ietf.org>; Wed, 14 Mar 2018 15:07:34 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 401m6p72BQzFTX; Wed, 14 Mar 2018 23:07:30 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1521065251; bh=1dzwHfErBfD4Zq0fAiF0nkZ79ZnXBitj0PmRvK3cb4M=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LQozl/VnR3KJ2mR0EQ8kgjjvTKDpRDxb3oNFA4xocEO3XJnzH1NoOLJ/CKBjR72fC kzoJKalT725SGhT/a6ODt66fOGgEhgVH6+BvmdFiu4PPAzMOfpfMPf58ioWR7mifxN 3j1hwjLh463sNBdtcZmhkferv2UnKXAlAaGWPYlQ=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 8Du7WK2bOTXc; Wed, 14 Mar 2018 23:07:29 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 14 Mar 2018 23:07:29 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 640BB366701; Wed, 14 Mar 2018 18:07:28 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 640BB366701
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 57F454023332; Wed, 14 Mar 2018 18:07:28 -0400 (EDT)
Date: Wed, 14 Mar 2018 18:07:28 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Peter van Dijk <peter.van.dijk@powerdns.com>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <284032BE-285A-499D-906C-9C24E5901B25@powerdns.com>
Message-ID: <alpine.LRH.2.21.1803141744550.16094@bofh.nohats.ca>
References: <152026531853.14559.3697718467935375329.idtracker@ietfa.amsl.com> <284032BE-285A-499D-906C-9C24E5901B25@powerdns.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/46sECmTiwuPNa-JmNuR7GmQJGVU>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-04.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: Wed, 14 Mar 2018 22:07:38 -0000

On Mon, 5 Mar 2018, Peter van Dijk wrote:

> Please find below revision 04 of the XPF draft. We believe all concerns 
> previously raised have been addressed in this version.

> We’d like to ask the WG to consider adoption. Ray and myself will be present 
> at IETF101 if you want to discuss.

>> Htmlized:        https://tools.ietf.org/html/draft-bellis-dnsop-xpf-04

While I was initially afraid of abuse of this feature, the document has
addressed this issue very well. So as long as implementors follow the
specification, I think this document poses no privacy risk.

I'm in favour of adoption.

Some nits:

Section 3.1:

    Stub resolvers, client-side proxy devices, and recursive resolvers
    MUST NOT add the XPF RR to DNS requests.

Can this be extended to say what these should do when receiving or
forwarding these?g

Section 3.2:

    If a server finds this RR anywhere other than in the Additional
    Section of a request it MUST return a REFUSED response.

    If the value of the RR's IP version field is not understood by the
    server it MUST return a REFUSED response.

Why return REFUSED instead of FORMERR for these ?


    Servers MUST NOT send this RR in DNS responses.

Can this be extended to include "not forward these packets" as well?

Setion 3.4:

Why SHOULD and not MUST? Can you give an example of when the SHOULD can
be ignored?

Section 3.5:

    The XPF RR is formatted like any standard RR, but none of the fields
    except RDLENGTH and RDATA have any meaning in this specification.

If these fields don't matter, can we mandate a setting for these? I
guess we can because you do :) So maybe this text can be omitted or
changed to reflect that?

My petpeeve: using +---+---+---+---+---+---+---+ instead of +---------+-----------+
I find the overuse of +-+-+ reduces readability.


    Implementations MUST support IPv4 (4) and IPv6 (6).

I would not say this. In the happy future where we are mostly/only v6,
we wouldn't want to issue an update to this RFC just to kill this sentence.

Section 3.6:

This could use an example.

Section 4:

It could mention DNS-COOKIES as one way to avoid spoofing issues.

Paul