idnits 2.17.1
draft-donnerhacke-linktax-04.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.
-- The document date (September 6, 2019) is 1695 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 (~~), 3 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 September 6, 2019
5 Expires: March 9, 2020
7 Rights for restricted content
8 draft-donnerhacke-linktax-04
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 March 9, 2020.
45 Copyright Notice
47 Copyright (c) 2019 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 1.3. Success conditions . . . . . . . . . . . . . . . . . . . 4
66 2. Referencing restricted content . . . . . . . . . . . . . . . 5
67 2.1. The RIGHT element . . . . . . . . . . . . . . . . . . . . 5
68 2.2. Monetization . . . . . . . . . . . . . . . . . . . . . . 5
69 2.2.1. Prepaid references . . . . . . . . . . . . . . . . . 5
70 2.2.2. Pay per use . . . . . . . . . . . . . . . . . . . . . 6
71 2.3. Digital Rights Management . . . . . . . . . . . . . . . . 6
72 3. Compensate transit providers . . . . . . . . . . . . . . . . 7
73 3.1. Routing Considerations . . . . . . . . . . . . . . . . . 7
74 3.2. Option Format . . . . . . . . . . . . . . . . . . . . . . 7
75 3.3. Offering services . . . . . . . . . . . . . . . . . . . . 8
76 3.4. Accepting offers . . . . . . . . . . . . . . . . . . . . 9
77 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
81 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
82 7.2. Informative References . . . . . . . . . . . . . . . . . 11
83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
85 1. Introduction
87 The current Internet is best described by the famous quote "From each
88 according to his ability, to each according to his needs" by Karl
89 Marx [14]. In the Internet everybody provides its resources for the
90 use by anybody else. This is the basic concept behind the hyperlink.
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.
97 Using the mechanisms defined in this memo, content owners can decide
98 the model of access to their property. They are free to choose new
99 mechanisms and monetize their content, or to keep in line with open
100 and free Internet by using the already existing mechanisms.
102 On the other hand Internet access providers seek for methods to
103 participate on such monetization. They want to offer higher level of
104 service quality to specific content providers. This memo allowes
105 access providers to offer QoS for monetized content and get paid if
106 the offer was accepted by the content provider.
108 1.1. Background
110 German publishers tries to establish a right on news and other
111 aggregated information for more than one century [13]. The latest
112 spin was to promote the idea of a link tax by the German publisher
113 "Axel Springer". They simply claim, that "Links" can't be free and
114 that the Internet is a "Rechts-freier Raum" (lawless space). To
115 overcome this situation, they invented the "Leistungsschutzrecht",
116 which in turn is the founding of the EU proposal [11].
118 Implementing this memo will satisfy all those claims:
120 They can choose to monetize their content by using the "right"
121 instead of the "link" element. If they are using "link", they
122 agree to not sue anybody over the use of the resource.
124 If they choose "right", they can limit the amount of usage of the
125 reference. This way the can obtain money from the referencing
126 page (i.e. a news aggregator).
128 If they choose "right", they even can limit the usage of the
129 content itself. They can prevent i.e. printing or sharing by the
130 customer.
132 1.2. Requirements Language
134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
136 memo are to be interpreted as described in RFC 2119 [10].
138 1.3. Success conditions
140 This memo specifies an experiment. It tries to make a political
141 offer to those parties, which constantly want to change the Internet
142 in favor of their own needs. By defining a technical solution for
143 the announced problems, the political decision process has another
144 alternative to accepting or denying the requested laws. This memo
145 allows to acknowledge the needs of the interested parties without
146 harming the existing Internet.
148 Now the political decision process has to choose one from the
149 following possibilities:
151 Denying the requests completely,
153 Allowing the requests and point them to this memo for
154 implementation,
156 or to actively changing the existing Internet in order to fulfil
157 the requests.
159 In order to be successful, this memo needs to match the following
160 technical criteria:
162 An implementation of the RIGHT tag must exist for popular
163 browsers. For now it's sufficient to be implemented by plugins.
165 At the minimal level users must be able to click on RIGHT
166 references. get a dialog about the licence issues and can select
167 to follow the the reference or not.
169 Futheremore there should be an implementation of the TCP flag
170 operations on client side for at least one operating system. This
171 implementation should be able to set a socket option TCP_ASN,
172 which sets the tcp header option accordingly.
174 There should be an implementation of the TCP flag option on the
175 server side for at least one operating system. This
176 implementation should be able to get a socket option TCP_ACK,
177 which reads the received tcp header option for an accepted TCP
178 session.
180 Initially all ASN offers could be either accepted or rejected at
181 the server side.
183 Given this list of preconditions, the server side processing of
184 RIGHTs is only a subject of local application progamming.
186 2. Referencing restricted content
188 References to remote content are currently done using "links". The
189 only relevant environment for the purposes of this memo is the World
190 Wide Web. There the "link" is represented by the element [8]
191 or the element [9].
193 2.1. The RIGHT element
195 The new element is a modification of the existing
196 element [8]. It differs from the former by the retrieval method used
197 by the client browser, and two additional attributes.
199 When accessing the referenced resource of the RIGHT element, the
200 browser SHOULD initiate the connection using the TCP options
201 described in Section 3.
203 2.2. Monetization
205 Wenn referencing a resource one of the following monetization methods
206 MUST be used. The methods are mutually exclusive.
208 2.2.1. Prepaid references
210 The RIGHT element MAY have an attribute named "prepaid", which
211 contains an opaque token. The token SHOULD be a Base64 string [4].
212 The attribute MUST not processed, if the token does exceed the Base64
213 charset. It MAY even check, if the token is really a Base64
214 encoding.
216 Any valid token MUST be copied to a new HTTP header line "Right:
217 prepaid=token" when requesting the referenced resource. If the
218 attribute does not exist or is invalid, the line SHOULD be omitted.
220 The resource provider MAY use this token to validate, that the
221 resource was legally requested. If the token is invalid, it MAY
222 respond with the error code 402. It MUST NOT respond with error code
223 451 [7].
225 The resource provider MUST provide an API, where new tokens can be
226 obtained. Access to the API SHOULD be limited to paying contractors
227 and SHOULD offer tokens which are valid for a larger amount of
228 requests and MAY time out.
230 This is the prefered method for link aggregators and search engines,
231 which make money from referencing third party content. It can also
232 be used, if the referencing page owner want to avoid payment hussle
233 for the customer.
235 2.2.2. Pay per use
237 The RIGHT element MAY have a couple of attributes, which instruct the
238 browser to process the necessary payment before accessing the
239 resource.
241 The attribute "payment" contains a URI [2] denoting the clearing
242 point for the transaction and the destination of the payment. This
243 memo does not define any methods, but it might look like
244 "microico:123456..def" or "https://micro.pay.me.example/@company/
245 AxelS". The payment API MUST return a proof of payment (PoP) value
246 on success. The PoP value MUST NOT exceed the Base64 charset [4].
248 The attribute "currency" contains a string to be used by the payment
249 API. It SHOULD donate a well defined abbreviation for the currency.
251 The attribute "view" contains a numerical value. The browser MUST
252 NOT render the RIGHT element, without successfully paying the denoted
253 amount of currency via the payment API. It SHOULD cache this result
254 for later use to avoid multiple spendings for the same content.
256 The attribute "click" contains a numerical value. The browser MUST
257 add the a header line "Right: click=PoP" when requesting the
258 referenced resource. The PoP is the proof of payment value from
259 payment of the denoted amount of currency. The resource provider MAY
260 use this value to validate, that the resource was payed. If the
261 token is invalid, it MAY respond with the error code 402. It MUST
262 NOT respond with error code 451 [7].
264 At least one of the attributes "view" or "click", as well as the
265 attributes "payment" and "currency" MUST be present for this method.
267 This is the prefered method for referencing restricted content from
268 pages providing own content.
270 2.3. Digital Rights Management
272 The RIGHT element MAY have an attribute named "drm", which contains
273 an opaque token. The token SHOULD be a Base64 string [4]. The
274 attribute MUST NOT processed, if the token exceeds the Base64
275 charset. It MAY even check, that the token is really a Base64
276 encoding.
278 Any valid token MUST be handed over to the local DRM software used to
279 process the content of the resource. The details of the API and the
280 processing inside the DRM software is out of the scope of this memo.
282 3. Compensate transit providers
284 3.1. Routing Considerations
286 Traffic from the resource provider to the client (and back) travels
287 through the Internet by passing from one internet carrier to the next
288 one until it reaches the destination. The internet carriers are
289 interconnected by each other through dedicated peerings. At such a
290 peering, the networks of the carriers talk directly to each other.
291 The network of a carrier itself are summarized by an Autonomous
292 System Number [3].
294 There is no guarantee, that the packets travel the same way all the
295 time. Traffic in one direction may touch completely different
296 providers, than on the way back. The traffic can be rerouted if
297 necessary, even if the TCP session is still up. So it is difficult
298 to compensate the intermediate carriers, simply because they may
299 change at any time.
301 3.2. Option Format
303 In order to track the route of carriers involved, a new TCP option is
304 defined. It contains an arbitrary amount of 32 bit ASN / Payload
305 pairs.
307 0 1 2 3
308 01234567 89012345 67890123 45678901
309 +--------+--------+--------+--------+
310 | Kind | Length | ExID |
311 +--------+--------+--------+--------+
312 | ASN-1 |
313 +--------+--------+--------+--------+
314 | Payload-1 |
315 +--------+--------+--------+--------+
316 ...
317 | ASN-n |
318 +--------+--------+--------+--------+
319 | Payload-n |
320 +--------+--------+--------+--------+
322 Figure 1: Autonomous System Compensation Option
324 Kind: The option kind value is 253.
326 Length: The length of the option is variable, based on the required
327 size of the content. The size will be a multiple of 4.
329 ExID: The experiment ID value is 0x0a0d (2573).
331 ASN: 32 bit value of the Autonomous System Number.
333 Payload: A 32 bit opaque value.
335 The option space in the TCP header is limited to eleven 32 bit words
336 [1]. So no more than five ASN / Payload pairs can be included. The
337 number might be lower, if other TCP options are present.
339 The option is defined to exist only in packets with the SYN flag set.
340 It SHOULD NOT occur in data only packets, hence the MSS is not
341 changed. For TCP fast open [6], the size of the initial segment
342 needs to be adjusted.
344 3.3. Offering services
346 In order request a resource according to Section 2.1, the client
347 opens a new TCP connection with the SYN flag set and the ACK flag
348 cleared [1] and SHOULD add an empty ASN option as defined in
349 Section 3.2.
351 Any ASN MAY offer a special service to the content provider by
352 appending its own ASN to the end. The payload contains a
353 contractually defined value, i.e. a challenge with nonce bits, which
354 will be processed by the content provider. The list of offers MUST
355 NOT be deleted or reordered.
357 If there is no contract between the carrier and the content provider,
358 the special payload "0" MAY be used. This means, that the carrier
359 want to negotiate a contract. If this negotiation fails after a
360 reasonable period of time, the carrier SHOULD pass the packets
361 untouched.
363 A carrier MUST NOT add an offer to the list, if it can not guarantee,
364 that all packets of the flow will run through its infrastructure.
365 Normally only the Internet access provider is able to do so. Transit
366 providers need to take extra actions to bypass the normal Internet
367 routing, before adding an offer. Adding an offer includes the
368 promise to keep the routing decision stable and always route the
369 following packets of this flow to the same ASN as the initial packet.
370 Furthermore it MUST route all the response packets of this flow to
371 the ASN which was last one in the list.
373 If the option space is full, the carrier MUST NOT add an offer to the
374 list. This way the access providers have a first opportunity to
375 place an offer, fulfilling their request to compensate the broadband
376 access costs.
378 3.4. Accepting offers
380 Any new connection containing this ASN option, SHOULD be signalled to
381 the application level. Processing of any of the payment headers as
382 defined in Section 2.2 SHOULD be suppressed unless the application
383 got this signal. This way normal "links" are processed as usual,
384 while "rights" can be handled correctly.
386 On receiving the initial packet at the final destination, the option
387 values are examined. For each offer the payload MUST be replaced by
388 the contractually defined, computed response. The list MUST NOT be
389 reordered. If an offer is rejected, the payload is set to "0". So
390 the TCP syn/ack packet contains a ASN option with all the acceptance
391 values.
393 On the way back each ASN, which put in an offer, MUST examine the
394 option, and MUST remove the last item from the list, if AS number
395 matches. Depending on the response to the offer, the TCP flow SHOULD
396 be handled accordingly to the contractual requirements.
398 Finally the carrier SHOULD route toward the next ASN in the option.
400 4. Acknowledgements
402 This memo is influenced by the legislative process in the EU [11].
403 Special thanks go to Julia Reda [12] for keeping the public updated.
404 The basic idea was contributed by Bernd Paysan. Very valuable input
405 came from many discussions over the IETF lists.
407 5. IANA Considerations
409 This memo adds an TCP ExID into the IANA registry
410 according the the rules of RFC 6994 [5].
413 +--------+--------------------------------+
414 | Value | Description |
415 +--------+--------------------------------+
416 | 0x0a0d | Autonomous System Compensation |
417 +--------+--------------------------------+
419 6. Security Considerations
421 Filtering the TCP option on intermediate devices might render the
422 resource in question unreachable.
424 The TCP option is designed to implement a challenge response
425 mechanism, which should withstand a MITM attack. All details of such
426 a mechanism are out of the scope of this memo.
428 Attribute values might be copied from a document and reused
429 elsewhere. This might result in theft of access rights and should be
430 prevented by appropriate actions (i.e. checking Referer, Cookies).
432 7. References
434 7.1. Normative References
436 [1] Postel, J., "Transmission Control Protocol", STD 7,
437 RFC 793, DOI 10.17487/RFC0793, September 1981,
438 .
440 [2] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
441 Resource Identifier (URI): Generic Syntax", STD 66,
442 RFC 3986, DOI 10.17487/RFC3986, January 2005,
443 .
445 [3] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
446 Border Gateway Protocol 4 (BGP-4)", RFC 4271,
447 DOI 10.17487/RFC4271, January 2006,
448 .
450 [4] Josefsson, S., "The Base16, Base32, and Base64 Data
451 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
452 .
454 [5] Touch, J., "Shared Use of Experimental TCP Options",
455 RFC 6994, DOI 10.17487/RFC6994, August 2013,
456 .
458 [6] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
459 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
460 .
462 [7] Bray, T., "An HTTP Status Code to Report Legal Obstacles",
463 RFC 7725, DOI 10.17487/RFC7725, February 2016,
464 .
466 [8] World Wide Web Consortium, "The link element", 2018,
467 .
470 [9] World Wide Web Consortium, "The a element", 2018,
471 .
474 7.2. Informative References
476 [10] Bradner, S., "Key words for use in RFCs to Indicate
477 Requirement Levels", BCP 14, RFC 2119,
478 DOI 10.17487/RFC2119, March 1997,
479 .
481 [11] EUROPEAN COMMISSION, "Proposal for a DIRECTIVE OF THE
482 EUROPEAN PARLIAMENT AND OF THE COUNCIL on copyright in the
483 Digital Single Market", 2016, .
486 [12] Reda, J., "Homepage", .
488 [13] Helgadottir, A., "German press track record",
489 .
492 [14] Marx, K., "Kritik des Gothaer Programms", 1875.
494 Author's Address
496 Lutz Donnerhacke
497 Fitug e.V.
498 Leutragraben 1
499 Jena 07743
500 DE
502 Phone: +49 3641 573561
503 Email: lutz@fitug.de