idnits 2.17.1 draft-hildebrand-middlebox-erosion-01.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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 10, 2014) is 3454 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hildebrand 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational P. McManus 5 Expires: May 14, 2015 Mozilla 6 November 10, 2014 8 Erosion of the moral authority of transparent middleboxes 9 draft-hildebrand-middlebox-erosion-01 11 Abstract 13 Many middleboxes on the Internet attempt to add value to the 14 connections that traverse that point on the network. Problems in 15 their implementations erode the moral authority that otherwise might 16 accrue to the legitimate value that they add. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 14, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Introduction 52 There are several middlebox use cases that typically stand in the way 53 of better encryption helping to mitigate perpass-style attacks. 55 o Local caching 57 o Enterprise policy controls, including Data Loss Prevention (DLP) 58 and monitoring for acceptable use 60 o Service provider acceleration of mobile data 62 o Network management and quality of service routing 64 o Authorization and billing of network services 66 These use cases may cause third parties to an otherwise end-to-end 67 conversation to have legitimate legal and moral rights that grant 68 them participation in the conversation. This document discusses 69 several reasons why the legitimacy of these use cases is undermined 70 in the minds of some who build other products for the Internet. 72 2. Similarity to attacks 74 Some middlebox capabilities are currently implemented using the same 75 mechanisms employed by attackers, including passive capturing of 76 plaintext data, active impersonation, and denial of service. 77 Further, some services are legitimate in one context but illegitimate 78 in another - and the transparent nature of the middleboxes creates 79 security problems separating those problem domains. 81 It is difficult to design protocols that simultaneously prevent a 82 given vulnerability and simultaneously selectively allow legitimate 83 access, and arguments that particular attacks cannot therefore be 84 mitigated are greeted by end-users with skepticism - particularly 85 when the benefit added by the middlebox does not accrue directly to 86 those users. 88 3. Unintentional breakage 90 The experiences of living with a wide variety of middleboxes in the 91 real world lead developers to realize that they all have defects that 92 go years without being addressed. Even when the vendor fixes a given 93 bug, software is updated so infrequently at this layer that often the 94 bug must just be worked around. 96 Developers that have to add multiple special cases to their products 97 as they discover every new way to incorrectly implement what they 98 previously thought were simple protocols often overreact by using 99 protocols that are harder to manage, have worse security properties, 100 or perform poorly. 102 Even middleboxes that are operating correctly become design 103 constraints that inhibit end to end innovation because of their 104 centralized model. A middlebox that inserts itself into all web 105 traffic on a network but only speaks HTTP/1.1 will not allow the 106 evolution of any device on that network beyond that state. 108 4. Support cost appropriation 110 When a middlebox subtly fails, end users never call the entity that 111 deployed the middlebox, much less the vendor that built that box. 112 Indeed, the nature of a transparent middlebox makes it very difficult 113 to even diagnose the error for a professional. Instead, they file a 114 support request with the services that they are trying to access. 116 The team that developed that service typically spends many hours 117 finally tracking down the issue, only to finally find the problem 118 with the middlebox. The original end user never has the authority to 119 fix the middlebox or even opt out of using it. Instead they demand 120 the service owner work around the problem. The service implementor 121 may not have any more control than the end user, so too often the 122 result is that new technologies have to be abandoned because they are 123 not backwards compatible with middlebox infrastructure that neither 124 the end user nor service operator has direct control over. This 125 dynamic holds back Internet evolution. 127 When the costs associated with broken behavior are not paid by the 128 developers of that behavior, it is easy for those developers to 129 assume that everyone is happy with their product. 131 5. Other monetary incentives 133 Developers of new services will often try to make their network 134 traffic as similar as possible to an existing essential service. 135 This approach maximizes the chances that they will be able to develop 136 a user base, however it can stress middleboxes beyond their design 137 constraints causing them to fail in new ways. 139 When middlebox developers bring about their own downfall by pushing 140 application providers outside of natural design patterns, they do not 141 impress the community with their desire to be trustable elements of 142 the Internet architecture. 144 6. Conclusions 145 When the moral authority of middleboxes is eroded, arguments by their 146 developers to allow unfettered access to the plaintext of traffic 147 that traverses those boxes may be called into question. 149 As an industry, we should look for other mechanisms to provide 150 legitimate third-party value. Explicitly addressed intermediaries 151 offer an alternative to transparent middleboxes. Addressing the 152 harder problems of service discovery and authorization would make 153 these services more effective, robust, and secure than their existing 154 middlebox counterparts. 156 7. References 158 Authors' Addresses 160 Joe Hildebrand 161 Cisco Systems, Inc. 163 Email: jhildebr@cisco.com 165 Patrick McManus 166 Mozilla 168 Email: pmcmanus@mozilla.com