Subject: Clear path requirement

From: Sam Weiler <[email-masked]>
Date: Tue, 19 Nov 2002 15:16:04 -0500 (EST)

Over the past several months we've seen several problems that stem
from legacy resolvers thinking that children, not parents, are
authoritative for DS.  In particular, having non-DS-aware
resolvers/caches/proxies in the path from querier to authoritative
server can block DS records entirely, even if those boxes otherwise
handle unknown RR types.  Further details are being discussed on
[email-masked].

So here are the questions: is it reasonable to mandate a "clear path"
between resolver and authoritative server, meaning a path with only
DS-aware (not just 2535-aware) resolvers/caches/proxies?  Is it
acceptable to have DNSSEC RRs dropped until everything along the path
is upgraded, or is that a deployment showstopper?  Or do so few of
these boxes pass unknown RR types that this is nothing new -- we're
already stuck with upgrading everything just to get KEY/SIG/NXT?

I think a clear path requirement is too onerous and will slow
deployment.  In particular, while a zone that wants to be signed can
probably remove any legacy caches that sit in front of its
authoritative servers, users wishing to validate results may not be
able to remove or upgrade the (often embedded) hardware at their ISP
(or hotel).  Assuming that there are enough of these boxes that handle
unknown RR types but don't understand DS, I think we should try to
make the protocol work through them.  The exact technical solution can
be debated -- I'd like to see if we can get rough consensus on the
need to avoid a clear path requirement.

-- Sam

--
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: Ted Lemon <[email-masked]>
Date: Tue, 19 Nov 2002 16:54:52 -0500

I think it's reasonable to require that there be no DS-unaware 
resolvers in the path to a secure zone.   The reason is that in 
general, one can almost always bypass broken resolvers in embedded 
devices - for example, I never use the resolver in my airport base 
station, even though in terms of topology it is between me and the 
outside world.

My experience as a frequent roamer is that outside of corporate 
networks, it is rarely the case that anyone prevents you from bypassing 
a resolver.   Inside of corporate networks, arguing that the resolver 
is causing a security problem can, over time, result in the problem 
being fixed.   Because early adopters tend to be highly motivated, I 
think that this requirement will have a good effect.

BTW, I do not intend to strongly advocate this position - I am just 
interjecting with some personal experience and the possibly incorrect 
conclusion I draw from it.   Your milage may vary.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 19 Nov 2002 21:52:50 +0000

