<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 23, 2014 at 10:25 AM, Paul Hoffman <span dir="ltr"><<a href="mailto:paul.hoffman@vpnc.org" target="_blank">paul.hoffman@vpnc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Speaking as someone who supports all end systems to be their own validating recursive resolver.<br></blockquote><div><br></div><div>I used to think that, but writing a paper for the middlebox workshop has forced be to radically change my thinking. I have just converted it to a draft and uploaded it. </div><div><br></div><div><a href="https://tools.ietf.org/id/draft-hallambaker-presentation-00">https://tools.ietf.org/id/draft-hallambaker-presentation-00</a><br></div><div><br></div><div><br></div><div>Some highlights:</div><div><br></div><div>* The architectural model of the Internet should be described by the interfaces between layers, not the descriptions of the layers. How a layer is implemented can change (multipath TLS, DTN, etc). How it interfaces to other layers changes over time</div><div><br></div><div>* Each interface is characterized by the identifiers that are used. Applications connect  by DNS names, port numbers and SRV prefixes. The Network/Transport layer exposes IP headers. the Transport layer exposes IP addresses and ports.</div><div><br></div><div>* From the above it follows that there is a layer missing from the model because applications aren't talking the same language as transport. The name Presentation is already established but it is not a presentation layer in the OSI sense.</div><div><br></div><div>* Using DNS to distribute keys has totally different security considerations to distribution of IP addresses.</div><div><br></div><div><br></div><div>The last is important because there is very good case to be made for DNSSEC validating DANE records at the end system client. It is actually better to validate DNSSEC in the resolver.</div><div><br></div><div>Right now I do not see any transition plan from IPv4 to IPv6. We have plenty of plans that let us use IPv6 only but as yet no plan that lets us put a pure IPv6 device on a mixed network and achieve 100% connectivity with legacy IPv4 hosts. Such a device would never make A record queries. It would only make AAAA queries.</div><div><br></div><div>But give me a trusted path to an IPv6 resolver that I can trust to rewrite DNS records so that my requests for hosts with only IPv4 connectivity are rewritten to give me the address of a suitable gateway for that particular AS.</div><div><br></div><div>With only a small amount of cleverness, we can make such a gateway stateless. And that in turn means that providing internal network gateways can become a base feature of ethernet switches.</div><div><br></div><div><br></div><div>The only thing that breaks is the DNSSEC signature on the AAAA record. And that should not matter because an Internet application only cares about domain names, the address should not be visible. </div><div><br></div><div>DANE has confused the issue because DANE is supporting the application/presentation interface and the rest of DNS is supporting the presentation/transport layer. DANE keys are an application concern and it makes perfect sense to check DANE records at the application just as the application checks WebPKI certificates. But having application code check signatures on A and AAAA records makes no more sense than checking signatures on BGP route advertisements there.</div><div><br></div><div><br></div><div>The OSI layer model is a failure when it comes to describing most of the new innovations taking place in IETF. But when we invert the model and look at the interfaces rather than the layers, the architecture that has emerged over the past 20 years fits very cleanly.</div><div><br></div><div>Resolvers are of course a form of middlebox. They don't get counted as such because middleboxes are 'evil' and resolvers are 'necessary'. But they sit between the endpoint and the net, their logical function is middlebox-like and thus their form is a middlebox.</div></div></div></div>