[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04                                                
Internet Engineering Task Force                           L. Donnerhacke
Internet-Draft                                                Fitug e.V.
Intended status: Experimental                          September 6, 2019
Expires: March 9, 2020

                     Rights for restricted content


   Links are omnipresent in the Internet to provide access to other
   resources.  There is no mechanism to express differences in law
   systems, access limitations, or arbitrary rules defined by the owner
   of the linked resource.  Therefore links do depend on and enforce a
   communist sharing ideology, which ignores the content owner rights.

   Links may point to resources far away from the originating page,
   hiding this fact from the customer.  It takes the data transport
   services for free, internet transit providers on the way from the
   content source to the customers are not extra payed for this effort.
   In many cases, the remote company generates huge amount of money from
   the customers worldwide not shared with the transit providers.

   In order to get the rights of all involved parties balanced, a new
   type of connection initiation is proposed: The Right.

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 https://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 9, 2020.

Donnerhacke               Expires March 9, 2020                 [Page 1]

Internet-Draft        Rights for restricted content       September 2019

Copyright Notice

   Copyright (c) 2019 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
   (https://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.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.3.  Success conditions  . . . . . . . . . . . . . . . . . . .   4
   2.  Referencing restricted content  . . . . . . . . . . . . . . .   5
     2.1.  The RIGHT element . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Monetization  . . . . . . . . . . . . . . . . . . . . . .   5
       2.2.1.  Prepaid references  . . . . . . . . . . . . . . . . .   5
       2.2.2.  Pay per use . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Digital Rights Management . . . . . . . . . . . . . . . .   6
   3.  Compensate transit providers  . . . . . . . . . . . . . . . .   7
     3.1.  Routing Considerations  . . . . . . . . . . . . . . . . .   7
     3.2.  Option Format . . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  Offering services . . . . . . . . . . . . . . . . . . . .   8
     3.4.  Accepting offers  . . . . . . . . . . . . . . . . . . . .   9
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   The current Internet is best described by the famous quote "From each
   according to his ability, to each according to his needs" by Karl
   Marx [14].  In the Internet everybody provides its resources for the
   use by anybody else.  This is the basic concept behind the hyperlink.

Donnerhacke               Expires March 9, 2020                 [Page 2]

Internet-Draft        Rights for restricted content       September 2019

   On the other hand the concept of intellectual property requires to
   have a contractual relationship before use of the requested resource.
   In order to fulfil the needs of the intellectual property industry,
   additional elements needs to be implemented in the Internet.

   Using the mechanisms defined in this memo, content owners can decide
   the model of access to their property.  They are free to choose new
   mechanisms and monetize their content, or to keep in line with open
   and free Internet by using the already existing mechanisms.

   On the other hand Internet access providers seek for methods to
   participate on such monetization.  They want to offer higher level of
   service quality to specific content providers.  This memo allowes
   access providers to offer QoS for monetized content and get paid if
   the offer was accepted by the content provider.

1.1.  Background

   German publishers tries to establish a right on news and other
   aggregated information for more than one century [13].  The latest
   spin was to promote the idea of a link tax by the German publisher
   "Axel Springer".  They simply claim, that "Links" can't be free and
   that the Internet is a "Rechts-freier Raum" (lawless space).  To
   overcome this situation, they invented the "Leistungsschutzrecht",
   which in turn is the founding of the EU proposal [11].

   Implementing this memo will satisfy all those claims:

      They can choose to monetize their content by using the "right"
      instead of the "link" element.  If they are using "link", they
      agree to not sue anybody over the use of the resource.

      If they choose "right", they can limit the amount of usage of the
      reference.  This way the can obtain money from the referencing
      page (i.e. a news aggregator).

      If they choose "right", they even can limit the usage of the
      content itself.  They can prevent i.e. printing or sharing by the

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   memo are to be interpreted as described in RFC 2119 [10].

Donnerhacke               Expires March 9, 2020                 [Page 3]

Internet-Draft        Rights for restricted content       September 2019

1.3.  Success conditions

   This memo specifies an experiment.  It tries to make a political
   offer to those parties, which constantly want to change the Internet
   in favor of their own needs.  By defining a technical solution for
   the announced problems, the political decision process has another
   alternative to accepting or denying the requested laws.  This memo
   allows to acknowledge the needs of the interested parties without
   harming the existing Internet.

   Now the political decision process has to choose one from the
   following possibilities:

      Denying the requests completely,

      Allowing the requests and point them to this memo for

      or to actively changing the existing Internet in order to fulfil
      the requests.

   In order to be successful, this memo needs to match the following
   technical criteria:

      An implementation of the RIGHT tag must exist for popular
      browsers.  For now it's sufficient to be implemented by plugins.

      At the minimal level users must be able to click on RIGHT
      references. get a dialog about the licence issues and can select
      to follow the the reference or not.

      Futheremore there should be an implementation of the TCP flag
      operations on client side for at least one operating system.  This
      implementation should be able to set a socket option TCP_ASN,
      which sets the tcp header option accordingly.

      There should be an implementation of the TCP flag option on the
      server side for at least one operating system.  This
      implementation should be able to get a socket option TCP_ACK,
      which reads the received tcp header option for an accepted TCP

      Initially all ASN offers could be either accepted or rejected at
      the server side.

   Given this list of preconditions, the server side processing of
   RIGHTs is only a subject of local application progamming.

Donnerhacke               Expires March 9, 2020                 [Page 4]

Internet-Draft        Rights for restricted content       September 2019

2.  Referencing restricted content

   References to remote content are currently done using "links".  The
   only relevant environment for the purposes of this memo is the World
   Wide Web. There the "link" is represented by the <LINK> element [8]
   or the <A> element [9].

2.1.  The RIGHT element

   The new <RIGHT> element is a modification of the existing <LINK>
   element [8].  It differs from the former by the retrieval method used
   by the client browser, and two additional attributes.

   When accessing the referenced resource of the RIGHT element, the
   browser SHOULD initiate the connection using the TCP options
   described in Section 3.

2.2.  Monetization

   Wenn referencing a resource one of the following monetization methods
   MUST be used.  The methods are mutually exclusive.

2.2.1.  Prepaid references

   The RIGHT element MAY have an attribute named "prepaid", which
   contains an opaque token.  The token SHOULD be a Base64 string [4].
   The attribute MUST not processed, if the token does exceed the Base64
   charset.  It MAY even check, if the token is really a Base64

   Any valid token MUST be copied to a new HTTP header line "Right:
   prepaid=token" when requesting the referenced resource.  If the
   attribute does not exist or is invalid, the line SHOULD be omitted.

   The resource provider MAY use this token to validate, that the
   resource was legally requested.  If the token is invalid, it MAY
   respond with the error code 402.  It MUST NOT respond with error code
   451 [7].

   The resource provider MUST provide an API, where new tokens can be
   obtained.  Access to the API SHOULD be limited to paying contractors
   and SHOULD offer tokens which are valid for a larger amount of
   requests and MAY time out.

   This is the prefered method for link aggregators and search engines,
   which make money from referencing third party content.  It can also
   be used, if the referencing page owner want to avoid payment hussle
   for the customer.

Donnerhacke               Expires March 9, 2020                 [Page 5]

Internet-Draft        Rights for restricted content       September 2019

2.2.2.  Pay per use

   The RIGHT element MAY have a couple of attributes, which instruct the
   browser to process the necessary payment before accessing the

   The attribute "payment" contains a URI [2] denoting the clearing
   point for the transaction and the destination of the payment.  This
   memo does not define any methods, but it might look like
   "microico:123456..def" or "https://micro.pay.me.example/@company/
   AxelS".  The payment API MUST return a proof of payment (PoP) value
   on success.  The PoP value MUST NOT exceed the Base64 charset [4].

   The attribute "currency" contains a string to be used by the payment
   API.  It SHOULD donate a well defined abbreviation for the currency.

   The attribute "view" contains a numerical value.  The browser MUST
   NOT render the RIGHT element, without successfully paying the denoted
   amount of currency via the payment API.  It SHOULD cache this result
   for later use to avoid multiple spendings for the same content.

   The attribute "click" contains a numerical value.  The browser MUST
   add the a header line "Right: click=PoP" when requesting the
   referenced resource.  The PoP is the proof of payment value from
   payment of the denoted amount of currency.  The resource provider MAY
   use this value to validate, that the resource was payed.  If the
   token is invalid, it MAY respond with the error code 402.  It MUST
   NOT respond with error code 451 [7].

   At least one of the attributes "view" or "click", as well as the
   attributes "payment" and "currency" MUST be present for this method.

   This is the prefered method for referencing restricted content from
   pages providing own content.

2.3.  Digital Rights Management

   The RIGHT element MAY have an attribute named "drm", which contains
   an opaque token.  The token SHOULD be a Base64 string [4].  The
   attribute MUST NOT processed, if the token exceeds the Base64
   charset.  It MAY even check, that the token is really a Base64

   Any valid token MUST be handed over to the local DRM software used to
   process the content of the resource.  The details of the API and the
   processing inside the DRM software is out of the scope of this memo.

Donnerhacke               Expires March 9, 2020                 [Page 6]

Internet-Draft        Rights for restricted content       September 2019

3.  Compensate transit providers

3.1.  Routing Considerations

   Traffic from the resource provider to the client (and back) travels
   through the Internet by passing from one internet carrier to the next
   one until it reaches the destination.  The internet carriers are
   interconnected by each other through dedicated peerings.  At such a
   peering, the networks of the carriers talk directly to each other.
   The network of a carrier itself are summarized by an Autonomous
   System Number [3].

   There is no guarantee, that the packets travel the same way all the
   time.  Traffic in one direction may touch completely different
   providers, than on the way back.  The traffic can be rerouted if
   necessary, even if the TCP session is still up.  So it is difficult
   to compensate the intermediate carriers, simply because they may
   change at any time.

3.2.  Option Format

   In order to track the route of carriers involved, a new TCP option is
   defined.  It contains an arbitrary amount of 32 bit ASN / Payload

    0          1          2          3
    01234567 89012345 67890123 45678901
   |  Kind  | Length |       ExID      |
   |  ASN-1                            |
   |  Payload-1                        |
   |  ASN-n                            |
   |  Payload-n                        |

              Figure 1: Autonomous System Compensation Option

   Kind:     The option kind value is 253.

   Length:   The length of the option is variable, based on the required
             size of the content.  The size will be a multiple of 4.

   ExID:     The experiment ID value is 0x0a0d (2573).

Donnerhacke               Expires March 9, 2020                 [Page 7]

Internet-Draft        Rights for restricted content       September 2019

   ASN:      32 bit value of the Autonomous System Number.

   Payload:  A 32 bit opaque value.

   The option space in the TCP header is limited to eleven 32 bit words
   [1].  So no more than five ASN / Payload pairs can be included.  The
   number might be lower, if other TCP options are present.

   The option is defined to exist only in packets with the SYN flag set.
   It SHOULD NOT occur in data only packets, hence the MSS is not
   changed.  For TCP fast open [6], the size of the initial segment
   needs to be adjusted.

3.3.  Offering services

   In order request a resource according to Section 2.1, the client
   opens a new TCP connection with the SYN flag set and the ACK flag
   cleared [1] and SHOULD add an empty ASN option as defined in
   Section 3.2.

   Any ASN MAY offer a special service to the content provider by
   appending its own ASN to the end.  The payload contains a
   contractually defined value, i.e. a challenge with nonce bits, which
   will be processed by the content provider.  The list of offers MUST
   NOT be deleted or reordered.

   If there is no contract between the carrier and the content provider,
   the special payload "0" MAY be used.  This means, that the carrier
   want to negotiate a contract.  If this negotiation fails after a
   reasonable period of time, the carrier SHOULD pass the packets

   A carrier MUST NOT add an offer to the list, if it can not guarantee,
   that all packets of the flow will run through its infrastructure.
   Normally only the Internet access provider is able to do so.  Transit
   providers need to take extra actions to bypass the normal Internet
   routing, before adding an offer.  Adding an offer includes the
   promise to keep the routing decision stable and always route the
   following packets of this flow to the same ASN as the initial packet.
   Furthermore it MUST route all the response packets of this flow to
   the ASN which was last one in the list.

   If the option space is full, the carrier MUST NOT add an offer to the
   list.  This way the access providers have a first opportunity to
   place an offer, fulfilling their request to compensate the broadband
   access costs.

Donnerhacke               Expires March 9, 2020                 [Page 8]

Internet-Draft        Rights for restricted content       September 2019

3.4.  Accepting offers

   Any new connection containing this ASN option, SHOULD be signalled to
   the application level.  Processing of any of the payment headers as
   defined in Section 2.2 SHOULD be suppressed unless the application
   got this signal.  This way normal "links" are processed as usual,
   while "rights" can be handled correctly.

   On receiving the initial packet at the final destination, the option
   values are examined.  For each offer the payload MUST be replaced by
   the contractually defined, computed response.  The list MUST NOT be
   reordered.  If an offer is rejected, the payload is set to "0".  So
   the TCP syn/ack packet contains a ASN option with all the acceptance

   On the way back each ASN, which put in an offer, MUST examine the
   option, and MUST remove the last item from the list, if AS number
   matches.  Depending on the response to the offer, the TCP flow SHOULD
   be handled accordingly to the contractual requirements.

   Finally the carrier SHOULD route toward the next ASN in the option.

4.  Acknowledgements

   This memo is influenced by the legislative process in the EU [11].
   Special thanks go to Julia Reda [12] for keeping the public updated.
   The basic idea was contributed by Bernd Paysan.  Very valuable input
   came from many discussions over the IETF lists.

5.  IANA Considerations

   This memo adds an TCP ExID into the IANA registry
   parameters.xhtml#tcp-exids> according the the rules of RFC 6994 [5].

                | Value  | Description                    |
                | 0x0a0d | Autonomous System Compensation |

6.  Security Considerations

   Filtering the TCP option on intermediate devices might render the
   resource in question unreachable.

Donnerhacke               Expires March 9, 2020                 [Page 9]

Internet-Draft        Rights for restricted content       September 2019

   The TCP option is designed to implement a challenge response
   mechanism, which should withstand a MITM attack.  All details of such
   a mechanism are out of the scope of this memo.

   Attribute values might be copied from a document and reused
   elsewhere.  This might result in theft of access rights and should be
   prevented by appropriate actions (i.e. checking Referer, Cookies).

7.  References

7.1.  Normative References

   [1]        Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,

   [2]        Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,

   [3]        Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,

   [4]        Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,

   [5]        Touch, J., "Shared Use of Experimental TCP Options",
              RFC 6994, DOI 10.17487/RFC6994, August 2013,

   [6]        Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
              Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,

   [7]        Bray, T., "An HTTP Status Code to Report Legal Obstacles",
              RFC 7725, DOI 10.17487/RFC7725, February 2016,

   [8]        World Wide Web Consortium, "The link element", 2018,

Donnerhacke               Expires March 9, 2020                [Page 10]

Internet-Draft        Rights for restricted content       September 2019

   [9]        World Wide Web Consortium, "The a element", 2018,

7.2.  Informative References

   [10]       Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [11]       EUROPEAN COMMISSION, "Proposal for a DIRECTIVE OF THE
              EUROPEAN PARLIAMENT AND OF THE COUNCIL on copyright in the
              Digital Single Market", 2016, <https://eur-lex.europa.eu/

   [12]       Reda, J., "Homepage", <https://juliareda.eu/>.

   [13]       Helgadottir, A., "German press track record",

   [14]       Marx, K., "Kritik des Gothaer Programms", 1875.

Author's Address

   Lutz Donnerhacke
   Fitug e.V.
   Leutragraben 1
   Jena  07743

   Phone: +49 3641 573561
   Email: lutz@fitug.de

Donnerhacke               Expires March 9, 2020                [Page 11]