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: 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: Sam Weiler <[email-masked]>
Date: Wed, 20 Nov 2002 20:21:02 -0500 (EST)

On Wed, 20 Nov 2002, Edward Lewis wrote:
>
> >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?"

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