Subject: Re: Clear path requirement

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Nov 2002 10:36:15 -0500

I'm not sure how to take this thread.

The problem is a failure in the end to end assumption of the 
Internet.  Not personally being on top of the the general topic of 
what we colloquially call "NAT," I think the problem is that 
components are interacting with the DNS protocol in a non-compliant 
(with the RFCs) way.

How does a protocol go about hardening itself against miscreant 
devices.  Ignoring the issue I call NAT, this is something that needs 
to be addresses.  Bugs, outages, etc. are cases of "miscreant" action.

There are some basic principles to keep in mind.  First - graceful 
degradation of services.  (Best example of this refers to the loss of 
bandwidth as channels break.)  Another principle is - don't panic. 
By this I mean, don't start complaining needlessly as this just 
irritates the rest of the network.  (E.g., in a diskless environment 
while recovering from a power failure, clients became too aggressive 
in reattaching to the server, causing the server to fall down.  I 
could use a more recent example of a particular resolver and lame 
delegations.)

There are probably other principles, I'd ask others if they can think 
of any.  I'm not claiming to be complete here, but those are the two 
principles I've held most dear.

The first principle says - if we can't get the secure data and can't 
evaluate the security, we might want to just drop the level of 
security.  Ooh - heresy, but faced with less secure or no network at 
all, well, it's your choice.

The second principle says - a few things.

One, whatever the new code does, do not cause harm to the old code. 
E.g., let's avoid the situation that old caches mark servers lame for 
incorrect reasons.

Two, don't screw with the basic architecture to solve this problem. 
Once we fool with the basic nature of the protocol, we begin playing 
with fire.  (E.g., KEY RR's use of the flags as an end-run around the 
name-type-class assumption of DNS and the resulting "key restrict" 
document.)

I just thought of a third principle, which really doesn't apply here.

Explicit recovery.  Don't be afraid to alter some basic assumptions 
while healing the system.  Since we aren't considering system failure 
here, there isn't a "healing" phase to consider.  If we had, well, we 
don't so I won't go there.

So - what do I think should be done (as of now)?  I think we should 
have a DS-aware bit in the message (OPT RR, whatever), we should 
define "DS-lame" as a condition of servers that are DNSSEC-aware but 
not DS-aware, and that when DS-lameness detected, a resolver 
experiences a hard failure and hopefully will retry another "path." 
I think we should not do any kind of tinkering with naming schemes 
because we might then cause servers to have to assemble answers 
differently, and/or run into problems with the concept of credibility 
(RFC 2181) at the resolver.

The previous paragraph is a summary of a message that appeared on the 
[email-masked] list, a draft of a discussion held at a workshop just 
before the IETF 55.  I'd attach a link to the message in the 
archives, but the IETF-net is "not good" right now.  (I can ping 
www.cafax.se, but I can't http://www.cafax.se./dnssec now.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

--
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: "Matt Larson" <[email-masked]>
Date: Wed, 20 Nov 2002 12:32:26 -0500

Edward Lewis wrote:
> have a DS-aware bit in the message (OPT RR, whatever),

Olaf asked this question earlier and no one replied, so I'll ask it
again: Why do we need a DS-aware bit when we've already got the OK bit,
and we're having a flag day anyway?  I really don't want to see a
DS-aware bit--I think that's unnecessarily complicated.

> (RFC 2181) at the resolver.

Name space tinkering doesn't necessarily imply credibility problems if
all the modifications are done at the resolver, i.e., the server needs
no special knowledge and a resolver has to issue a second query to
retrieve the DS record at the "alternate" name (example._ds.com,
_ds_example.com, whatever).  Yes, it's an ugly hack that requires
additional queries, not to mention another NXT and SIG(NXT).  But it
doesn't mess with the fundamental DNS resolution algorithm, which makes
me Very Nervous.

Matt

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Nov 2002 16:07:32 -0500

>DS-aware bit--I think that's unnecessarily complicated.

BIND 9.2 - at least.

>doesn't mess with the fundamental DNS resolution algorithm, which makes

The problem is that caching resolvers attach the credibility to the 
data admitted to the cache.  When a caching server answers from 
cached data, the credibility is part of the equation used to know 
what records to put in the response.

Or so I believe.

---

From: "Matt Larson" <[email-masked]>
Date: Wed, 20 Nov 2002 17:08:55 -0500

Edward Lewis wrote:
>> again: Why do we need a DS-aware bit when we've already got the OK
>> bit, and we're having a flag day anyway?  I really don't want to see
>> a DS-aware bit--I think that's unnecessarily complicated.
>
> BIND 9.2 - at least.

I'm sorry, but I don't understand.  BIND 9.2 is not DS-aware, so it
can't be used as a recursive resolver to retrieve DS records.  Even
though it has support for unknown types, there'll be the problems that
you pointed out in your recent posting on the DNSSEC list.  And do we
really expect someone to try to use BIND 9.2 as an authoritative server
for a zone hosting DS records, again in light of the issues you pointed
out?

I still think the need for a DS-aware flag is obviated by the flag day.

> what records to put in the response.

I think you're assuming that we'd require DS records whose owner name
was mangled to be inserted in responses for other QNAMEs by a server.
I'm pointing out that name-mangled DS records need not invoke additional
section processing--all the knowledge of this could be done in the
resolver.  But maybe I'm just not understanding your comment.

Matt

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Nov 2002 19:51:18 -0500

>for a zone hosting DS records, again in light of the issues you pointed

A BIND 9.2 caching server might be in use on a proxy firewall.  If a 
BIND 9.3 resolver asks it for the DS set, the 9.2 can be forced to 
"misbehave."

>I still think the need for a DS-aware flag is obviated by the flag day.

Hmmm, has anyone ever defined what is meant by a "flag day?"  It's 
not like the old days when we switched all of our routers from all 
0's broadcast to all 1's broadcast.

>resolver.  But maybe I'm just not understanding your comment.

If you are relying on using a query to a second name to get the 
additional data, you will incur more round trips (times) to get the 
answer.  Not much detail in this answer.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer