idnits 2.17.1 draft-hallambaker-presentation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2014) is 3467 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.hallambaker-privatedns' is defined on line 1145, but no explicit reference was found in the text == Unused Reference: 'I-D.hallambaker-wsconnect' is defined on line 1149, but no explicit reference was found in the text == Unused Reference: 'I-D.hallambaker-omnibroker' is defined on line 1153, but no explicit reference was found in the text == Unused Reference: 'I-D.hallambaker-omnipublish' is defined on line 1157, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-hallambaker-privatedns-00 == Outdated reference: A later version (-08) exists of draft-hallambaker-wsconnect-05 == Outdated reference: A later version (-08) exists of draft-hallambaker-omnibroker-07 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force (IETF) Phillip Hallam-Baker 2 Internet-Draft Comodo Group Inc. 3 Intended Status: Standards Track October 23, 2014 4 Expires: April 26, 2015 6 An Internet Presentation Level 7 draft-hallambaker-presentation-00 9 Abstract 11 Paper submitted to the IAB Middlebox workshop describing an Internet 12 architectural model. 14 Status of This Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 Copyright Notice 31 Copyright (c) 2014 IETF Trust and the persons identified as the 32 document authors. All rights reserved. 34 This document is subject to BCP 78 and the IETF Trust's Legal 35 Provisions Relating to IETF Documents 36 (http://trustee.ietf.org/license-info) in effect on the date of 37 publication of this document. Please review these documents 38 carefully, as they describe your rights and restrictions with respect 39 to this document. Code Components extracted from this document must 40 include Simplified BSD License text as described in Section 4.e of 41 the Trust Legal Provisions and are provided without warranty as 42 described in the Simplified BSD License. 44 Table of Contents 46 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Success has Consequences . . . . . . . . . . . . . . . . . . . 4 48 2.1. Middleboxes Emerge as Symptom, not Cause . . . . . . . . 6 49 2.2. The Deployment Challenge . . . . . . . . . . . . . . . . 7 50 2.3. Need for a Consistent Discovery Architecture . . . . . . 8 51 2.4. Limitations of the DNS Infrastructure . . . . . . . . . 9 52 2.5. Non DNS Discovery Infrastructure . . . . . . . . . . . . 10 53 2.6. Not Yet Existing Infrastructure . . . . . . . . . . . . 11 54 2.7. The Administration Gap . . . . . . . . . . . . . . . . . 11 55 3. An Internet Presentation Level . . . . . . . . . . . . . . . 12 56 3.1. Authoritative Infrastructures and Ground Truth . . . . . 14 57 3.2. Anti-Abuse Filtering . . . . . . . . . . . . . . . . . . 15 58 3.3. IPv6 Transition . . . . . . . . . . . . . . . . . . . . 15 59 3.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 16 60 3.5. Naming Architecture . . . . . . . . . . . . . . . . . . 16 61 3.5.1. Account Names . . . . . . . . . . . . . . . . . . . 17 62 3.5.2. Strong Names . . . . . . . . . . . . . . . . . . . 18 63 3.6. Discovery Services . . . . . . . . . . . . . . . . . . . 19 64 3.6.1. Consistent Discovery API . . . . . . . . . . . . . 19 65 4. Implementation . . . . . . . . . . . . . . . . . . . . . . . 20 66 4.1. Connection Broker . . . . . . . . . . . . . . . . . . . 20 67 4.2. Private DNS - Eliminating Legacy DNS restrictions . . . 21 68 4.3. OmniQuery - A Presentation Level Discovery Service . . . 22 69 4.4. OmniPublish - A Presentation Level Provisioning Service 23 70 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 24 73 6.2. Informative References . . . . . . . . . . . . . . . . . 24 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 76 1. Overview 78 IETF process traditionally favors incremental change over radical 79 change. But this approach fails when the problem to be solved is 80 itself caused by divergent incremental change. Every one of the 81 problems described in this document has been solved and not once but 82 multiple times. And it is the proliferation and inconsistency of 83 those solutions that is now the problem. 85 This first section of this paper surveys the key problems arising 86 from the current Internet discovery architecture and the constraints 87 within which any proposed solution must work. It is the view of the 88 author that the proliferation of middleboxes is a symptom rather than 89 the cause of these problems. Middleboxes do however represent a 90 constraint which any solution must work within. 92 The second section argues that the areas in which the original 93 Internet architecture now falls short do not properly belong 94 exclusively to either the transport layer or the application layer. 95 The need for middle boxes arises because the Internet model lacks a 96 level of abstraction between the transport and application layers. 97 The term 'Presentation Level' is used as a term for this new 98 interface as the term 'Presentation Layer' is firmly established as 99 the term of art for what lies between OSI layers 5 and 7. 101 While the idea that the DNS represents an Internet presentation layer 102 has been advanced on previous occasions, this paper takes the concept 103 further using the term presentation level to include host and service 104 discovery, account presence protocols, Kerberos like key services and 105 PKI. 107 The final section describes a realization the architecture described 108 in the previous section through a compact set of simple Web Services 109 that are individually of limited scope. Each of these proposals has 110 been tested in an open source implementation and has been described 111 previously a separate draft. These are: 113 * Omni-Query [!I-D.hallambaker-omnibroker] 115 * Omni-Publish [!I-D.hallambaker-omnipublish] 117 * Private-DNS [!I-D.hallambaker-privatedns] 119 * SXS-Connect [!I-D.hallambaker-wsconnect] 121 Each of the first three proposals has its own independent value 122 proposition that makes it a candidate for deployment even if neither 123 of the other two ever advances. The last provides common 124 infrastructure that supports the first three. 126 2. Success has Consequences 128 While the IAB call for papers suggests that the need for change 129 arises from the deployment of middleboxes in the otherwise perfect 130 Internet architecture, it is the opinion of the author that 131 middleboxes are just one of the symptoms of the failure of the 132 Internet architecture to keep pace with Internet growth. 134 The fact that the Internet architecture has survived with little 135 major modification in the quarter century since deployment of DNS is 136 testament to both the foresight of the original architects and the 137 immense difficulty of making changes to an infrastructure on which 138 over two billion people and the majority of global commerce depend. 139 Denying outright the possibility that the Internet architecture model 140 devised in the 1980s might fall short of current needs is the mindset 141 that ossified the telephone network. The Internet was developed by 142 people who had the skill and the vision to question the status quo. 144 At the time the foundation of the Internet was laid, computers were 145 expensive and typically singular. The conception of the Inter-network 146 as a network of networks was radical at a time when computer 147 networking at most University campuses referred to the means by which 148 dumb terminals connected to the central mainframe. 150 The modern Internet is a very different place. [RFC0801] describing 151 the plan for the 'flag day' transition to TCP gives the number of NTP 152 hosts in January 1982 as 200. This is roughly the number of networked 153 devices I currently have in my house. And while my present 154 residential computing configuration is an outlier today, such 155 configurations will become typical in only a few years time. 157 The modern Internet connects between two and twenty billion hosts, 158 the difference reflecting the difficulty of agreeing a definition of 159 a host as much as uncertainty in the count. What is a host? A CPU? A 160 CPU core? A virtual machine running on a CPU? But regardless of 161 whether the Internet has grown by seven or eight orders of magnitude, 162 the notion that every aspect the original architecture should be 163 maintained unchanged is ideology, not respect. 165 Further, current estimates suggest that the global population will 166 ultimately peak at between 8 and 10 billion. Extrapolating from 167 current trends we should expect that every household item that 168 currently uses electricity will eventually connect to the network. We 169 should therefore adopt as a planning estimate that the Internet will 170 eventually expand to at least ten trillion connected devices. 172 One architectural consequence of the growth of the Internet is that 173 the Internet is no longer a network of hosts, it is a network of 174 services. The so-called cloud is after all merely a name we give to 175 the place Internet services reside because we no longer consider 176 their physical location to be important. The core principle that 177 underpins the cloud is that it is whether a function can be trusted 178 that is important, not where it takes place. So why get excited over 179 whether functions happen in a middle box or an end point if place 180 does not matter? 182 Another significant architectural consequence is that the Internet is 183 no longer a network of networks. It is a network of networks of 184 networks and it is possible there are further levels of recursion. 185 Middlebox appliances owe their existence in part to the fact that the 186 interests of the user are not always the same as the interests of the 187 local area network manager and their interests may in turn diverge 188 from those of the Internet access provider whose interests are almost 189 certainly divergent from their carrier. 191 Yet another difference resulting from scale is the need for security. 192 When the Internet was a purely academic infrastructure and the users 193 were members of academic institutions, there were few assets worth 194 attacking and abuse was effectively controlled by an accountability 195 model. As a result, the Internet culture many of us grew up with is 196 profoundly maladapted to life in an Internet of 2 billion users. Even 197 if only 1% of them were malicious (the usual expectation for a 198 population is 10%) that would be 20 million malicious actors. 200 In particular we need to recognize that while everyone has the right 201 to connect to the Internet, there is not a general right to connect 202 to my part of it. In particular: 204 * The fact that it is possible to initiate an SMTP session with a 205 mail server does not entail a guarantee that the server will 206 accept an email for delivery 208 * The fact that an email is delivered does not mean it must be 209 read 211 * The fact that a DNS name is registered with ICANN by a 212 notorious Internet crime ring does not mean that my local DNS 213 service must resolve it 215 * The fact that an IP address is assigned does not mean that I 216 must allow my hosts or services to connect to it. 218 The received Internet security model is profoundly maladapted through 219 the insistence of a single failure security model. This leads to the 220 two arguments that are invariably made against any proposal for a new 221 security control, that the new control is 'unnecessary' because 222 another existing control is sufficient or that it will be ineffective 223 because it does not cover every conceivable corner case. 225 An architecture that allows a breach to occur as a result of the 226 failure of a single system is a bad architecture. Thus arguments of 227 the form 'we don't need firewalls because systems should not be 228 vulnerable to malware' are profoundly wrong because they assert that 229 if the breach could have been prevented by control X then it is 230 somehow bad architecture to insist on also deploying control Y. The 231 correct security approach is to deploy both controls X and Y and a 232 further infrastructure Z to provide feedback by reporting on breaches 233 that should have been caught by one control but were not. 235 The biggest and most concerning consequence of Internet growth is the 236 difficulty of changing the Internet infrastructures. IPv6, IPSEC and 237 DNSSEC were all proposed over two decades ago. All were intended to 238 become ubiquitous within a few years, no more than five at most. None 239 has succeeded in becoming ubiquitous, not is there any reason to 240 expect this to change until the reasons for the lack of deployment 241 are addressed. 243 2.1. Middleboxes Emerge as Symptom, not Cause 245 The term middlebox is a generic term for any network infrastructure 246 that breaks the pure end-to-end IP architecture. As such they have 247 been generally regarded as the result of ignorance or malice rather 248 than a response to real world requirements. Only rarely has the 249 question been asked if the end-to-end principle might not be 250 universal in scope. 252 As previously mentioned, I have 200 network enabled devices in my 253 residence. Ideally these devices would all be IP enabled devices but 254 many of them are currently not IP enabled precisely because while it 255 makes perfect sense to have a light switch to communicate using IP 256 protocol it does not make sense for a lightswitch to be running an 257 email server. 259 The principle of least privilege should be given at least equal 260 respect as the end-to-end principle. And the least privilege 261 principle states that my light switch does not need to be able to 262 send email. Nor does my light switch need to be able to perform any 263 form of communication that is not essential to its purpose. 265 Set out in these terms, the role and justification for Internet 266 firewalls becomes obvious. As does the fact that firewalls are 267 woefully inadequate for their intended purpose. While my firewalls 268 could in theory prevent an attacker outside my network mounting an 269 attack on my toaster oven, if the toaster oven is compromised, they 270 cannot stop it conspiring with the refrigerator. And that is a 271 serious concern. 273 The real problem with firewalls is not that they do not have a useful 274 purpose but that they are unable to fulfill the purposes they are 275 designed for. The main consequence of Internet firewall port blocking 276 is that all new Internet services are layered on port 80 and port 443 277 rather than protocol specific ports, precisely to avoid 'problems 278 caused by' middleboxes. 280 A realistic Internet architecture should respect the fact that the 281 Internet is a network of networks and a network has a natural and 282 legitimate interest in patrolling its border. The network perimeter 283 is after all the point where responsibility for packets being emitted 284 passes from one party to another. For the same reason, perimeter 285 security will always have an important place in any serious security 286 architecture. But that does not mean it should be the only place 287 where filtering should occur. 289 In a default deny network, no network communication should take place 290 that is not expressly permitted by network security policy. The 291 network communications that are permitted for a light switch would 292 not normally be as broad as those permitted to a desktop computer. 294 The idea that the local network is separate from the larger Internet 295 is not new. It is in fact the origin of the Inter-Network itself. My 296 private machines and my private network are my private domain. While 297 the impact of cloud computing means that the precise physical 298 boundaries are no longer clear, the Domain Name System provides the 299 infrastructure that denotes the logical boundaries between domains. 301 2.2. The Deployment Challenge 303 Changing an infrastructure with ten billion moving parts is 304 inevitably difficult and slow. But one aspect that makes the Internet 305 particularly difficult to change is the rigidity of the Internet 306 application interface. 308 When the Internet was first developed it was only one of many 309 networking standards and so there was no 'Internet' API, there was a 310 network API which supported the Internet as one option. A client 311 application using one of the standard network stacks of the day, 312 would connect to an Internet host by means of gethostbyname() system 313 call to obtain the network address(es) of the host to connect to and 314 then perform whatever platform specific call is required to establish 315 a socket (or mailbox) to connect to the specified address. 317 A quarter century later, the application interface is essentially 318 unchanged. The only difference being that on some object oriented 319 platforms a socket is now known as a 'stream'. Meanwhile a large 320 number of changes have taken place in the Internet infrastructure and 321 the way it is used: 323 * The hosts.txt file was replaced by the DNS 325 * DNS names are typically names of services as opposed to hosts 326 and clients typically are attempting to connect to services. 328 * There is no standard approach to support establishment of peer 329 to peer connections. 331 * DNS has been extended to support records that advertise 332 services but these records are not visible to application 333 clients unless they make use of their own DNS libraries. 334 Further the decision to make use of SRV or NAPTR records is 335 left to the application protocol designer. 337 * DNS has been extended to support authentication of 338 authoritative DNS Resource Records but this information is not 339 typically available to the application programmer. 341 * Many applications make use of TLS over TCP transport in place 342 of TCP but it is left to the application protocol designer and 343 implementer to manage this and make security sensitive 344 decisions on the user's behalf by deciding the PKI 345 configuration to use. 347 * IPSEC transport may be available but there is no infrastructure 348 for delivery of keys. 350 * Even though IP is designed to support many end-to-end 351 protocols, the only protocols for which platform support is 352 ubiquitously available are TCP and UDP. 354 * Middleboxes of various types intercept and frequently transform 355 IP and DNS communications for purposes that are rarely 356 documented and frequently irrational. 358 * Many network applications, in particular, all successful peer- 359 to-peer applications employ a variety of techniques to 360 circumvent the limitations imposed by middleboxes. 362 One of the problems that has prevented progress in this area is that 363 the Application programmers desire for a new API that allows them the 364 advantages of the modern Internet is frequently mistaken for a desire 365 for an API that exposes more of the underlying complexity of the 366 Internet and DNS. 368 2.3. Need for a Consistent Discovery Architecture 370 What many of these defects have in common is that the Internet lacks 371 a standard architecture for discovery and negotiation of Internet 372 connections. While this problem has been solved on many occasions in 373 many different ways there is no single coherent solution to the 374 connection discovery problem. 376 The mechanism used for host discovery was not a choice for 377 application protocol designers in the days of RFC802. The mechanism 378 used for establishment of peer to peer or service connections should 379 not be a choice for application protocol designers today. The IETF 380 should have one mechanism that is consistently implemented and 381 applied. And this mechanism should provide for all the needs of the 382 modern Internet and anticipate future needs: 384 * Internet Protocol version, address and port number. 386 * Choice of transport protocol: e.g. TCP, UDP, Multicast or new 387 transports to be developed 389 * Choice of security enhancement: e.g. None, TLS, DTLS or new 390 transport to be developed. 392 * Authentication credentials to be verified 394 * Authentication credentials to be supplied 396 It is a truth universally acknowledged that gethostbyname is not a 397 suitable application layer interface to the DNS. But the truth that 398 is rather too frequently ignored is that application programmers 399 really don't want to have to deal with anything more complex. While 400 new APIs that expose the internals of DNS and PKI and directory 401 infrastructures are highly desirable in their own right, these are 402 not and should not be considered tools for use by the application 403 protocol designer or implementer. 405 Application protocol designers are very fond of explaining that the 406 discovery process is not a one-size-fits-all proposition, that there 407 are subtleties and complications that mean that it is not possible 408 for one particular discovery approach to meet every need. And these 409 reasons are sound and correct and are also the reason why such 410 decisions should not be taken by the application protocol designer at 411 all. Such considerations are properly the concern of the network 412 administrators and user and should be presented in a fashion that 413 puts those parties in direct control. 415 2.4. Limitations of the DNS Infrastructure 417 Another common source of deficiency are the limitations of the DNS 418 protocol and the DNS infrastructure. While the two are frequently 419 considered to be equivalent they are in fact very different. It being 420 far easier to change the former than the latter. Adding a Resource 421 Record type to DNS requires no more than publication of an RFC. 422 Changing the DNS infrastructure is much more challenging. 424 The DNS was originally designed as a mechanism to replace the 425 hosts.txt file mapping Internet host names to addresses and early use 426 was largely limited to this requirement. By the time more advanced 427 uses came to be considered the vast majority of the deployed DNS 428 infrastructure imposed a 500 byte message limit on DNS messages and 429 each request packet could only specify one domain and one record type 430 at a time. 432 Although the DNS protocol has been updated to remove the 500 byte 433 limit and every major DNS server implementation updated a decade or 434 more ago, many deployed residential network gateway boxes truncate 435 messages to conform to the long obsolete requirement. Another rather 436 more insidious limitation is that some middle boxes and platforms 437 impose tight limits on the number of outstanding DNS requests that 438 have not received responses. 440 While residential customers of an ISP can usually (but by no means 441 always) overcome such limitations by providing their own network 442 gateway box, this is by no means the only middle box attack performed 443 on DNS. Whoever controls the DNS controls the Internet, a fact not 444 lost on most ISPs. 446 It is now routine for DNS resolution services provided by ISPs to 447 return a redirect to a Web site with an advertising page rather than 448 the NXDOMAIN response code that should be returned when a domain name 449 is not found. Some ISPs hijack NXDOMAIN responses from third party 450 open resolvers to ensure that customers cannot avoid their unwanted 451 intrusions. 453 DNS is a trusted infrastructure but the mechanism by which clients 454 discover DNS resolvers is inherently untrustworthy. Internet clients 455 depend on the DNS resolver returning trustworthy information. It is 456 utterly ludicrous and unacceptable that the default DNS service be 457 chosen by network proximity without regard for trustworthiness. 459 DNSSEC can alert the user to the fact that perfidy has occurred but 460 does not provide a means of obtaining the correct, unadulterated 461 result. While government agencies in most liberal democracies are 462 anxious to conceal the fact that they are censoring and/or 463 intercepting network traffic, this constraint does not apply to 464 authoritarian regimes where the purpose of these practices is to 465 deter rather than prevent expression of dissent. And there is no 466 reason to believe that ISPs that have already decided that replacing 467 NXDOMAIN responses from external DNS services that compromise their 468 commercial interests will not attempt to strip out DNSSEC data if 469 they choose. 471 2.5. Non DNS Discovery Infrastructure 473 The DNS is the discovery infrastructure of the Internet and the 474 authoritative infrastructure that maps Internet domain names to 475 assertions about those names. It is not however the only 476 infrastructure that applications make use of during service discovery 477 and connection establishment. Nor should it be. 479 Modern email infrastructures make extensive use of various types of 480 blocklist. Although these blocklists are frequently distributed using 481 DNS protocol they are by no means authoritative DNS responses. On the 482 contrary, the value of these assertions lies in the very fact that 483 they are provided by a third party and not the holder of the IP 484 address. 486 Email was the first Internet infrastructure to make use of account 487 identifiers of the form @. Such identifiers are now 488 used in a wide range of peer to service and peer to peer applications 489 including authentication, instant messaging, voice and video. 491 Despite the ubiquity of such applications, no consistent presence 492 infrastructure has emerged. Depending on the application designer's 493 whim, names may be resolved by means of a variety of presence 494 services including LDAP, OpenID, SAML, WebFinger or XMPP and while 495 the DNS infrastructure is sometimes used as the means of resolving 496 the component of the account identifier, this rather obvious 497 approach is by no means universal or even the most common. 499 On many occasions, researchers have attempted to employ the DNS 500 infrastructure itself as a presence infrastructure. There are 501 structural factors that make this approach unlikely to succeed. In 502 most medium or larger enterprises the DNS infrastructure is managed 503 by a network administration team which is quite separate from the 504 system administrators and IT support staff who issue user accounts. 505 At any rate the fact that despite repeated attempts over the course 506 of three decades, such approaches have invariably remained 'research' 507 suggests that the approach is not ideal. 509 2.6. Not Yet Existing Infrastructure 511 The most important gap in the Internet discovery architecture is the 512 lack of a coherent security policy infrastructure to tell 513 applications which security enhancements are supported by an Internet 514 service and what credentials will be supplied. The lack of such 515 infrastructure is the reason that twenty years after the deployment 516 of practical PKI, security remains the exception on the Internet 517 rather than the norm. 519 This shortcoming has of course been recognized in recent work and 520 proposals such as certificate pinning and 'strict security' provide 521 valuable benefits. But the approach in such proposals is necessarily 522 tactical rather than strategic, designed to provide the best security 523 in the difficult circumstances of the legacy Internet rather than a 524 principled architecture. 526 2.7. The Administration Gap 528 There has never been a shortage of proposals for ingenious mechanisms 529 for extracting important and useful information from the DNS. The 530 problem that has received far less attention is the problem of how to 531 ensure the important, useful and accurate information can be inserted 532 into the DNS in the first place and how to keep the inserted 533 information up to date. 535 In the early Internet, DNS configuration was essentially static. 536 Modern network configurations require a more dynamic approach. One of 537 the more problematic consequences of middlebox proliferation is that 538 they typically introduce a veto point into the network that must be 539 configured to allow Internet services and peer to peer applications 540 to receive inbound connections. This is also one of the main reasons 541 that the deployers consider them to be attractive. Rather than 542 attempting to prevent the network administrators from deploying 543 devices that provide control through ad-hoc heuristics we should 544 attempt to design a system that gives them the control they seek. 546 Deployment in the cloud and PKI based security both introduce a whole 547 additional dimension of dynamic discovery and administration 548 challenges. A node in a cloud computing surface might support an 549 Internet service for only a few hours. 551 3. An Internet Presentation Level 553 According to Wikipedia, the Internet Application layer includes BGP, 554 DHCP and RIP. While these are certainly not transport layer protocols 555 it is hard to argue that they sit any better in the application 556 layer. If a new model for describing the Internet architecture were 557 to be developed these would surely sit in a quite separate 558 compartment to protocols such as Telnet SMTP, IMAP, POP, NNTP and FTP 559 that support applications. 561 The OSI layered model is a poor abstraction for the Internet 562 architecture because it describes what takes place in the layers 563 rather than the interfaces between the layers. 565 It is the interfaces between the levels that are the essential part 566 of the model. We can replace the data link layer with messages 567 strapped to pigeons provided that the interface to the Network layer 568 is maintained. 570 Every level in the model carries the same data content in different 571 representations. It is the identifiers used between the levels that 572 changes. 574 * Application - Presentation: Domain Name, Service Identifier 575 * Presentation - Transport: IP Address and Port Number 577 * Transport - Network: Packet Header 579 We note in passing but do not have the time to go into the topic in 580 detail, that understanding the model in terms of interfaces rather 581 than layers is also key to establishing the proper place for Virtual 582 Private Networks (VPNs) and Software Defined Networking (SDN). A VPN 583 is not a 'Layer', it is an object that sits above the Network level 584 and presents the Network/Transport interface to both the Network and 585 Transport Level. SDN performs the same role at the Data-Link/Network 586 layer. 588 In the now defunct OSI model, the Presentation layer was an 589 intermediary through which all communications between the Transport 590 and Application layer passed being transformed in the process. 592 What is proposed instead is that the discovery, performance and 593 security features that mediate between the Transport and Application 594 layers reside in a compartment labelled 'Presentation Service' that 595 does not necessarily fully extend between the two: 597 +------------------------------------------+ 598 | Application Layer | 599 +------------------------------------------+ 600 | | | 601 +--------------+ +--------------+ | 602 | Presentation | | Presentation | | 603 | Services | | Layer | | 604 +--------------+ +--------------+ | 605 | | | 606 +------------------------------------------+ 607 | Transport Layer | 608 +------------------------------------------+ 610 DNS is a Presentation Service. Following the traditional approach, an 611 application first discovers the IP address using the DNS and then 612 establishes a direct connection. Once discovery is completed, the DNS 613 plays no further role in mediating the connection. Kerberos and PKI 614 are likewise Presentation Services and follow the same use pattern. 615 In contrast, TLS is a Presentation Layer since all communications 616 between the application and transport layers are transformed. 618 One important protocol that does not fit within this architectural 619 model is HTTP and this is precisely because HTTP was originally 620 conceived as an application protocol but is now commonly employed as 621 a presentation layer. One visible consequence of this inconsistency 622 is the conflict between the requirements of the Web browser and Web 623 services communities in the design of HTTP/2.0. 625 Although HTTP/2 eliminates some of the inefficiency arising from the 626 use of RFC822 style text headers in the HTTP/1.1 protocol design, it 627 does not provide the features that one would expect or require from a 628 fully featured multimedia delivery protocol with multiple content 629 streams being delivered at individually negotiated Packet layer 630 Quality of Service. Nor does the traditional Internet architecture 631 suggest such an approach is even possible. 633 While the realization of such a presentation layer would likely 634 require innovation at both the Presentation and Transport layers and 635 is therefore outside the scope of this document, it should be the 636 function of the Presentation l ayer to inform an application that 637 such a capability was available and thus enable a graceful transition 638 between the current protocol and the new. Thus a browser attempting 639 to connect to http://example.com/ in a 2020 Internet might discover 640 that the HTTP/1.1 and HTTP/2 protocols are supported over a TCP 641 transport and that in addition HTTP/3 is supported over an as-yet- 642 undefined 'Extended' ETCP transport. 644 3.1. Authoritative Infrastructures and Ground Truth 646 The DNS infrastructure is regarded as holding a privileged position 647 in the Internet architecture as it is the authoritative 648 infrastructure for resolving DNS names. But what does the term 649 'authoritative' mean and is a result from an authoritative 650 infrastructure necessarily better than a result that is not 651 authoritative? 653 In considering the issue of naming we distinguish an authoritative 654 infrastructure from a service protocol. What makes a naming 655 infrastructure authoritative is that it serves as the 'ground truth' 656 for a set of names. Thus when in the early 1990s a Sun workstation 657 used the yellow pages protocol to resolve DNS names, the application 658 clients did not use DNS protocol to resolve DNS names but they were 659 still logically connected to the Internet since the DNS 660 infrastructure provided the ground truth for the name resolution 661 process. 663 The DNS infrastructure is, was and will always be the authoritative 664 infrastructure for resolving Internet names. The DNS protocol is 665 merely a protocol that supports access to the DNS infrastructure and 666 can change if necessary to meet changing constraints and 667 requirements. 669 While results from the DNS infrastructure are authoritative, they do 670 not necessarily represent a an objective ground truth that is 671 guaranteed to be the same regardless of who is asking the question 672 and when the question is being asked. Only cryptography can provide 673 ground truth in a communication infrastructure and then only with 674 respect to a key and not to facts. 676 3.2. Anti-Abuse Filtering 678 Consider the case in which a DNS registration is known to be used by 679 organized crime. This situation has occurred on numerous occasions 680 and is unavoidable in any system that is designed to provide no 681 obstacles to legitimate registrations. there have even been cases in 682 which DNS registrars have existed for the sole purpose of 683 facilitating criminal activity. The mere fact that a DNS name is 684 registered does not require a discovery service to resolve it. 686 There is a clear need for a curated discovery service just as 687 enabling such a service presents a clear threat of abuse. Curated 688 discovery introduces a new control point and some see a slippery 689 slope that begins with filtering out criminal activity expands to 690 block access to pornography and eventually ends up as government 691 censorship of political speech. 693 But slippery slope or not, relying on unfiltered authoritative 694 services replaces the possibility of abuse with certainty of attack. 695 The real question should be not whether curated discovery is possible 696 but who is in control. An infrastructure that puts the end user in 697 direct control of the choice of discovery service can be used as a 698 mechanism to evade government censorship rather than enforce it. 700 3.3. IPv6 Transition 702 The DNS infrastructure provides us with an authoritative answers to 703 questions about DNS names but not necessarily answers to the 704 questions that a particular application needs. 706 An A record binding the name ipv4.example.com to the address 10.1.2.3 707 does not answer the question a network host that can only speak IPv6 708 needs to ask. 710 In the traditional approach to IPv6 transition we introduce some form 711 of middlebox performing v4-v6 address translation, some form of 712 discovery mechanism by which the network host can discover the 713 translation middlebox and some form of addressing convention allowing 714 the host to direct an IPv6 packet to an IPv4 endpoint. While this 715 gets the job done, it requires the IPv6 network host to continue to 716 support IPv4 for as long as there are any IPv4 hosts remaining in the 717 network which for practical purposes means forever. 719 In a simpler approach the network host implements a pure IPv6 stack 720 with no support for legacy IPv4 or any transition mechanism. When the 721 host attempts to connect to an Internet service that is only 722 available in the IPv4 network, it would rely on its DNS resolver to 723 return a non-authoritative AAAA record giving the IPv6 address of a 724 translation service. 726 The second approach makes the DNS resolver the mediator of the IPv4- 727 to-v6 transition process. If a legacy IPv4 network sets up a local 728 translation gateway, a single change to the resolver configuration 729 allows every host using that resolver to take advantage of it. 730 Centralizing the configuration provides the necessary agility. 732 3.4. DNSSEC 734 As we have seen, the authoritative response is not necessarily the 735 one that answers the right question. Where does this leave DNSSEC 736 which is designed to allow verification of signatures on 737 authoritative responses? 739 While some DNSSEC supporters will no doubt argue that allowing a 740 client to act on non-authoritative DNS information opens up a 741 Pandora's box of horrors, the true situation is far less worrisome. 742 Using DNSSEC to sign A and AAAA records is like using an armored 743 delivery truck for delivering packages to a person living on a park 744 bench. An IP address is a means and only sometimes an end-point in an 745 Internet conversation. Resolver modification of A and AAAA should not 746 therefore be cause for panic. But what should? 748 The Presentation service model offers a useful framework for 749 resolving this question. The interfaces between layers are 750 characterized by a particular type of identifier. The IP address and 751 protocol type characterize the interface between the Internet and 752 Transport layer. The IP address and port number characterize the 753 interface between the Transport layer and the presentation layer. The 754 interface between the presentation layer and the Application layer is 755 characterized by DNS names and cryptographic credentials. 757 It is appropriate therefore to perform end-to-end validation of 758 signatures on records that bind cryptographic credentials to a DNS 759 name and to limit other DNSSEC validation to the DNS resolution 760 service. 762 3.5. Naming Architecture 764 Discovery is the process of resolving names to services and names to 765 accounts. In order to establish a solid basis for a Discovery 766 architecture we must first establish a consistent approach to naming. 768 While Uniform Resource Identifiers are commonly considered to be an 769 'Internet' naming architecture, the scope of URIs is universal and 770 not limited to the Internet. URIs therefore represent a naming 771 infrastructure layer above the Internet rather than a part of the 772 Internet itself. 774 In practice the Internet has three naming/addressing infrastructures 775 that are established with clarity: 777 * Autonomous Service numbers 779 * Internet Protocol addresses 781 * Domain Name System labels. 783 Of these naming conventions, only the last two are visible to 784 Internet endpoints in normal circumstances. At a pragmatic level, an 785 IP address is defined as where packets sent to that address will go 786 and a DNS label is defined by the responses returned by the DNS 787 infrastructures. 789 The interpretation of Internet account identifiers is not established 790 with similar clarity. While SMTP and XMPP both adopt a reasonable and 791 consistent approach to interpretation of RFC822 account names, the 792 lack of a coherent discovery architecture has led to what is at best 793 an unhelpful divergence of approaches and at worst a demonstration of 794 the fact that a hundred intelligent and accomplished Internet 795 protocol developers and a dozen major companies can commit resources 796 to the notion that users will understand a URI is their account name. 798 3.5.1. Account Names 800 Internet account names are account names of the form introduced in 801 RFC822, i.e. @. 803 The authoritative source for resolution of an Internet account name 804 is an Internet service that is advertised in the DNS by the holder of 805 the corresponding . 807 At present there are application protocols, notably SMTP a nd XMPP 808 that follow this model but the authoritative resolution of the 809 account is limited to the application. There is no authoritative 810 Internet service resolving Internet accounts in the general case. 812 The problem here is not the lack of a protocol. It would be easy 813 enough to specify a subset of the OpenID protocol that excluded URIs, 814 XRIs and other identifiers that are not Internet accounts. The 815 problem is that the service has to be recognized as authoritative. 816 And this cannot happen when OpenID is still architected as a vehicle 817 for establishing a new Internet naming infrastructure for accounts 818 with all the commercial advantages that would imply for the parties 819 who control the institutions controlling the alleged IPR. 821 From a practical point of view, the authoritative infrastructure for 822 Internet accounts is email. Established practice is that when a user 823 forgets their account identifier or password they are asked to 824 respond to a message sent to their Internet account address using the 825 SMTP protocol. While this approach is expedient, the user experience 826 is awful and so Web site designers avoid consulting the authoritative 827 service wherever possible. The user experience and the security of 828 this infrastructure could be greatly improved if a protocol was 829 designed to meet this specific purpose. 831 3.5.2. Strong Names 833 The Personal Privacy Environment introduced the concept of Strong 834 Email Addresses. A strong email address is of the form 835 ?@ where the and 836 portions have the usual meaning and is a cryptographic 837 digest identifying a public key which represents the root of trust 838 for establishing communication with the specified Internet account. 840 In the simplest form of strong email address is a PGP 841 public key fingerprint associated with the address. In a more general 842 approach, is the fingerprint of a public key that is a 843 root of trust for a PKI. This may be a formal PKI hierarchy 844 established by a CA, a lightweight personal hierarchy or a Web of 845 Trust. 847 In this paper we extend this approach to DNS labels to establish 848 ground truth for DNS names. Following the convention established by 849 punycode domain names, a strong domain name label has the form "xx--" 850 + where is a cryptographic digest 851 identifying a public key which represents the root of trust for 852 authenticating the domain name. 854 Thus if we wish to describe a domain 'example.com' to be interpreted 855 with respect to the ICANN DNSSEC root of trust we would write: 857 example.com.xx--49AAC1-1D7B6-F6446-702E5-4A1607-3716 859 49AAC11.. being the fingerprint of the ICANN DNSSEC root. 861 Representing the ICANN DNSSEC root in this way is not particularly 862 interesting as it is the implicit root of trust for all DNSSEC names 863 (although it could be very useful in the case of a root roll over). 864 The strong name representation becomes much more interesting when a 865 third party trust provider is involved such as a CA: 867 example.com.xx--cd9b97-e67b74-99a33f-59128e-f2cd46-3156e5-f6bd 869 The advantage of using a strong email address is that it provides a 870 layer of abstraction that conceals the complexity of the trust 871 infrastructure that lies beneath it in the same way that IP addresses 872 provide a layer of abstraction above the routing infrastructure and 873 URIs provide a layer above the application protocol stack. This has a 874 profound impact on how we address the problem. 876 In the traditional approach to Internet PKI (including SAML and 877 DNSSEC) the approach we follow is to obtain signed assertions 878 relevant to the proposition at issue from trusted sources, verify the 879 provenance of the assertions received by attempting to validate the 880 signatures and decide if the assertions are valid. In this model an 881 assertion is either valid or invalid. So when a party is acting as an 882 intermediary on behalf of another they are forced to respond as if 883 their answer is based on ground truth when it almost certainly is 884 not. 886 Simple Distributed Security Infrastructure (SDSI) by Rivest and 887 Lampson attempted to resolve this dilemma by introducing a key 888 centric PKI in which the namespace is intrinsically relative. Thus in 889 SDSI we talk about 'Bob's Alice' rather than 'Bob'. Ground truth is 890 introduced into the SDSI scheme by giving a small circle of 891 privileged parties reserved names (the paper suggests verisign!!, 892 dns!!, usps!!). This approach left SDSI deferring rather than 893 resolving the ground truth problem. 895 Using a fingerprint of a public key provides a ground truth that is 896 objective and unambiguous. We now have a vocabulary in which Web 897 Service A can describe to B the trust assertion it has received that 898 is grounded by trust provider C. And that allows us to be explicit as 899 to whether a B is relying on A or C as the trust provider. 901 3.6. Discovery Services 903 The traditional IETF approach to the discovery and maintenance 904 problems has been piecemeal. Instead of calling gethostbyname and 905 opening up a socket, the application programmer is expected to 906 interact with the half dozen components of a disparate discovery and 907 network configuration infrastructure, hoping that the network 908 administrators at the service to which connection is to be 909 established has done their part correctly. While these piecemeal 910 approaches generally anticipate a gradual migration of the relevant 911 functions to the DNS, the only process by which the DNS 912 infrastructure is expected to improve is through the gradual 913 attrition of non-conformant systems. 915 In this paper we take a different approach. Rather than burden the 916 application programmer with new chores, we reduce the effort expected 917 of them by providing a new Presentation API that provides an 918 abstraction layer above all the Presentation services that might be 919 used to establish a connection. 921 3.6.1. Consistent Discovery API 923 To establish a connection to an Internet service, the application 924 programmer need specify only the domain name of the service to 925 connect to and the service protocol identifier. The implementation 926 library then returns either a stream (or socket) connection to the 927 requested service with the best available security and performance 928 characteristics as specified by the service security policy or an 929 error report explaining why a connection was not established. 931 For example, if a Web browser were to attempt to resolve the URL 932 http://example.com/ the browser client would call the discovery API 933 specifying "example.com" as the domain name and "_http._tcp" as the 934 service protocol identifier. The implementation library finds the 935 service is supported by five points of presence and determines that 936 the example.com service security policy is to always offer TLS. A TLS 937 connection is established to an appropriately selected point of 938 presence consistent with the security credentials specified in the 939 security policy and delivered to the application programmer. 941 Offloading the work of establishing the Internet connection from the 942 application programmer to the implementation library offers agility 943 as well as simplicity. If a new high performance transport layer 944 protocol were devised that replaced TCP, every application using the 945 high level discovery API running on a platform that supported the new 946 transport layer protocol can make use of it immediately with no 947 application update required. 949 The same API would support peer to peer connections in the same 950 fashion but specifying the account identifiers of the parties 951 attempting to connect in place of the domain name. 953 The only precondition for implementing a consistent discovery API is 954 that the rules of discovery be clearly and precisely specified. The 955 discovery process might be uniform across all application protocols 956 or allow for variations to support legacy approaches. For example the 957 use of MX records rather than SRV records for SMTP service discovery. 958 It is not even necessary that all the required information be 959 provided through the DNS provided that the rules for using 960 information from other sources are precisely specified. 962 4. Implementation 964 While this paper proposes a major change to the Internet 965 architecture, the implementation of this change is surprisingly 966 simple. This is because the principal change proposed is to recognize 967 approaches that have been longstanding practice. 969 The implementation of the Presentation services follows a modular 970 approach. Each service is implemented as a JSON/REST style Web 971 service using either HTTPS or a lightweight UDP transport as the 972 base. 974 4.1. Connection Broker 976 SXS-Connect is a JSON-REST Web Service that is used to establish a 977 connection to a Web Service. As with a DNS SRV record, a service 978 connection is a logical connection that may comprise connections to 979 multiple physical hosts. Unlike an SRV connection, the physical hosts 980 may advertise services that differ in the protocol versions, 981 features, transport, syntax etc. 983 Authentication of client and server is supported by means of public 984 key or one time use credentials. Irregardless of whether the original 985 connection to the SXS-Connect service was authenticated or not, 986 communication between the client and the Web service is typically 987 secured by means of a shared secret that is used to protect the 988 confidentiality and integrity of every transaction message. 990 In normal operation a client discovers the SXS-Connect service 991 through a 'bootstrap discovery' mechanism based on either DHCP or the 992 DNS. Depending on the type of service provided, bootstrap discovery 993 might be repeated on a frequent basis (e.g. each time the bootstrap 994 DNS parameters expire), whenever the service signals a need for 995 reconfiguration or never. 997 4.2. Private DNS - Eliminating Legacy DNS restrictions 999 As shown earlier, one of the biggest obstacles to making effective 1000 use of the DNS as a comprehensive discovery infrastructure are the 1001 limitations of the legacy DNS client-resolver protocol. In particular 1002 the conflicting demands of lowest possible service latency from the 1003 application programmers and the limits of message size and queries 1004 per request imposed by the legacy middlebox infrastructure. 1006 Attempting to sort out the mess on port 53 is pointless. Any proposal 1007 that inherits the legacy DNS UDP port will inevitably inherit the 1008 legacy DNS restrictions as well. But any solution that does not meet 1009 the severe performance criteria demanded of the Web browser 1010 providers, particularly with respect to latency is doomed, as is any 1011 proposal that does not guarantee compatibility with all legacy 1012 network environments. 1014 Private-DNS is a replacement transport for the DNS client-resolver 1015 interface that offers two alternative transports, a new UDP based 1016 transport that is designed to provide optimum performance while being 1017 compatible with roughly 97% of legacy network configurations and a 1018 HTTP transport which is slow but provides the best practical 1019 guarantee of network compatibility. In either case, every message is 1020 encrypted and authenticated and responses securely bound to requests. 1022 Unlike competing proposals based on DTLS, the Private-DNS transport 1023 is designed to support DNS conversations rather than single 1024 transactions. This permits lower latency and more comprehensive 1025 results. 1027 When connecting to a Web site www.example.com, a Web browser today 1028 typically performs queries for A and AAAA records at www.example.com. 1029 In theory, the DNS protocol permits multiple queries per message, in 1030 practice this capability is not viable as a message can only return a 1031 single response and much of the infrastructure does not support it. 1033 The requirement that every query be performed in a separate query 1034 transaction discourages speculative requests for SRV, DANE or other 1035 DNS records that might contain useful information. This in turn 1036 discourages definition of useful record types. 1038 As in the traditional DNS UDP transport, the UDP transport employed 1039 in Private-DNS requires that the request portion of a DNS 1040 conversation fit within a single UDP packet but up to 16 packets may 1041 be returned in a response. 1043 The practical result of this change is that every reasonable DNS 1044 conversation can be realized in a single Private-DNS interaction 1045 without performance penalty. Instead of protocol designers and DNS 1046 administrators constantly having to worry that an overamitious design 1047 would lead to poor performance or protocol failure, it is quite 1048 unlikely that the limits of the transport would be reached 1049 inadvertently. 1051 4.3. OmniQuery - A Presentation Level Discovery Service 1053 Private-DNS provides a low level interface to the DNS system allowing 1054 a network client to implement a Presentation service on the local 1055 machine. But the responses returned by Private-DNS are limited to 1056 those provided by the DNS and as previously noted, the authoritative 1057 answer is not always the one that is desired. 1059 OmniQuery is a Web service that exposes the Presentation level 1060 discovery API as a Web Service. 1062 A client asks 'How can X connect to Y to perform protocol Z' where X 1063 and Y may be Internet accounts or domain names and Z is the name of 1064 an Internet service. The server then returns all the information that 1065 the client might want to know to establish the best connection for 1066 that purpose. In addition to the IP address and port number, a server 1067 might specify the transport to be used (e.g. UDP, TCP, some new 1068 transport) the cryptographic enhancements to be applied (e.g. TLS), 1069 required credentials and any other information that might be needed. 1071 Unlike the traditional DNS discovery infrastructure, OmniQuery allows 1072 both ends of the communication to be specified. The mechanism by 1073 which alice@example.com connects to example.com might be very 1074 different to the mechanism by which other parties connect. 1075 Connections may also be established between peers (e.g. 1076 alice@example.com connects to bob@example.com). 1078 One consequence of this difference in approach is that rather than 1079 accepting service from the closest discovery service, as is typically 1080 the case with DNS, clients select a particular service for OmniQuery 1081 service which is used regardless of client location. 1083 4.4. OmniPublish - A Presentation Level Provisioning Service 1085 One of the principal weaknesses in the current DNS infrastructure is 1086 that while there is a well developed standards based infrastructure 1087 for extracting data from the DNS, there is no similar standards based 1088 infrastructure for entering information. Provisioning services for 1089 other directory infrastructures and PKI are equally unsatisfactory. 1091 OmniPublish provides a high level interface that allows an Internet 1092 host to advertise an Internet Service and to obtain all the necessary 1093 cryptographic credentials to act in that role. In a typical 1094 deployment, an OmniPublish service is connected the DNS service, PKI 1095 and network firewall so that it can perform all the configuration 1096 steps necessary to configure the network to bring up the service. 1098 For example, consider the case that an Internet host is to be 1099 configured to establish a mail service. In the normal approach, the 1100 network administrator would configure the server on the Internet 1101 host, configure the firewall to permit delivery of mail and finally 1102 configure the local DNS settings. 1104 Not only is this approach complex, it is fragile. Any error in the 1105 network configuration is likely to result in an inoperable service. 1106 Network administrators are therefore understandably reluctant to make 1107 unnecessary changes. DNS records and firewall configuration settings 1108 that are not fully understood tend to be left untouched. This makes 1109 manually configured DNS a rather unreliable source of security policy 1110 records. While the records may be authoritative, they are frequently 1111 out of date. Mail abuse filters do not make mail delivery decisions 1112 on DKIM or SPF records without first applying heuristics designed to 1113 limit the impact of stale records. 1115 Generating the network configuration automatically allows the 1116 OmniPublish service to ensure that it is both correct and up to date. 1117 If a major change in network configuration is to be performed, the 1118 OmniPublish service provides a single point of control through which 1119 the change can be administered. 1121 5. Conclusions 1123 Middleboxes have emerged to meet a set of requirements that cannot be 1124 achieved within the traditional Internet model. Middleboxes are 1125 neither the result of ignorance, nor a 'necessary evil'. It is time 1126 to accept that middleboxes serve functions in the Internet 1127 infrastructure that are equally important to those traditionally 1128 recognized. 1130 Describing the Internet model in terms of interfaces rather than 1131 functions and adding a presentation level clarifies the functions of 1132 middleboxes and how those functions might be achieved in ways that do 1133 not compromise functionality in the ways that legacy middleboxes do. 1135 A set of three JSON based Web services are proposed to properly 1136 encapsulate the interaction between the Presentation layer and the 1137 Applications and Transport layers. These are OmniPublish, OmniQuery 1138 and Private DNS, each of which is built on the service connection 1139 protocol SXS-Connect. 1141 6. References 1143 6.1. Normative References 1145 [I-D.hallambaker-privatedns] Hallam-Baker, P, "Private-DNS", 1146 Internet-Draft draft-hallambaker-privatedns-00, 9 May 1147 2014. 1149 [I-D.hallambaker-wsconnect] Hallam-Baker, P, "JSON Service Connect 1150 (JCX) Protocol", Internet-Draft draft-hallambaker- 1151 wsconnect-05, 21 January 2014. 1153 [I-D.hallambaker-omnibroker] Hallam-Baker, P, "OmniBroker Protocol", 1154 Internet-Draft draft-hallambaker-omnibroker-07, 21 January 1155 2014. 1157 [I-D.hallambaker-omnipublish] Hallam-Baker, P, "OmniBroker 1158 Publication Protocol", Internet-Draft draft-hallambaker- 1159 omnipublish-00, 22 May 2014. 1161 6.2. Informative References 1163 [RFC0801] Postel, J., "NCP/TCP transition plan", RFC 801, 1 November 1164 1981. 1166 Author's Address 1168 Phillip Hallam-Baker 1169 Comodo Group Inc. 1171 philliph@comodo.com