idnits 2.17.1
draft-donnerhacke-linktax-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 :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords -- however, there's a paragraph with
a matching beginning. Boilerplate error?
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
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 encoding.
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
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 does exceed the Base64 charset. It MAY
even check, if the token is really a Base64 encoding.
-- The document date (June 27, 2018) is 2129 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 793 (ref. '1') (Obsoleted by RFC 9293)
Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force L. Donnerhacke
3 Internet-Draft Fitug e.V.
4 Intended status: Experimental June 27, 2018
5 Expires: December 29, 2018
7 Rights for restricted content
8 draft-donnerhacke-linktax-01
10 Abstract
12 Links are omnipresent in the Internet to provide access to other
13 resources. There is no mechanism to express differences in law
14 systems, access limitations, or arbitrary rules defined by the owner
15 of the linked resource. Therefore links do depend on and enforce a
16 communist sharing ideology, which ignores the content owner rights.
18 Links may point to resources far away from the originating page,
19 hiding this fact from the customer. It takes the data transport
20 services for free, internet transit providers on the way from the
21 content source to the customers are not extra payed for this effort.
22 In many cases, the remote company generates huge amount of money from
23 the customers worldwide not shared with the transit providers.
25 In order to get the rights of all involved parties balanced, a new
26 type of connection initiation is proposed: The Right.
28 Status of This Memo
30 This Internet-Draft is submitted in full conformance with the
31 provisions of BCP 78 and BCP 79.
33 Internet-Drafts are working documents of the Internet Engineering
34 Task Force (IETF). Note that other groups may also distribute
35 working documents as Internet-Drafts. The list of current Internet-
36 Drafts is at https://datatracker.ietf.org/drafts/current/.
38 Internet-Drafts are draft documents valid for a maximum of six months
39 and may be updated, replaced, or obsoleted by other documents at any
40 time. It is inappropriate to use Internet-Drafts as reference
41 material or to cite them other than as "work in progress."
43 This Internet-Draft will expire on December 29, 2018.
45 Copyright Notice
47 Copyright (c) 2018 IETF Trust and the persons identified as the
48 document authors. All rights reserved.
50 This document is subject to BCP 78 and the IETF Trust's Legal
51 Provisions Relating to IETF Documents
52 (https://trustee.ietf.org/license-info) in effect on the date of
53 publication of this document. Please review these documents
54 carefully, as they describe your rights and restrictions with respect
55 to this document. Code Components extracted from this document must
56 include Simplified BSD License text as described in Section 4.e of
57 the Trust Legal Provisions and are provided without warranty as
58 described in the Simplified BSD License.
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
63 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
64 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
65 2. Referencing restricted content . . . . . . . . . . . . . . . 4
66 2.1. The RIGHT element . . . . . . . . . . . . . . . . . . . . 4
67 2.2. Monetization . . . . . . . . . . . . . . . . . . . . . . 4
68 2.2.1. Prepaid references . . . . . . . . . . . . . . . . . 4
69 2.2.2. Pay per use . . . . . . . . . . . . . . . . . . . . . 5
70 2.3. Digital Rights Management . . . . . . . . . . . . . . . . 5
71 3. Compensate transit providers . . . . . . . . . . . . . . . . 6
72 3.1. Routing Considerations . . . . . . . . . . . . . . . . . 6
73 3.2. Option Format . . . . . . . . . . . . . . . . . . . . . . 6
74 3.3. Offering services . . . . . . . . . . . . . . . . . . . . 7
75 3.4. Accepting offers . . . . . . . . . . . . . . . . . . . . 8
76 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
80 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
81 7.2. Informative References . . . . . . . . . . . . . . . . . 10
82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
84 1. Introduction
86 The current Internet is best described by the famous quote "From each
87 according to his ability, to each according to his needs" by Karl
88 Marx [13]. In the Internet everybody provides its resources for the
89 use by anybody else. This is the basic concept behind the hyperlink.
90 For the purpose of this memo the concept is called "Left-Wing".
92 On the other hand the concept of intellectual property requires to
93 have a contractual relationship before use of the requested resource.
94 In order to fulfil the needs of the intellectual property industry,
95 additional elements needs to be implemented in the Internet. For the
96 purpose of this memo the concept is called "Right-Wing".
98 Using the mechanisms defined in this memo, content owners can decide
99 the model of access to their property. They are free to choose new
100 mechanisms and monetize their content, or to keep in line with open
101 and free Internet by using the old mechanisms.
103 1.1. Background
105 The idea of a link tax is commonly attributed to the German publisher
106 "Axel Springer". They claim that "Links" can't be free and that the
107 Internet is a "Rechts-freier Raum" (lawless space). To overcome this
108 situation, they invented the "Leistungsschutzrecht", which in turn is
109 the founding of the EU proposal [11].
111 Implementing this memo will satisfy all those "Right-Wing" claims:
113 The new element is called "right" ("rechts" in German), so
114 Internet is no longer a "Rechts-freier Raum".
116 They can choose to monetize their content by using the "right"
117 instead of the "link" element. If they are using "link", they
118 agree to not sue anybody over the use of the resource.
120 If they choose "right", they can limit the amount of usage of the
121 reference. This way the can obtain money from the reverencing
122 page (i.e. a news aggregator).
124 If they choose "right", they even can limit the usage of the
125 content itself. They can prevent i.e. printing or sharing by the
126 customer.
128 Furthermore they can speed up their content delivery substantially by
129 paying the transit and access providers for a higher level of service
130 quality. This way the net neutrality of the "Left-Wing" needs not to
131 be touched.
133 1.2. Requirements Language
135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
137 memo are to be interpreted as described in RFC 2119 [10].
139 2. Referencing restricted content
141 References to remote content are done by "links" in the "Left-Wing"
142 universe. The only relevant environment for links for the purposes
143 of this memo is the World Wide Web. There the "link" is represented
144 by the element [8] or the element [9].
146 2.1. The RIGHT element
148 The new element is a modification of the existing
149 element [8]. It differs from the former by the retrieval method used
150 by the client browser, and two additional attributes.
152 When accessing the referenced resource of the RIGHT element, the
153 browser MUST initiate the connection using the TCP options described
154 in Section 3.
156 2.2. Monetization
158 Wenn referencing a resource one of the following monetization methods
159 MUST be used. The methods are mutually exclusive.
161 2.2.1. Prepaid references
163 The RIGHT element MAY have an attribute named "prepaid", which
164 contains an opaque token. The token SHOULD be a Base64 string [4].
165 The attribute MUST not processed, if the token does exceed the Base64
166 charset. It MAY even check, if the token is really a Base64
167 encoding.
169 Any valid token MUST be copied to a new HTTP header line "Right:
170 prepaid=token" when requesting the referenced resource. If the
171 attribute does not exist or is invalid, the line SHOULD be omitted.
173 The resource provider MAY use this token to validate, that the
174 resource was legally requested. If the token is invalid, it MAY
175 respond with the error code 402. It MUST NOT respond with error code
176 451 [7].
178 The resource provider MUST provide an API, where new tokens can be
179 obtained. Access to the API SHOULD be limited to paying contractors
180 and SHOULD offer tokens which are valid for a larger amount of
181 requests and MAY time out.
183 This is the prefered method for link aggregators and search engines,
184 which make money from referencing third party content. It can also
185 be used, if the referencing page owner want to avoid payment hussle
186 for the customer.
188 2.2.2. Pay per use
190 The RIGHT element MAY have a couple of attributes, which instruct the
191 browser to process the necessary payment before accessing the
192 resource.
194 The attribute "payment" contains a URI [2] denoting the clearing
195 point for the transaction and the destination of the payment. This
196 memo does not define any methods, but an it might look like
197 "microico:123456..def" or "https://micro.pay.me.example/@company/
198 AxelSpringer". The payment API MUST return a proof of payment (PoP)
199 value on success. The PoP value MUST NOT exceed the Base64 charset
200 [4].
202 The attribute "currency" contains a string to be used by the payment
203 API. It SHOULD donate a well defined abbreviation for the currency.
205 The attribute "view" contains a numerical value. The browser MUST
206 NOT render the RIGHT element, without successfully paying the denoted
207 amount of currency via the payment API. It MIGHT cache this result
208 for later use to avoid multiple spendings for the same content.
210 The attribute "click" contains a numerical value. The browser MUST
211 add the a header line "Right: click=PoP" when requesting the
212 referenced resource. The PoP is the proof of payment value from
213 payment of the denoted amount of currency. The resource provider MAY
214 use this value to validate, that the resource was payed. If the
215 token is invalid, it MAY respond with the error code 402. It MUST
216 NOT respond with error code 451 [7].
218 At least one of the attributes "view" or "click", as well as the
219 attributes "payment" and "currency" MUST be present for this method.
221 This is the prefered method for referencing restricted content from
222 pages providing own content.
224 2.3. Digital Rights Management
226 The RIGHT element MAY have an attribute named "drm", which contains
227 an opaque token. The token SHOULD be a Base64 string [4]. The
228 attribute MUST not processed, if the token does exceed the Base64
229 charset. It MAY even check, if the token is really a Base64
230 encoding.
232 Any valid token MUST be handed over to the local DRM software used to
233 process the content of the resource. The details of the API and the
234 processing inside the DRM software is out of the scope of this memo.
236 3. Compensate transit providers
238 3.1. Routing Considerations
240 Traffic from the resource provider to the client (and back) travels
241 through the Internet by passing from one internet carrier to the next
242 one until it reaches the destination. The internet carriers are
243 interconnected by each other through dedicated peerings. At such a
244 peering, the networks of the carriers talk directly to each other.
245 The network of a carrier itself are summarized by an Autonomous
246 System Number [3].
248 There is no guarantee, that the packets travel the same way all the
249 time. Traffic in one direction may touch completely different
250 providers, than on the way back. The traffic can be rerouted if
251 necessary, even if the TCP session is still up. So it is difficult
252 to compensate the involved carriers, simply because they may change
253 at any time.
255 3.2. Option Format
257 In order to track the route of carriers involved, a new TCP option is
258 defined. It contains an arbitrary amount of 32 bit ASN / Payload
259 pairs.
261 0 1 2 3
262 01234567 89012345 67890123 45678901
263 +--------+--------+--------+--------+
264 | Kind | Length | ExID |
265 +--------+--------+--------+--------+
266 | ASN-1 |
267 +--------+--------+--------+--------+
268 | Payload-1 |
269 +--------+--------+--------+--------+
270 ...
271 | ASN-n |
272 +--------+--------+--------+--------+
273 | Payload-n |
274 +--------+--------+--------+--------+
276 Figure 1: Autonomous System Compensation Option
278 Kind: The option kind value is 253.
280 Length: The length of the option is variable, based on the required
281 size of the content. The size will be a multiple of 4.
283 ExID: The experiment ID value is 0x0a0d (2573).
285 ASN: 32 bit value of the Autonomous System Number.
287 Payload: A 32 bit opaque value.
289 The option space in the TCP header is limited to eleven 32 bit words
290 [1]. So no more than five ASN / Payload pairs can be included. The
291 number might be lower, if other TCP options are present.
293 The option is defined to exist only in packets with the SYN flag set.
294 It SHOULD NOT occur in data only packets, hence the MSS is not
295 changed. For TCP fast open [6], the size of the initial segment
296 needs to be adjusted.
298 3.3. Offering services
300 In order request a resource according to Section 2.1, the client
301 opens a new TCP connection with the SYN flag set and the ACK flag
302 cleared [1] and MUST add an empty ASN option as defined in
303 Section 3.2.
305 Any ASN MAY offer a special service to the content provider by
306 appending its own ASN to the end. The payload contains a
307 contractually defined value, i.e. a challenge with nonce bits, which
308 will be processed by the content provider. The list of offers MUST
309 NOT be deleted or reordered.
311 If there is no contract between the carrier and the content provider,
312 the special payload "0" CAN be used. This means, that the carrier
313 want to negotiate a contract. If those negotiation fails after a
314 reasonable period of time, the carrier MAY drop such packets. In
315 this case, it MUST respond with a appropriate, rate-limited ICMP
316 error message.
318 If the carrier adds an offer to the list, it MUST keep the routing
319 decision stable and always route the following packets of this flow
320 to the same ASN as the initial packet. Furthermore it MUST route all
321 the response packets of this flow to the ASN which was last one in
322 the list.
324 If the option space is full, the carrier MUST NOT add an offer to the
325 list. This way the access providers have a first opportunity to
326 place an offer, fulfilling their request to compensate the broadband
327 access costs.
329 3.4. Accepting offers
331 Any new connection containing this ASN option, MUST be signalled to
332 the application level. Processing of any of the payment headers as
333 defined in Section 2.2 MUST be suppressed unless the application got
334 this signal. This way normal "links" are processed as usual, while
335 "rights" can be handled correctly.
337 On receiving the initial packet at the final destination, the option
338 values are examined. For each OFFER the payload MUST be replaced by
339 the contractually defined, computed response. The list MUST NOT be
340 reordered. If an offer is rejected, the payload is set to "0". So
341 the TCP syn/ack packet contains a ASN option with all the acceptance
342 values.
344 On the way back each ASN, which put in an offer, examines the option,
345 it MUST remove the last item from the ASN option list, if AS number
346 matches. Depending on the response to the offer, the TCP flow SHOULD
347 be handled accordingly to the contractual requirements.
349 The carrier has to route according to the stored flow context, but
350 there are any problems, it SHOULD route toward the last ASN in the
351 option.
353 4. Acknowledgements
355 This memo is influenced by the legislative process in the EU [11].
356 Special thanks go to Julia Reda [12] for keeping the public updated.
357 The basic idea was contributed by Bernd Paysan.
359 5. IANA Considerations
361 This memo adds an TCP ExID into the IANA registry
362 according the the rules of RFC 6994 [5].
365 +--------+--------------------------------+
366 | Value | Description |
367 +--------+--------------------------------+
368 | 0x0a0d | Autonomous System Compensation |
369 +--------+--------------------------------+
371 6. Security Considerations
373 Filtering the TCP option on intermediate devices might render the
374 resource in question unreachable.
376 The TCP option is designed to implement a challenge response
377 mechanism, which should withstand a MITM attack. All details of such
378 a mechanism are out of the scope of this memo.
380 Attribute values might be copied from a document and reused
381 elsewhere. This might result in theft of access rights and should be
382 prevented by appropriate actions (i.e. checking Referer, Cookies).
384 7. References
386 7.1. Normative References
388 [1] Postel, J., "Transmission Control Protocol", STD 7,
389 RFC 793, DOI 10.17487/RFC0793, September 1981,
390 .
392 [2] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
393 Resource Identifier (URI): Generic Syntax", STD 66,
394 RFC 3986, DOI 10.17487/RFC3986, January 2005,
395 .
397 [3] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
398 Border Gateway Protocol 4 (BGP-4)", RFC 4271,
399 DOI 10.17487/RFC4271, January 2006,
400 .
402 [4] Josefsson, S., "The Base16, Base32, and Base64 Data
403 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
404 .
406 [5] Touch, J., "Shared Use of Experimental TCP Options",
407 RFC 6994, DOI 10.17487/RFC6994, August 2013,
408 .
410 [6] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
411 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
412 .
414 [7] Bray, T., "An HTTP Status Code to Report Legal Obstacles",
415 RFC 7725, DOI 10.17487/RFC7725, February 2016,
416 .
418 [8] World Wide Web Consortium, "The link element", 2018,
419 .
422 [9] World Wide Web Consortium, "The a element", 2018,
423 .
426 7.2. Informative References
428 [10] Bradner, S., "Key words for use in RFCs to Indicate
429 Requirement Levels", BCP 14, RFC 2119,
430 DOI 10.17487/RFC2119, March 1997,
431 .
433 [11] EUROPEAN COMMISSION, "Proposal for a DIRECTIVE OF THE
434 EUROPEAN PARLIAMENT AND OF THE COUNCIL on copyright in the
435 Digital Single Market", 2016, .
438 [12] Reda, J., "Homepage", .
440 [13] Marx, K., "Kritik des Gothaer Programms", 1875.
442 Author's Address
444 Lutz Donnerhacke
445 Fitug e.V.
446 Leutragraben 1
447 Jena 07743
448 DE
450 Phone: +49 3641 573561
451 Email: lutz@fitug.de