Subject: Re: [dnsext] EDNS clarification

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

> From: "George Barwood" <[email-masked]>
> Date: Sun, 31 May 2009 17:52:36 +0100
> 
> RFC 2671 does not appear to explicitly document how an EDNS responder
> should treat unrecognised options.
> 
> May I suggest that any future revision of RFC 2671 ( and/or the
> "Clarifications and Implementation Notes for DNSSECbis" document ),
> should contain a statement along the lines:
> 
> "Responders MUST disregard (ignore) unrecognised EDNS options."

this was the topic of an I-D some years ago by rob austein entitled EDNS0_5
but it didn't reach escape velocity since the WG did not reach consensus as
to the need for a version number change to reflect this behaviour.

> This may seem fairly obvious, and I assume this was the intention, but
> given the history of DNS, I think an explicit statement would be best.
> 
> Fortunately existing EDNS implementations do seem to follow this policy.

agreed.

--
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/>

---

From: Paul Vixie <[email-masked]>
Date: Sun, 31 May 2009 20:08:54 +0000

> Date: Sun, 31 May 2009 20:54:19 +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".
> 
> It is entirely a matter of local policy what a the requestor chooses to
> accept.

that's just not true.

> > there are lots of other disadvantages to this including increased load
> > on networks and servers,
> 
> I don't believe the extra network/server load is significant. Once most
> servers are upgraded, clients would only send a single packet initially,
> and send the second only if no PING was received.

you're assuming a lot here.  like, most servers will be upgrade.  and, there
aren't a huge and growing and high-churn lot of initiators.  and, servers are
real boxes not anycast clusters which might not all have been upgraded.  and,
servers are never downgraded.  i do not share those assumptions.

> > and loss of determinism when both responses come back
> > with or without PING but the two answer sections differ.
> 
> No, if any response comes back with PING it can be safely accepted, and
> all other responses ignored.

so you'd go with the first response you receive even if the first and second
were reorded in transit.  this is a loss of determinism.

> >> (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.
> 
> It's up to the requestors local policy, for many applications I think (2)
> would be completely practical.  An attacker gains very little from this
> DoS attack, so I doubt it would be a significant problem.

if you think that any of us is smarter today than attackers will be tomorrow,
and that it is therefore safe to give attackers a "mode switch" on our DNS
initiators, then there is an unbridgeable gap in our understandings.

> > ...  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.
> 
> I don't think SCTP is a good solution, the extra latency would I believe
> be unacceptable.

what extra latency?  session setup is two packets.  data is exchanged in
the second round trip.  session setup is lightweight, there's no reason to
close sessions unless you have more than 10X as many sessions are there are
authority and recursive nameservers on the internet today.  what extra
latency?

> Two Ping requests are similar to an SCTP transaction, but have the
> advantage that there is no extra latency.

EDNS is subject to downgrade attacks far more trivial than those needed for
SCTP, and EDNS depends on IP fragmentation for large message sizes which has
not worked out very well for us so far.

> For large (typically DNSSEC) responses, SCTP (or similar) may be a good
> idea, but that is a seperate issue.

the need for large responses is not typically for DNSSEC, though that will
change as DNSSEC gets more widely deployed.