Subject: dropping sets, was Re: Comments on restrict key

From: Ed Lewis <[email-masked]>
Date: Fri, 10 May 2002 11:08:18 -0400 (EDT)

I think it would be a good thing to dicuss how, when, and under what sets
of rules the DNS discontinues the use and dissemination of data that
is loaded.  Mind you that is what I believe is the situation, I may be
wrong, but at least the resulting flames will help me build character.

There are currently four points at which data is "choked off."  First is
the zone loading process.  Second is the TTL - provided for data base
coherency.  Third is credibility, as defined in RFC 2181, which probably
can be more generalize into "protocol rules."  Finally, there
is DNSSEC.

What we need to avoid is arbitratry stemming of data flow as this
situation harms troubleshooting.  (See route filtering, not that filtering
routing is bad but that it does make troubleshooting connectivity harder.)
The danger in DNS is that if we have too many data filters in place, the
system gets muddled, bad things happen, and we can't figure out how to
right the ship.

So, perhaps this summary may set the tone for any "drop the data"
discussion.

First, at zone loading, if there is a serious problem with a data set,
then it is probably wise to not load the zone at all.  For less serious
problems, then logging a warning is appropriate.  In any case, the server
is not to modify the resulting zone.  I.e., the admin should see in an
AXFR query the same data that is in the loaded zone file (modulo dymanic
updates).  (My opinion, at least.)

Second, the TTL is used strictly to improve the coherency of the caches in
the database.  TTL's can be set by the policy of the cacher, but this does
not change the meaning of the data.  TTL rules should never be confused
with the SIG validity period of data in DNSSEC processing.

Third, credibility and the other rules in RFC 2181 are "really good ideas"
in reducing DNS problems.  E.g., data sets are never merged and data is
cached if it is more believeable than what is currently held.  (Whether
glue is used in an answer is part of these rules.)  Probably a more
general grouping for these drop rules are "by protocol rule."

Finally there is the DNSSEC processing.  Here I am talking about KEYs and
SIGs.  (TSIG, dynamic update, etc. more or less are special cases of zone
loading - in a general sense.)  This kind of data trimming is done prior
to accepting data into caches and in some cases when the decision is made
to send data onward (some confusion on my part about what happens when a
+cd check is made, followed by one with check).  Part of this is whether
to use data in the validation process, e.g., a KEY RR.

So, when ever we are discussing "dropping" data, we should see what
category the dropping fits into.

Now, it seems to me that the key-restrict rules would govern whether a
suspect KEY RR set is used for a validity check.  My problem is that I
can't see under what set of conditions KEY RR sets would be singled out
for "dropping."  The problem is that only during zone loading do we
examine the RDATA of records (mostly to just parse the database format
into wire format), which is what key-restrict wants to do in the normal
course of the protocol.

Perhaps a server should not load a zone with an non-conformant KEY RR set.
However, you can't really rule out the existing set of name servers, or
you will really be begging for trouble.  Remember the "flag day" is for
DNSSEC only, not all of DNS.

Anyway, just thoughts, and some of what is behind my "middlebox"
commentary.

 On Thu, 9 May 2002, Andy W. Barclay wrote:

> 
> 
> Sam Weiler wrote:
> 
> > On Thu, 9 May 2002, Scott Rose wrote:
> > 
> > 
> >>Personally, I am in favor of "dropping the entire RR set" if an
> >>invalid KEY RR is encountered in a set, but there might need to be
> >>more debate on this issue.
> >>
> > 
> > If we care about the following, then the answer should not be "drop
> > the entire RR set":
> > 
> > A malicious cache (or a malicious dnsspoof) returns to the client:
> >   -- a real KEY RR (#1)
> >   -- a SIG(KEY) on that RR
> >   -- an additional KEY RR (#2)
> > 
> > What should the client do?  A dumb client will try to validate the SIG
> > for the KEY RR set containing both 1 and 2, fail, and drop the entire
> > RRset.
> 
> 
> I don't see the problem here... The client should do exactly that.
> Drop the set. END.
> 
> 
> > A smarter client will try to validate the SIG(KEY) for all
> > subsets of the KEY RR set it received, eventually finding the valid
> > subset.  To reduce the workload, it should start with the subsets of
> > the expected size (1 or 2 KEYs) and go up from there, but this still
> > presents an opportunity for an attacker to consume some CPU cycles.
> 
> 
> Doing this would be wrong. The SIG is supposed to sign the set. There is
> no need to check subsets.
> 
> 
> .... snip.....
> 
> 
> -- 
> Regards,
> Andy W. Barclay.        [email-masked]
> fax  (781) 823-8276
> Always a UNIX Evangelist (and sometimes a system and network architect)
> 
> The truth of a proposition has nothing to do with its
> credibility. And Vice-Versa.
> 
> 
> --
> 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/>
> 

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