



Network Working Group                                      M. Nottingham
Internet-Draft                                        September 22, 2017
Intended status: Best Current Practice
Expires: March 26, 2018


                   Scoping Protocols for the Internet
                 draft-nottingham-scoping-protocols-00

Abstract

   This document explores the properties of changes to protocols that
   might be harmful if widely deployed, and suggests guidelines for
   evaluating whether they should be published.

Note to Readers

   _RFC EDITOR: please remove this section before publication_

   The issues list for this draft can be found at
   https://github.com/mnot/I-D/labels/for-everyone.

   The most recent (often, unpublished) draft is at
   https://mnot.github.io/I-D/for-everyone/.

   Recent changes are listed at https://github.com/mnot/I-D/commits/gh-
   pages/for-everyone.

   See also the draft's current status in the IETF datatracker, at
   https://datatracker.ietf.org/doc/draft-nottingham-for-everyone/.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 26, 2018.




Nottingham               Expires March 26, 2018                 [Page 1]

Internet-Draft              Scoping Protocols             September 2017


Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   3
   2.  Scoping Protocols for the Internet  . . . . . . . . . . . . .   4
     2.1.  Defining Limited Scope  . . . . . . . . . . . . . . . . .   4
     2.2.  What is "Harmful"?  . . . . . . . . . . . . . . . . . . .   4
     2.3.  Can Harmful Deployment Be Avoided?  . . . . . . . . . . .   4
     2.4.  Considering the Impact of Standardisation . . . . . . . .   5
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   [RFC3935] declares that the goal of the IETF "is to make the Internet
   work better."

   It goes on to define the Internet as:

      A large, heterogeneous collection of interconnected systems that
      can be used for communication of many different types between any
      interested parties connected to it.  The term includes both the
      "core Internet" (ISP networks) and "edge Internet" (corporate and
      private networks, often connected via firewalls, NAT boxes,
      application layer gateways and similar devices.

   But later, in Section 4.2, goes on to say:





Nottingham               Expires March 26, 2018                 [Page 2]

Internet-Draft              Scoping Protocols             September 2017


      In attempting to resolve the question of the IETF's scope, perhaps
      the fairest balance is struck by this formulation: "protocols and
      practices for which secure and scalable implementations are
      expected to have wide deployment and interoperation on the
      Internet, or to form part of the infrastructure of the Internet."

   When a new proposal is brought to the IETF, this scope is important
   to keep in mind; if the proposal is specified to certain kinds of
   deployments, but might cause harm in others, it could be
   inappropriate to "have wide deployment and interoperation on the
   Internet" as a whole.

   For example, a datacentre network might want to change how congestion
   control operates (or remove it entirely) inside its confines.  While
   this might be advantageous in a controlled environment, it would be
   disastrous to do so on the open Internet, as it would result in
   congestion collapse [I-D.ietf-tcpm-dctcp].

   Or, a financial institution might need to conform to regulations
   specific to them, and thus need to change how encrypted protocols on
   their network operate to enable efficient monitoring of activity,
   while still adhering to their security requirements.  While this
   might be seen as pragmatic in that environment, using such techniques
   on the open Internet would be widely seen as a step (or many steps)
   backwards in security, as it would sacrifice forward security, and
   furthermore be prone to abuse for attacks such as pervasive
   monitoring [RFC7258].

   In discussing such proposals, there is often a question of whether it
   is appropriate to promote something to Internet Standard, or even
   publish it at all.

   Clearly, every Internet specification need not be deployable on every
   Internet-connected network; likewise, the very possibility of harm
   does not automatically preclude standardisation.  However, when the
   potential consequences and/or likelihood of deployment outside the
   intended environment are too great, such a proposal needs much more
   careful vetting.

   This document explores the properties of such "limited scope"
   proposals and suggests guidelines for evaluating whether they should
   be published.

1.1.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].



Nottingham               Expires March 26, 2018                 [Page 3]

Internet-Draft              Scoping Protocols             September 2017


2.  Scoping Protocols for the Internet

   Engineers often concentrate on the problems immediately in front of
   them, and propose solutions that minimally solve those problems.
   While this is acceptable practice in a limited, known environment,
   this style of engineering often fails when proposing changes to the
   Internet, because it is such a diverse environment.

   In a limited environment, it's not uncommon to be able to make a
   variety of assumptions about deployment architecture, user
   expectations, traffic characteristics, and so on.  On the Internet as
   a whole, this is not true; not only is it diverse, but it is also
   open; we do not know all of the ways in which is is used, deployed,
   or operated.

   Therefore, proposals to change it need to consider what effect they
   will have when deployed generally, not just specifically within the
   scope they were designed for.

2.1.  Defining Limited Scope

   A proposal is said to have "limited scope" if it is designed with
   deployment on a subset of the Internet, or if it is known to only be
   suitable for deployment on a subset of the Internet.

   A subset of the Internet could be a single network, or a single type
   of Internet-connected network.  Generally, it would be considered
   "edge Internet", using [RFC3935] terminology.

   A proposal could be a new protocol, an extension to an existing
   protocol, or a change to an existing protocol.

