Subject: [dnsext] Comments on draft-vandergaast-edns-client-ip-00

From: Matthew Dempsky <[email-masked]>
Date: Tue, 30 Mar 2010 17:09:02 -0700

Below are some of my comments on draft-vandergaast-edns-client-ip-00.
The most significant concern is the increased risk of forgeries due to
colliding attacks.  The other concerns are largely editorial, IMO
(e.g., SHOULD vs MUST).

Section 3.  Are the presence and size of the NETMASK and ADDRESS
fields address family-dependent?  The diagram makes them appear to be
family-independent, but it's unclear exactly what "[t]he format of the
address part depends on the value of FAMILY" means here.  As not all
address families have a concept of netmasks, it seems wrong to specify
it that way.  (That said, it's probably moot, as servers will ignore
edns-client-ip options with an unknown address family anyway.)

Additionally, I think there should be a second NETMASK field (herein
referred to as NETMASK2) for responses to use so that the server can
echo the full NETMASK and ADDRESS fields of the client.  I'm mostly
indifferent on whether or not clients should be required to include
this field in query packets: including it would be an extra byte of
useless space overhead but might simplify some code slightly.

The reason for the requiring the server to echo back the client's
NETMASK/ADDRESS fields are to prevent colliding attacks.  E.g.,
suppose a cache receives two queries for www.example.com from separate
IP addresses (1.2.3.4 and 5.6.7.8), and can't answer from cache.

The current draft suggests to me that the cache should send two
queries concurrently to the authoritative server:

    www.example.com A? [client-ip: 1.2.3/24]
    www.example.com A? [client-ip: 5.6.7/24]

An attacker could send a forged response that claims to be valid for
the entire 0/0 address block, and the cache would potentially match it
against either of these outstanding queries, thereby increasing his
chance of successfully poisoning the cache.  If the attacker can send
queries to the cache with forged source addresses, he can improve his
chance of success even further.

Section 4.1.  I disagree with a few uses of MUST here.

"If an edns-client-ip option is included, the FAMILY and ADDRESS
fields MUST be populated with the IP address of the client that
originally initiated the resolution."  I think this requirement should
be a SHOULD.  While I can't think of any particular value to using a
different IP address instead, it doesn't seem like the protocol
requires it for interoperability, so MUST seems overly strong.

"If the incoming query originally contained an edns-client-ip option,
its ... information MUST be used instead, ...."  I strongly disagree
with this.  I think a recursive resolver should be free to choose
whether or not to include the client-provided edns-client-ip option.
I'm not decided on whether MAY or SHOULD is appropriate instead
though.

"A Recursive Resolver set up to serve clients in private address space
...."  I don't see any interoperability harm in allowing private
addresses in queries.  E.g., a resolver that also resolves intranet
names may find it worthwhile when contacting intranet name servers to
provide the client's IP address.  The real risk is in servers handing
out private responses to public clients.

The "For privacy reasons, ..." paragraph seems redundant with the
earlier mention of "The address SHOULD be truncated ...".  If not, the
requirement that "the address MUST be truncated to a certain number of
bits" is unclear.  I don't see a reason to forbid sending the full IP
address, and as no specific number is given, it's impossible to comply
anyway.  (Section 8 suggests 24 bits for IPv4, but offers no advice
for IPv6.)

"A Recursive Resolver MAY be configured to omit the edns-client-ip
option ...."  I agree.  I think it's also worthwhile pointing out that
recursive resolvers may choose other criteria for when to enable the
edns-client-ip; e.g., on a per-client, per-zone, and/or
per-authoritative-name-server (or combination thereof) basis.

Section 4.2.  I think this section will need to be updated slightly to
mention use of the NETMASK2 field.  In particular, the server should
echo back the full NETMASK and ADDRESS values given by the client, and
then use the NETMASK2 field to provide the same caching control that
the current draft uses the NETMASK field for.

One comment though: "The ADDRESS and FAMILY specified MUST match the
ADDRESS and FAMILY in the request ...."  It's not defined what "match"
means here, though I assume it means the first min(query-NETMASK,
response-NETMASK) bits of query-ADDRESS and response-ADDRESS must
match.

Section 4.3.  I think this section will need to be updated slightly to
mention use of the NETMASK2 field.  In particular, if a client sends a
query with an edns-client-ip option, it MUST NOT accept a response
that doesn't contain an edns-client-ip option that contains the same
NETMASK and ADDRESS values it included in its own query packet.

"In the cache, any resource record in the answer section will be tied
to the network specified [...]."  I fully agree with this, though I
think it should be emphasized that the authority and additional
sections are *not* affected.  It's perhaps also worth pointing out
that servers that want optimized A/AAAA records corresponding to their
MX/SRV records can simply omit them from the additional section, and
clients will subsequently query for them directly.

Section 7.  I don't understand the reasoning behind the requirements
related to NAT.

Section 8.2.  I think for the list of recommendations on mitigating
cache pollution, the RFC 2119 terms are appropriate.  I think all of
the "should"s should be replaced with "SHOULD"s.  Also, I think the
requirement that default configurations must disable client-ip should
also just be a SHOULD.

Section 9.  Needs to be updated to mention NETMASK2.

Section 11.  The iana.org URI us used normatively within the document,
so it should probably be listed in the normative references section,
rather than a separate URIs section.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 31 Mar 2010 16:40:28 -0700

On Tue, Mar 30, 2010 at 5:09 PM, Matthew Dempsky <[email-masked]> wrote:
> chance of successfully poisoning the cache.

My reading of section 4.2 was that this type of attack is not
possible, because the address and family in the response must reflect
that of the request. So 0/0 would not be a valid reply - but 1.2.3/0
and 5.6.7/0 would be valid. This seems to suggest that the protocol
actually permits for more entropy in the request/response transaction,
rather than less. Up to 128 bits in the IPv6 case, and 32 bits in the
IPv4 case.

> anyway.  (Section 8 suggests 24 bits for IPv4, but offers no advice

There is no established filtering size yet established amongst the
BGP-using IPv6 community. Personally I think that /48 would be
reasonable boundary, but others have pointed out that this is
non-anonymous for 6to4 users (who are uniquely identified by the /48).
So an anonymity-sensitive solution might require several defaults for
IPv6.

-- 
Colm

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 31 Mar 2010 16:46:22 -0700

2010/3/31 Colm MacCárthaigh <[email-masked]>:
> and 5.6.7/0 would be valid.

No, see paragraph 5 of section 4.2, particularly the second sentence:

   Conversely, a lower NETMASK indicates that more bits than necessary
   were provided.  In this case, the ADDRESS in the reply MUST be
   truncated according to the new NETMASK value, as described in
   Section 3.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 31 Mar 2010 16:58:03 -0700

>   truncated according to the new NETMASK value, as described in

Oh, then I agree that that should be changed.

-- 
Colm