Re: [DNSOP] Review of draft-livingood-dns-redirect-00

[Dave CROCKER <[e-mail]>]

Jason, et al,

This note suggests changes in both style and detail in
draft-livingood-dns-redirect-00.  All of the points made here have been made or
suggested by others in this thread; my intent is to underscore and elaborate on
those points, rather than to challenge development and publication of the draft.
  I’ve seen enough postings to convince me that there actual is existing practice
with significant deployment. The goal of the draft is to document that behavior.
  Debating whether the mechanism is ever reasonable or appropriate to deploy –
and what alternatives might be more reasonable and appropriate might be
productive, but not as part of the current exercise.  The current exercise is
one of technical specification.

Given the coincidental timing, however, it’s worth citing a paper being
presented at the CEAS conference today:

    Anti-Phishing Landing Page: Turning a 404 into a
    Teachable Moment for End Users

    <http://ceas.cc/papers-2009/ceas2009-paper-37.pdf>


A few specific points:

As with others, I think the draft needs to remove its promotional, persuasive or
legalistic vocabulary.  It’s a technical document, attempting to specify
existing practice. So it should focus on technical details and operational
trade-offs, without trying to sell the reader or protect against lawsuits.  When
the document recommends a particular choice, it should simply use RFC 2119
vocabulary.  To the extent that there are tradeoffs, simply state what they are
and which one(s) the document prefers (and possibly in what context.)  That is,
what technical or operational characteristics provide the basis for a particular
recommendation?

The long thread of discussion on the dnsop list has cited a  number of
alternative mechanisms for accomplishing the same, or similar, goals as the one
described in the draft.  To properly establish the context for use of this
particular mechanism, the draft should diligently include all of these in its
discussion of background, choices and tradeoffs.  Not to debate the
alternatives, and not to provide an extensive tutorial, but to explain the
pragmatic reasons that the mechanism being specified is (regularly?) chosen in
preference to those alternatives.

The thread discussion has also produced references to a small, but very
interesting, set of RFCs. These documents provide a rich background of relevant
material; so the draft should carefully include each of these citations and
discuss them in terms of the draft.  Besides being basic due diligence, such a
discussion might mitigate some people’s concerns about the mechanism specified
in the draft.

The draft’s discussion about the presence of DNSSec contains a nice case
analysis of various configurations and scenarios, explaining how the mechanism
works within each scenario.  However it is easy to miss a key fact that the
draft should provide in a simple, summary statement:  When DNSSec validation is
performed by the user’s resolver, this mechanism will fail. While the user will
be denied access to the potentially problematic address, they will not not land
at the alternative address.  That is, this mechanism has long-term viability
only when a user’s resolver does not implement DNSSec and, instead, relies on
their operational infrastructure to validate DNS data.

The draft specifies a mechanism that appears to work properly only for a single
application service, namely the Web. Yet it characterizes all other services as
exceptions.  Instead, the draft should cast the mechanism as intended only for a
single application and should provide substantive discussion about either how
other services will continue to operate or why disrupting them is acceptable.
This discussion is really the basis for understanding when the mechanism can be
practical to deploy and when it cannot.


A deeper issue:

The draft demonstrates some confusion about the architectural role of the
service it is specifyhing.  Various postings on the mailing list discussion have
offered a variety of alternative labels to refer to the mechanism; this serves
to highlight the potential for misunderstanding what the specified service
really is and when it is really reasonable to use.  This could be caused by a
pervasive confusion about the model for DNS service that this draft is affecting.

A cliché in the technical community is that the only lesson of the Internet is
scaling.  While scaling to the level of a global Internet does teach quite a
lot, its lesson does not seem to be as challenging as that of mediation.
Networking is about mediated exchange.  At every level, and for nearly all
services, mediation mechanisms come into play: Between two principals, there are
typically agents in the path, providing assistance. Some assistance is simply
routing and forwarding.  Other assistance plays with the payload.  Assistance
can be supplied by an agent of one of the principals – that is, at one end of
the path –  or by an independent operator along the path.  These are important
differences.

IP routers and email relays, for example, route and forward an object (and its
header) without modifying either.  NATs, v4/v6 gateways and email gateways dive
into the object (and its header) and make substantive – semantic – changes.
Changing the endpoint identifier – that is, specification of the target address
– is a major change, every bit as much as changing the “content”. The draft
specifies a mechanism that does both.

DNS vocabulary uses the word “resolver” to refer to one of the end-points and
potentially one or more of the mediators in an exchange.  This can be confusing.
Equally, the term “redirect” is historically used to refer to a response by a
principal, to specify an alternative address for the desired information. In
contrast, in the draft, the term is used by 1) an intermediary,  2) to change
the underlying nature of the provided information.  As such, the mechanism is
not a “resolver”.  It is something else.

In other words, the nature and details of the specified mechanism are quite
different than what its terminology is typically used for.  So I suggest
changing the vocabulary and discussion, to avoid the confusion. Getting a usable
term that is both noticeably different from “resolver” and meaningfully
descriptive appears to be a challenge.  “Intercept” is tantalizing but
semantically inaccurate.  “Proxy” might be the best compromise term, since other
proxies tend to do translations, too.  Personally, I’d wish for a word that is a
little more striking, since the function is striking, but “proxy” is the best
I’ve been able to come up with.

What is essential is to make sure that the label does not permit one to think
that this module is anything like a normal resolver.

As with others, I suspect it is important to have the document more strongly
distinguish between modified behaviors that occur because a government requires
it, versus those triggered by some sort of blocklist, versus a simple NXDomain
response.  While the draft already cites these distinctions, I suspect there are
design and/or operational differences for the different cases.  At the least,
the potential for differential handling should be discussed.  If they all result
in the same processing, that should be explained.

Most importantly, the specification needs to characterize the environments in
which it can be successfully deployed, versus others whereas it cannot.  My
current understanding is that the mechanism can work acceptably only in walled
gardens (edge networks), where the operator has defined a substantially
constrained user environment.  In such places, email and other services are
highly mediated by the operator.  So the describee mechanism does not get in
their way. Being clear about the pragmatic constraints that are required appears
to be an interesting challenge for the paper.


d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net