Subject: [DNSOP] ECS badly formatted ADDRESS field

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 24 Dec 2015 08:01:14 +0530

Hi all

https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-06

says in Section 6. Option Format:

>   o  A server receiving an ECS option that uses more ADDRESS octets
>      than are needed, or that has non-zero bits set beyond SOURCE
>      PREFIX-LENGTH, SHOULD return REFUSED to reject the packet, as a
>      signal to the developer of the software making the request to fix
>      their implementation.

FORMERR seems more appropriate than REFUSED for an implementor to notice
format issues, and perhaps this has been raised on this list already. If
you can change this, please change this to FORMERR.

I have a related clarification. What if the ADDRESS field has fewer
octets than than SOURCE PREFIX-LENGTH indicates? Should REFUSED or
FORMERR be returned in this case? The draft must clarify this if it's
requiring REFUSED.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 24 Dec 2015 08:33:27 +0530

> FORMERR be returned in this case? The draft must clarify this if it's

I also suggest describing implementation behavior with FAMILY=0 clearly
in section 6 (option format). This is described all over the draft.

Example, section 7.2.1 (authoritative nameserver) says:

>   The FAMILY, SOURCE PREFIX-LENGTH and ADDRESS in the response MUST
>   match those in the query, unless the query specified only the SOURCE
>   PREFIX-LENGTH for privacy (with FAMILY and ADDRESS set to 0).

1. It is not clear how SOURCE PREFIX-LENGTH makes sense by itself
without knowing what FAMILY it is targetting. How can it be 0 with
FAMILY=0?

2. I assume ADDRESS is missing here, not set to 0? Or are ADDRESS octets
present to match SOURCE PREFIX-LENGTH and they are set to 0 bits?
ADDRESS field should be undefined if FAMILY=0. It is better to clearly
state all this under section 6 (option format).

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 24 Dec 2015 08:49:27 +0530

Also note that section 7.2.1 is almost disagreeing with the above:

>   A query with a wrongly formatted option (e.g., an unknown FAMILY)
>   MUST be rejected and a FORMERR response MUST be returned to the
>   sender, as described by [RFC6891], Transport Considerations.

		Mukund

---

From: 神明達哉 <[email-masked]>
Date: Wed, 30 Dec 2015 15:33:16 -0600

At Thu, 24 Dec 2015 08:33:27 +0530,

> in section 6 (option format). This is described all over the draft.

On re-reading the draft, I happen to have the same question that I've
not noticed in my previous phases of review.

> state all this under section 6 (option format).

+1 on these should be clarified.  It's also not clear what the
authoritative server should do if "only the SOURCE PREFIX-LENGTH"
should be specified (whatever it means).  The draft only suggests this
case is an exception by the word 'unless', but it's not clear to me
what the server should do instead in this case.

There's also at least one other phrase of 'ADDRESS set to 0':

   includes a non-zero ADDRESS, it MUST retry with FAMILY and ADDRESS
   set to 0.
(Section 7.1.3)

This should be also clarified as well as any other similar cases I
might be missing.

I also have one related question on Section 7.3:

   For a response to a query which specified only the
   SOURCE PREFIX-LENGTH for privacy masking, the FAMILY and ADDRESS
   fields should contain the appropriate non-zero information for
   caching.

On a re-read I just realized this sentence isn't clear enough to me.
Aside from what "specified only the SOURCE PREFIX-LENGTH" means,
precisely what does this mean? "the FAMILY and ADDRESS fields should
contain the appropriate non-zero information"

Does this mean the authoritative server should (somehow) have set the
FAMILY and ADDRESS to a non-zero value (see also about the other
question above on what the authoritative server should do)?  Or does
it mean the cached entry for such a response should be taken from the
source address of the very original query (i.e. the query that the
Intermediate Nameserver received)?  Or something else?

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Wed, 30 Dec 2015 16:14:07 -0600

At Thu, 24 Dec 2015 08:01:14 +0530,

> you can change this, please change this to FORMERR.

My understanding is that it's fodder for the imaginary followup
standard document (whether it's FORMERR or something else may still be
debatable, but should at least be something other than REFUSED).  I
believe you can find the discussion that led to this conclusion in the
ML archive (I didn't like it either but that seemed to be the "rough
consensus").

--
JINMEI, Tatuya

---

From: Paul Vixie <[email-masked]>
Date: Wed, 30 Dec 2015 14:28:48 -0800

> ML archive (I didn't like it either but that seemed to be the "rough

if the intent is to document existing practice and existing implementations send REFUSED in 
this situation, then the document should say that. but the document should also say that 
FORMERR is the correct signal.

REFUSED means that some other name server might be willing to process the query. 
FORMERR means that no name server could process this query.

-- 
P. Vixie