2.2.  What is "Harmful"?

   "Harm" is not defined in this document; that is something that the
   relevant body (e.g., Working Group) needs to discuss.  The IETF has
   already established a body of guidance for such decisions, including
   (but not limited to) [RFC7754] on filtering, [RFC7258] and [RFC7624]
   on pervasive surveillance, [RFC7288] on host firewalls, and [RFC6973]
   regarding privacy considerations.

2.3.  Can Harmful Deployment Be Avoided?

   A key consideration when evaluating a limited-scope proposal is
   whether harmful deployment can be avoided.  This is most often done
   by considering the incentives for various parties to deploy - or
   avoid deploying - the proposal more widely.




Nottingham               Expires March 26, 2018                 [Page 4]

Internet-Draft              Scoping Protocols             September 2017


   For example, a proposal to disable congestion control in TCP needs to
   be enabled in the operating system (in most current implementations).
   The operating system vendor has a strong incentive to deliver
   flexible yet safe systems; congestion collapse due to irresponsible
   deployment will lead to less use of that operating system, so the
   vendor will assure that it is deployed responsibly, most likely by
   requiring the administrator of the machine to explicitly configure
   their machine to do so.

   The administrator, in turn, has a strong incentive to make sure that
   all applications on the machine have fair network access, and that
   the machine is no penalised as a bad actor by the network it operates
   within; operating without congestion control on an ISP network, for
   example, will eventually get noticed, and likely result in access
   being terminated.

   These incentives suggest that it is safe for the IETF to define
   limited-deployment modifications to congestion control, because wider
   deployment on the Internet - where it would be harmful - is against
   the interests of the relevant parties.

   A counterexample would be a proposal to weaken encryption to make it
   possible to monitor it in enterprise networks.  While there might be
   a reasonable argument for deploying this in a constrained network,
   the potential harm if it is deployed on the broader Internet is
   considerable; it could be used to enable pervasive monitoring
   [RFC7624], for example.

   It's much less clear whether the appropriate incentives are in place
   to avoid harmful deployment of such a proposal.  Depending on the
   specifics of how it worked, deployment could be compelled, for
   example.

2.4.  Considering the Impact of Standardisation

   When the IETF determines that a limited-scope proposal cannot be
   published due to its potential harm, a few counter-arguments usually
   surface.

   It is sometimes argued that if the IETF withholds standards-track
   status (or publication altogether) the proponents can still have
   their proposal published as an Individual Submission, or by another
   standards organisation.

   This might be true, but it ignores the imprimatur of the IETF
   Standards Track; becoming an IETF standard _does_ have demonstrable
   value, otherwise participants would not have invested significant




Nottingham               Expires March 26, 2018                 [Page 5]

Internet-Draft              Scoping Protocols             September 2017


   resources into creating them, and indeed the proponents would not
   have brought their proposal to the IETF.

   Likewise, publication as an RFC - even on another track - is
   perceived by many as an implied endorsement by the IETF.

   A similar argument is that by accepting such work into the IETF, we
   can minimise harm and avoid something worse being published
   elsewhere.  Again, this might be true, but if we compromise our
   values (as expressed in existing Internet Standards and Best Current
   Practices) to do so, this is a loss much greater than the area of the
   proposal in question; it establishes a precedent for further erosion
   of them, and dilutes their current expression.  This must be avoided.

   While the bar is lower for other documents (e.g., Informational), it
   is expected that the same considerations will apply for any document
   that is an IETF work product.

3.  IANA Considerations

   This document has no actions for IANA.

4.  Security Considerations

   TBD

5.  References

5.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
              editor.org/info/rfc2119>.

5.2.  Informative References

   [I-D.ietf-tcpm-dctcp]
              Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
              and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion
              Control for Datacenters", draft-ietf-tcpm-dctcp-10 (work
              in progress), August 2017.

   [RFC3935]  Alvestrand, H., "A Mission Statement for the IETF",
              BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
              <https://www.rfc-editor.org/info/rfc3935>.





Nottingham               Expires March 26, 2018                 [Page 6]

Internet-Draft              Scoping Protocols             September 2017


   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013, <https://www.rfc-
              editor.org/info/rfc6973>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <https://www.rfc-editor.org/info/rfc7258>.

   [RFC7288]  Thaler, D., "Reflections on Host Firewalls", RFC 7288,
              DOI 10.17487/RFC7288, June 2014, <https://www.rfc-
              editor.org/info/rfc7288>.

   [RFC7624]  Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
              Trammell, B., Huitema, C., and D. Borkmann,
              "Confidentiality in the Face of Pervasive Surveillance: A
              Threat Model and Problem Statement", RFC 7624,
              DOI 10.17487/RFC7624, August 2015, <https://www.rfc-
              editor.org/info/rfc7624>.

   [RFC7754]  Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E.
              Nordmark, "Technical Considerations for Internet Service
              Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754,
              March 2016, <https://www.rfc-editor.org/info/rfc7754>.

Author's Address

   Mark Nottingham

   Email: mnot@mnot.net
   URI:   https://www.mnot.net/



















Nottingham               Expires March 26, 2018                 [Page 7]
