Subject: Re: Clear path requirement

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.

--
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: Paul Vixie <[email-masked]>
Date: Thu, 21 Nov 2002 05:35:00 +0000

> > >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".  ...

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.