Great feedback, Dave. Thank you and we¹ll take it into account as we work on a revision.
Jason On 7/17/09 1:02 PM, "Dave CROCKER" <d...@dcrocker.net> wrote: > > > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
