Rights for restricted content
draft-donnerhacke-linktax-00

Abstract

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 December 24, 2018.

Copyright Notice

Copyright (c) 2018 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
• 1.1. Background
• 1.2. Requirements Language
• 2. Referencing restricted content
• 2.1. The RIGHT element
• 2.2. Monetarization
• 2.3. Handling Digital Rights Management
• 3. Compensate transit providers
• 3.1. Routing Considerations
• 3.2. Option Format
• 3.3. Offering services
• 3.4. Accepting offers
• 4. Acknowledgements
• 5. IANA Considerations
• 6. Security Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Author's Address

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. In the Internet everybody provides its resources for the use by anybody else. This is the basic concept behind the hyperlink. For the purpose of this memo the concept is called "Left-Wing".

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. For the purpose of this memo the concept is called "Right-Wing".

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 monetarize their content, or to keep in line with open and free Internet by using the old mechanisms.

1.1. Background

The idea of a link tax is commonly attributed to the German publisher "Axel Springer". They 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.

Implementing this memo will satisfy all those "Right-Wing" claims:

• The new element is called "right" ("rechts" in German), so Internet is no longer a "Rechts-freier Raum".
• They can choose to monetarize 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 reverencing 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 customer.

Furthermore they can speed up their content delivery substantially by paying the transit and access providers for a higher level of service quality. This way the net neutrality of the "Left-Wing" needs not to be touched.

1.2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this memo are to be interpreted as described in RFC 2119.

2. Referencing restricted content

References to remote content are done by "links" in the "Left-Wing" universe. The only relevant environment for links for the purposes of this memo is the World Wide Web. There the "link" is represented by the <LINK> element or the <A> element.

2.1. The RIGHT element

The new <RIGHT> element is a modification of the existing <LINK> element. 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 MUST initiate the connection using the TCP options described in Section 3.

2.2. Monetarization

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

Any valid token MUST be copied to a new HTTP header line "Right: tax=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.

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.

2.3. Handling Digital Rights Management

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

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.

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.

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 involved 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 32bit ASN / Payload pairs.

 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).

ASN:

32bit value of the Autonomous System Number.

Payload:

A 32bit opaque value.

3.3. Offering services

In order request a resource according to Section 2.1, the clients opens a new TCP connection with the SYN flag set and the ACK flag cleared and adds 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" CAN be used. This means, that the carrier want to negotiate a contract. If those negotiation fails after a reasonable period of time, the carrier MAY drop such packets. In this case, it MUST respond with a appropriate, rate-limited ICMP error message.

If the carrier adds an offer to the list, it MUST 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.

3.4. Accepting offers

Any new connection containing this ASN option, MUST be signalled to the application level. Processing of the "tax" attribute as defined in Section 2.2 MUST 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 values.

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

The carrier has to route according to the stored flow context, but there are any problems, it SHOULD route toward the last ASN in the option.

4. Acknowledgements

This memo is influenced by the legislative process in the EU. Special thanks go to Julia Reda for keeping the public updated.

5. IANA Considerations

This memo adds an TCP ExID into the IANA registry <https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-exids> according the the rules of RFC 6994.

6. Security Considerations

7. References

7.1. Normative References

7.2. Informative References

Author's Address