Subject: Re: [dnsext] EDNS Ping fallbacks

From: Paul Vixie <[email-masked]>
Date: Sun, 31 May 2009 17:56:11 +0000

> From: "George Barwood" <[email-masked]>
> Date: Sun, 31 May 2009 18:16:40 +0100
> 
> There seems to be a perception that EDNS Ping "does not work", because a
> spoof response that does not contain the Ping option will be accepted.

not merely "will be accepted" but "must be accepted".

> This is true for a naive use of EDNS Ping, but it does not mean EDNS Ping
> is not useful.
> 
> There are many possible strategies that can be used.
> 
> (1) Send two (Ping) requests in parallel. If both come back with no Ping,
> assume the server has not yet implemented EDNS Ping, and accept either.
> 
> Disadvantage: security with servers that have not been upgraded is not
> improved.

there are lots of other disadvantages to this including increased load on
networks and servers, and loss of determinism when both responses come back
with or without PING but the two answer sections differ.

> (2) Send a single (Ping) request. If the response does not have the Ping,
> and "BadID environment*" is poor, return SERVFAIL, and alert the
> operator.
> 
> Disadvantage: attacker can force DoS if server has not been upgraded.

we should have learned by now that giving attackers the ability to alter
our behaviour modally is an automatic lose, a guaranteed bad idea, even if
we don't know up front how they would use it.  so, do not underestimate
the strength of the disadvantage you have noted here.

> (3) Adopt more complex fallbacks, such as comparing multiple responses to
> infer a safe result, or a restrictive ( but less efficient ) cache
> policy.

loss of determinism is bad.  and, there's no reason why any two valid
responses would ever have the same answer section.  do not underestimate
the strength of the disadvantage you have noted here.

> Clients may also maintain state information to minimise the number of
> extra packets required.

in EDNS the requestor (i won't say "client" -- i'm thinking server-to-server)
only has to hold state about unupgraded responders, with the intent being
that this state load drops over time (as the internet upgrades).  new state
loads should be evaluated along the same metric.

> This description of possible fallbacks is certainly not complete, but we
> don't need to fully understand all the possible strategies to see that
> EDNS Ping MAY be a useful and practical way to improve DNS security and
> efficiency.

i disagree.  you have effectively and resoundingly damned EDNS here for any
kind of extended TXID.  (that's why EDNS did not include such originally.)

we have to start a transition away from UDP/53 (which is not upgradeable in
place due to many failings including reliance on IP fragmentation) and TCP/53
(which is too fragile to be relied upon for queries, even as a fallback).  i
don't think we should exert more energy on these two transports now that we
know what the problems really are.  let's consider SCTP.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>