idnits 2.17.00 (12 Aug 2021) /tmp/idnits10022/draft-hildebrand-middlebox-erosion-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.) ** 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 (January 15, 2014) is 3047 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 January 15, 2014 5 Expires: July 19, 2014 7 Erosion of the moral authority of middleboxes 8 draft-hildebrand-middlebox-erosion-00 10 Abstract 12 Many middleboxes on the Internet attempt to add value to the 13 connections that traverse that point on the network. Problems in 14 their implementations erode the moral authority that otherwise might 15 accrue to the legitimate value that they add. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 19, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 There are several middlebox use cases that typically stand in the way 52 of better encryption helping to mitigate perpass-style attacks. 54 o Local caching 56 o Enterprise policy controls, including Data Loss Prevention (DLP) 57 and monitoring for acceptable use 59 o Service provider acceleration of mobile data 61 o Advertisement insertion for "free" networks 63 These use cases may cause third parties to an end-to-end conversation 64 to have legitimate legal and moral rights that grant them 65 participation in the conversation. This document discusses several 66 reasons why the legitimacy of these use cases is undermined in the 67 minds of some who build products for the Internet. 69 2. Similarity to attacks 71 Some middlebox capabilities are currently implemented using the same 72 mechanisms employed by attackers, including passive capturing of 73 plaintext data, active impersonation, and denial of service. 75 It is difficult to design protocols that simultaneously prevent a 76 given vulnerability and simultaneously selectively allow legitimate 77 access, and arguments that particular attacks cannot therefore be 78 mitigated are greeted by end-users with skepticism - particularly 79 when the benefit added by the middlebox does not accrue directly to 80 those users. 82 3. Unintentional breakage 84 The experiences of living with a wide variety of middleboxes in the 85 real world lead developers to realize that they all have defects that 86 go years without being addressed. Even when the vendor fixes a given 87 bug, software is updated so infrequently at this layer that often the 88 bug must just be worked around. 90 Developers that have to add multiple special cases to their products 91 as they discover every new way to incorrectly implement what they 92 previously thought were simple protocols often overreact by using 93 protocols that are harder to manage, have worse security properties, 94 or perform poorly. 96 4. Support cost appropriation 98 When a middlebox subtly fails, end users never call the entity that 99 deployed the middlebox, much less the vendor that built that box. 100 Instead, they file a support request with the services that they are 101 trying to access. The team that developed that service typically 102 spends many hours finally tracking down the issue, only to finally 103 find the problem with the middlebox. The original end user never has 104 the authority to fix the middlebox, so they demand the service owner 105 work around the problem. 107 When the costs associated with broken behavior are not paid by the 108 developers of that behavior, it is easy for those developers to 109 assume that everyone is happy with their product. 111 5. Other monetary incentives 113 Developers of new services will often try to make their network 114 traffic as similar as possible to an existing essential service. 115 This approach maximizes the chances that they will be able to develop 116 a user base, however it can stress middleboxes beyond their design 117 constraints causing them to fail in new ways. 119 When middlebox developers bring about their own downfall by pushing 120 application providers outside of natural design patterns, they do not 121 impress the community with their desire to be trustable elements of 122 the Internet architecture. 124 6. Conclusions 126 When the moral authority of middleboxes is eroded, arguments by their 127 developers to allow unfettered access to the plaintext of traffic 128 that traverses those boxes may be called into question. 130 As an industry, we should look for other mechanisms to provide 131 legitimate third-party value. 133 7. References 135 Author's Address 137 Joe Hildebrand 138 Cisco Systems, Inc. 140 Email: jhildebr@cisco.com