Subject: [dnsext] FR: comments re draft-weaver-dnsext-fr-comprehensive-00.txt

From: "George Barwood" <[email-masked]>
Date: Sat, 18 Oct 2008 21:49:11 +0100

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

My comments on 
http://tools.ietf.org/id/draft-weaver-dnsext-fr-comprehensive-00.txt

>From section 6:

   The algorithm is simple: ... and all cache entries set or dependent
   on the first result should be voided

That seems to me to be actually quite complex, since the dependencies
need to be tracked ( so any use of a NS record to fetch other records
etc. must also be tracked ).

   The state-holding requirements, although nontrivial, are also
   reasonable.  Consider a recursive resolver (or a cluster node in a
   clustered resolver implementation) that generates 10,000 outstanding
   external queries per second.  If the timeout is 1 second, and the
   state-holding required involves 1 KB of data, the additional memory
   requirements would only be 10 MB of data for such a resolver.  Even
   with a longer timeout or a more active resolver, the state-holding
   requirements should be reasonable.

Was the number of ports that need to be left open considered?
Could that be a problem?

>From section 8:

   When a DNS resolver starts, and when a resolver notices that its IP
   address has changed..

The NAT device could change without the resolver IP address changing.
For example the resolver might be using an intermediate computer as
a gateway, or the behavior of a NAT device might change without notice,
for example due switching to a backup device, or any number of possibilties
that cannot be predicted.

So my feeling is that the complexity of attempting this is not justified.

I suggest that duplication is simple and cheap, and will not cause
problems for authorities ( which can probably easily cope with an order
of  magnitude increase in traffic ). The possible exception being the root
and top level domains, where a random prepended nonce can be used to
encode almost unlimited entropy, and authorities behind NAT devices
that may impose very low limits on incoming connections, where using
the same source port for repetition may avoid problems ( needs
research ? )

   If 40b of entropy are available on the request and the resolver is
   not under a significant attack, duplication is not necessary.  Thus
   duplication should be viewed as a fallback position for resolvers
   which are behind a NAT or other entropy stripping device, accessing
   authoritative servers which don't respond to 0x20 (per Dagon et. al's
   proposal [0x20], or is known to be under an active blind attack.

The initial priming query is a high-value target, where repetition is
in my view advisable ( and 0x20 is nil ). Especially if the attacker
can predict the time when the root will be refreshed, by being able to
see the TTL. Similarly the refresh of top level domains. Public
resolvers might choose to refresh early, or to conceal the exact TTL in
some way ( I don't think this is discussed in any of the current drafts ).

   However, it appears reasonable to return one of the values as the
   answer to the transaction, as blind transaction attacks are less
   powerful than blind cache attacks (Section 4).

I'm not sure I have properly followed your logic here, but simple
non-Kaminsky attacks need to be considered. If say only 20 to 25 bits
of entropy are available, and the TTL is 20 seconds, a random attack
on a large number of IP addresses could succeed too easily I think.
At least I'm uneasy about this.

   For the NS record and associated A records, the separate global and
   local scope is approximated by validating the NS RRSet and all
   elements within it using subsequent separate fetches.

With non-deterministic authorities, the seperate fetch might not agree.
If there were just 2 IP addresses for the name servers, you might end
up with a single address, and a loss of resilience.

On uses for additional data : I think you might have missed out the
common usage where authorities return the NS and glue with responses
to keep the TTL high.

With regard to performance, I think it's important to decide whether
extra complexity ( which increases the risk of problems, bugs and
security holes ) is wise. It may not be worth having more complexity
simply to save a few packets that probably won't cause any problems.

>From an engineering perspective, systems are best designed with
reliable layers that can be depended on. Repetition (and 0x20,nonce)
can be implemented in a well-isolated layer where the problem of
spoofing is addressed without complicating the overall design
of the resolver in other areas. It also doesn't disturb the logic of
how the resolver interacts with servers ( except in the non-deterministic
case ).

Hence I argue for straightforward repetition ( which is necesary in
any case IMO ) to achieve acceptable security rather than complex
optimization schemes ( that in any case may use more packets in some
cases ). Simple solutions, provided they work, are to be preferred, IMO.

I also think building in some margin of safety is sensible, which is
why I suggest 50 bits rather than 40. The history of DNS suggests
that we may yet be missing something important, so provided the cost
is not a major problem ( and I suggest that it isn't ), it's best to err
on the safe side, even though of course that gives no guarantee
against our own fallability.

It may be that I am missing something here, and that operators are
very sensitive to the number of packets required, but according to
my rough reasoning this should not be the case. The DNS server load
for an organisation ( other than at the root and TLD operators ), should
be completely insignificant compared to the processing of higher
level applications.

Maybe someone with more operational experience could cast more
light on this question

Kind regards, and apologies if I have laboured the point, repetition is
possibly infectious.
George

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