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

From: "Peter van Dijk" <[email-masked]>
Date: Mon, 05 Mar 2018 17:25:51 +0100

Hello dnsop,

Please find below revision 04 of the XPF draft. We believe all concerns 
previously raised have been addressed in this version. Additionally, two 
implementations (both in PowerDNS products) have popped up, along with 
two decoders (Wireshark, and [not mentioned in -04] tcpdump). As authors 
we feel this is a good time to ask for adoption of the document.

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

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

Forwarded message:

> From: [email-masked]
> To: Ray Bellis <[email-masked]>, Remi Gacogne 
> <[email-masked]>, Peter van Dijk 
> <[email-masked]>, Rémi Gacogne 
> <[email-masked]>
> Subject: New Version Notification for draft-bellis-dnsop-xpf-04.txt
> Date: Mon, 05 Mar 2018 07:55:18 -0800
>
> A new version of I-D, draft-bellis-dnsop-xpf-04.txt
> has been successfully submitted by Peter van Dijk and posted to the
> IETF repository.
>
> Name:		draft-bellis-dnsop-xpf
> Revision:	04
> Title:		DNS X-Proxied-For
> Document date:	2018-03-05
> Group:		Individual Submission
> Pages:		10
> URL:            
> https://www.ietf.org/internet-drafts/draft-bellis-dnsop-xpf-04.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-bellis-dnsop-xpf/
> Htmlized:       https://tools.ietf.org/html/draft-bellis-dnsop-xpf-04
> Htmlized:       
> https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-xpf-04
> Diff:           
> https://www.ietf.org/rfcdiff?url2=draft-bellis-dnsop-xpf-04
>
> Abstract:
>    It is becoming more commonplace to install front end proxy devices 
> in
>    front of DNS servers to provide (for example) load balancing or to
>    perform transport layer conversions.
>
>    This document defines a meta resource record that allows a DNS 
> server
>    to receive information about the client's original transport 
> protocol
>    parameters when supplied by trusted proxies.
>
>
>
>
> 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.
>
> The IETF Secretariat

---

From: Paul Wouters <[email-masked]>
Date: Wed, 14 Mar 2018 18:07:28 -0400 (EDT)

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

> 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

---

From: Ray Bellis <[email-masked]>
Date: Thu, 15 Mar 2018 10:01:00 +0000

> Can this be extended to say what these should do when receiving or

I think it would suffice to replace "client proxy devices" with "client
side proxies or forwarders".

> Why return REFUSED instead of FORMERR for these ?

That's fair, those are arguably "illegal packets" rather than "policy
rejected".

There's perhaps also an omission here w.r.t the "Protocol" field which
is not mentioned in this context.

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

I don't think that fits here.   If the server is being used as a
front-end forwarder for a server farm than adding XPF would be appropriate.

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

When the server doesn't implement XPF?  I think this wording was there
to prevent a charge of imposing retrospective mandates.

We could perhaps change that to say that "an XPF-capable server MUST ..."

> guess we can because you do :) So maybe this text can be omitted or

OK, will look at that.

> My petpeeve: using +---+---+---+---+---+---+---+ instead of

That's one for the WG, I think, on adoption.  With sub-octet fields
present it makes the size of those fields completely explicit.

I also personally find it much more legible than the 32-bits per line
using '+-+-...' that e.g. RFC 791 (IP) uses.

It may be hard to reach consensus :p

> we wouldn't want to issue an update to this RFC just to kill this sentence.

I appreciate the sentiment, but I think it highly unlikely that the
original IPv4 specification will ever be rendered completely historic.

If that does ever happen, the RFC that does it can just update this one
without requiring a -bis.

> This could use an example.

OK.

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

That sounds like a good idea.

thanks for the review!

Ray

---

From: Ray Bellis <[email-masked]>
Date: Thu, 15 Mar 2018 10:41:28 +0000

> That sounds like a good idea.

On reflection (and discussion with one of my co-authors) we think that
would be problematic.

Don't forget that the issue here is non-spoofability of the internal
channel _between the front-end forwarder and the back-end server_, and
not end-to-end.

Using DNS Cookies there would require manipulation of the packet
contents of exactly the sort that earlier versions of this draft had
when it used EDNS instead of a meta-RR.

Ray

---

From: Paul Wouters <[email-masked]>
Date: Thu, 15 Mar 2018 10:45:04 -0400 (EDT)

> channel _between the front-end forwarder and the back-end server_, and

Makes sense. So forget about DNS-COOKIES :)

Paul