quite a lot of the ipv4 edge consists of gateway boxes (nat, etc) which
were poorly programmed, have unspecified features, and whose manufacturers
are out of business.  if we decide on a dnssec design which requires that
these devices be replaced/upgraded before dnssec will work "at these edges"
then we won't see deployment at badly served edges until some later time
when dnssec functionality becomes compelling (i don't know what that will
look like but whatever it is, i don't expect it to occur soon.)

the boxes in question often rewrite dns messages as they pass through, and
their weaknesses give rise to a strong defense of the "end to end" argument
and may even form some motivation for ipv6 deployment in the hope that ipv6
firewalls will somehow be smarter than ipv4 firewalls were, since NAT won't
be a consideration.

my take on this: a clear-path requirement would slow dnssec deployment,
if dnssec deployment otherwise became possible.

---

From: Derek Atkins <[email-masked]>
Date: 19 Nov 2002 17:09:54 -0500

Ted Lemon <[email-masked]> writes:

> networks, it is rarely the case that anyone prevents you from
> bypassing a resolver.   Inside of corporate networks, arguing that the
> resolver is causing a security problem can, over time, result in the
> problem being fixed.   Because early adopters tend to be highly
> motivated, I think that this requirement will have a good effect.

Interesting -- I've been stuck behind "transparent" proxy caches
that intercept DNS messages, even when the dest IP is a server I
know.  Indeed, the service in the hotel rooms here at the IETF
have this "feature"...

> conclusion I draw from it.   Your milage may vary.

I also believe that requiring all these edge devices to be upgraded in
order to get DNSSec to work will be a major impediment to deployment.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Nov 2002 18:01:22 -0500

> know.  Indeed, the service in the hotel rooms here at the IETF

Yes, indeed, this is the one exception of which I am aware, and I have 
also run into it at other hotels.   I am glad that the fact that I use 
DNS correctly means that I can't get through this box - I find it 
alarming that a device such as this might silently corrupt my network 
transactions. Anything that can be done to make it so that Joe Average 
simply loses when trying to connect through such boxes is a good thing. 
  It gives the service provider a financial incentive to fix the problem 
- it means they have to pay for backcharges, reduces their income, and 
runs up the phone bill on their 800-number.   It is not in Joe 
Average's interest to connect through a device that arbitrarily 
modifies the contents of DNS packets - no good can come of it.

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 19 Nov 2002 22:54:33 -0500 (EST)

> know.  Indeed, the service in the hotel rooms here at the IETF

the "transparent" proxy caches play well with other DNSSEC RR types such
as SIG, KEY and NXT ? what about support for EDNS0 ?

	jakob

---

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

---

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

---

From: Sam Weiler <[email-masked]>
Date: Wed, 20 Nov 2002 20:21:02 -0500 (EST)

On Wed, 20 Nov 2002, Edward Lewis wrote:
> Hmmm, has anyone ever defined what is meant by a "flag day?"

I presumed it meant "anyone signing with 2535 will potentially see
things break and they will stop signing with 2535 if that's necessary
to keep other things from breaking".  Or "we can deprecate any and all
code that deals with 2535-signed zones".  We can't assume all
2535-aware resolvers will go away, just like we can't assume that all
older resolvers will go away.  At the time, I don't think we
recognized how interesting the legacy resolver interactions would be.

-- Sam

---

From: Paul Vixie <[email-masked]>
Date: Thu, 21 Nov 2002 05:35:00 +0000

> to keep other things from breaking".  ...

i'm the one who keeps bringing it up so i'll say what i've been meaning
by the term "flag day."  a flag day is when everyone who wants to continue
to have functionality of some type has to upgrade.  ncp->tcp was a flag
day.  sure, there were islands of ncp after the flag day, but none today.

when you make an incompatible change to the on-the-wire format of a
protocol, you invalidate a set of older clients.  by "incompatible" i
don't mean breaking older implementations of a looser spec, nor anything
for which being liberal in what you accept is an antidote.  i mean "the
people who had this functionality before the date, will have to change
their software or configuration in order to ever have it again after the
date."

in dnssec terms, we have at least one flag day coming, due to DS or whatever
we use instead of DS if we can't make DS work.  the thing we don't know yet
is whether that will be our last flag day.  why not?  because we are still
doing basic research on what kind of data model will work for dns security.
after three or four times of saying "NOW we've got it, THIS TIME for sure"
there's finally some humility in the picture... "wonder if THIS'll work?"

for comparison purposes, it's hard (bordering on beyond impossible) to
imagine declaring another flag day for IPv6, such that all pre-flagday
implementations would become obsolete and incompatible until upgraded.

whereas, for DNSSEC, the opposite is far from false: it's impossible to
know how many more flag days we'll have before it's safe to burn ROMs
that marshall and unmarshall the DNSSEC related RR's, or follow chains
trying to validate signatures.  it sure isn't plain old SIG+KEY, and
it sure isn't DS as currently specified.  when will it be?  we don't know.
what has to happen before we will know?  we don't know that either.

right now i'm ready to treat "that was our last flag day" as a victory,
even if the specs and tools are a little rough on that particular day.
i'm interested in seeing a clear list of things that have to happen before
we will know what has to happen before our final DNSSEC flag day.

2535 is already dead and buried.  there is no installed base.  we're
starting from scratch.  that's both a boon and a curse.