idnits 2.17.1 draft-donnerhacke-linktax-02.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 (December 28, 2018) is 1939 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 December 28, 2018 5 Expires: July 1, 2019 7 Rights for restricted content 8 draft-donnerhacke-linktax-02 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 July 1, 2019. 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 1.3. Success conditions . . . . . . . . . . . . . . . . . . . 4 66 2. Referencing restricted content . . . . . . . . . . . . . . . 4 67 2.1. The RIGHT element . . . . . . . . . . . . . . . . . . . . 4 68 2.2. Monetization . . . . . . . . . . . . . . . . . . . . . . 4 69 2.2.1. Prepaid references . . . . . . . . . . . . . . . . . 4 70 2.2.2. Pay per use . . . . . . . . . . . . . . . . . . . . . 5 71 2.3. Digital Rights Management . . . . . . . . . . . . . . . . 6 72 3. Compensate transit providers . . . . . . . . . . . . . . . . 6 73 3.1. Routing Considerations . . . . . . . . . . . . . . . . . 6 74 3.2. Option Format . . . . . . . . . . . . . . . . . . . . . . 6 75 3.3. Offering services . . . . . . . . . . . . . . . . . . . . 7 76 3.4. Accepting offers . . . . . . . . . . . . . . . . . . . . 8 77 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 82 7.2. Informative References . . . . . . . . . . . . . . . . . 10 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 [13]. 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 The idea of a link tax is commonly attributed to the German publisher 111 "Axel Springer". They claim that "Links" can't be free and that the 112 Internet is a "Rechts-freier Raum" (lawless space). To overcome this 113 situation, they invented the "Leistungsschutzrecht", which in turn is 114 the founding of the EU proposal [11]. 116 Implementing this memo will satisfy all those claims: 118 They can choose to monetize their content by using the "right" 119 instead of the "link" element. If they are using "link", they 120 agree to not sue anybody over the use of the resource. 122 If they choose "right", they can limit the amount of usage of the 123 reference. This way the can obtain money from the referencing 124 page (i.e. a news aggregator). 126 If they choose "right", they even can limit the usage of the 127 content itself. They can prevent i.e. printing or sharing by the 128 customer. 130 1.2. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 memo are to be interpreted as described in RFC 2119 [10]. 136 1.3. Success conditions 138 This memo specifies an experiment. It tries to make a political 139 offer to those parties, which constantly want to change the Internet 140 in favor of their own needs. By defining a technical solution for 141 the announced problems, the political decision process has another 142 alternative to accepting or denying the requested laws. This memo 143 allows to acknowledge the needs of the interested parties without 144 harming the existing Internet. 146 Now the political decision process has to choose one from the 147 following possibilities: 149 Denying the requests completely, 151 Allowing the requests and point them to this memo for 152 implementation, 154 or to actively changing the existing Internet in order to fulfil 155 the requests. 157 2. Referencing restricted content 159 References to remote content are currently done using "links". The 160 only relevant environment for the purposes of this memo is the World 161 Wide Web. There the "link" is represented by the element [8] 162 or the element [9]. 164 2.1. The RIGHT element 166 The new element is a modification of the existing 167 element [8]. It differs from the former by the retrieval method used 168 by the client browser, and two additional attributes. 170 When accessing the referenced resource of the RIGHT element, the 171 browser SHOULD initiate the connection using the TCP options 172 described in Section 3. 174 2.2. Monetization 176 Wenn referencing a resource one of the following monetization methods 177 MUST be used. The methods are mutually exclusive. 179 2.2.1. Prepaid references 181 The RIGHT element MAY have an attribute named "prepaid", which 182 contains an opaque token. The token SHOULD be a Base64 string [4]. 183 The attribute MUST not processed, if the token does exceed the Base64 184 charset. It MAY even check, if the token is really a Base64 185 encoding. 187 Any valid token MUST be copied to a new HTTP header line "Right: 188 prepaid=token" when requesting the referenced resource. If the 189 attribute does not exist or is invalid, the line SHOULD be omitted. 191 The resource provider MAY use this token to validate, that the 192 resource was legally requested. If the token is invalid, it MAY 193 respond with the error code 402. It MUST NOT respond with error code 194 451 [7]. 196 The resource provider MUST provide an API, where new tokens can be 197 obtained. Access to the API SHOULD be limited to paying contractors 198 and SHOULD offer tokens which are valid for a larger amount of 199 requests and MAY time out. 201 This is the prefered method for link aggregators and search engines, 202 which make money from referencing third party content. It can also 203 be used, if the referencing page owner want to avoid payment hussle 204 for the customer. 206 2.2.2. Pay per use 208 The RIGHT element MAY have a couple of attributes, which instruct the 209 browser to process the necessary payment before accessing the 210 resource. 212 The attribute "payment" contains a URI [2] denoting the clearing 213 point for the transaction and the destination of the payment. This 214 memo does not define any methods, but it might look like 215 "microico:123456..def" or "https://micro.pay.me.example/@company/ 216 AxelS". The payment API MUST return a proof of payment (PoP) value 217 on success. The PoP value MUST NOT exceed the Base64 charset [4]. 219 The attribute "currency" contains a string to be used by the payment 220 API. It SHOULD donate a well defined abbreviation for the currency. 222 The attribute "view" contains a numerical value. The browser MUST 223 NOT render the RIGHT element, without successfully paying the denoted 224 amount of currency via the payment API. It SHOULD cache this result 225 for later use to avoid multiple spendings for the same content. 227 The attribute "click" contains a numerical value. The browser MUST 228 add the a header line "Right: click=PoP" when requesting the 229 referenced resource. The PoP is the proof of payment value from 230 payment of the denoted amount of currency. The resource provider MAY 231 use this value to validate, that the resource was payed. If the 232 token is invalid, it MAY respond with the error code 402. It MUST 233 NOT respond with error code 451 [7]. 235 At least one of the attributes "view" or "click", as well as the 236 attributes "payment" and "currency" MUST be present for this method. 238 This is the prefered method for referencing restricted content from 239 pages providing own content. 241 2.3. Digital Rights Management 243 The RIGHT element MAY have an attribute named "drm", which contains 244 an opaque token. The token SHOULD be a Base64 string [4]. The 245 attribute MUST NOT processed, if the token exceeds the Base64 246 charset. It MAY even check, that the token is really a Base64 247 encoding. 249 Any valid token MUST be handed over to the local DRM software used to 250 process the content of the resource. The details of the API and the 251 processing inside the DRM software is out of the scope of this memo. 253 3. Compensate transit providers 255 3.1. Routing Considerations 257 Traffic from the resource provider to the client (and back) travels 258 through the Internet by passing from one internet carrier to the next 259 one until it reaches the destination. The internet carriers are 260 interconnected by each other through dedicated peerings. At such a 261 peering, the networks of the carriers talk directly to each other. 262 The network of a carrier itself are summarized by an Autonomous 263 System Number [3]. 265 There is no guarantee, that the packets travel the same way all the 266 time. Traffic in one direction may touch completely different 267 providers, than on the way back. The traffic can be rerouted if 268 necessary, even if the TCP session is still up. So it is difficult 269 to compensate the intermediate carriers, simply because they may 270 change at any time. 272 3.2. Option Format 274 In order to track the route of carriers involved, a new TCP option is 275 defined. It contains an arbitrary amount of 32 bit ASN / Payload 276 pairs. 278 0 1 2 3 279 01234567 89012345 67890123 45678901 280 +--------+--------+--------+--------+ 281 | Kind | Length | ExID | 282 +--------+--------+--------+--------+ 283 | ASN-1 | 284 +--------+--------+--------+--------+ 285 | Payload-1 | 286 +--------+--------+--------+--------+ 287 ... 288 | ASN-n | 289 +--------+--------+--------+--------+ 290 | Payload-n | 291 +--------+--------+--------+--------+ 293 Figure 1: Autonomous System Compensation Option 295 Kind: The option kind value is 253. 297 Length: The length of the option is variable, based on the required 298 size of the content. The size will be a multiple of 4. 300 ExID: The experiment ID value is 0x0a0d (2573). 302 ASN: 32 bit value of the Autonomous System Number. 304 Payload: A 32 bit opaque value. 306 The option space in the TCP header is limited to eleven 32 bit words 307 [1]. So no more than five ASN / Payload pairs can be included. The 308 number might be lower, if other TCP options are present. 310 The option is defined to exist only in packets with the SYN flag set. 311 It SHOULD NOT occur in data only packets, hence the MSS is not 312 changed. For TCP fast open [6], the size of the initial segment 313 needs to be adjusted. 315 3.3. Offering services 317 In order request a resource according to Section 2.1, the client 318 opens a new TCP connection with the SYN flag set and the ACK flag 319 cleared [1] and SHOULD add an empty ASN option as defined in 320 Section 3.2. 322 Any ASN MAY offer a special service to the content provider by 323 appending its own ASN to the end. The payload contains a 324 contractually defined value, i.e. a challenge with nonce bits, which 325 will be processed by the content provider. The list of offers MUST 326 NOT be deleted or reordered. 328 If there is no contract between the carrier and the content provider, 329 the special payload "0" MAY be used. This means, that the carrier 330 want to negotiate a contract. If this negotiation fails after a 331 reasonable period of time, the carrier SHOULD pass the packets 332 untouched. 334 A carrier MUST NOT add an offer to the list, if it can not guarantee, 335 that all packets of the flow will run through its infrastructure. 336 Normally only the Internet access provider is able to do so. Transit 337 providers need to take extra actions to bypass the normal Internet 338 routing, before adding an offer. Adding an offer includes the 339 promise to keep the routing decision stable and always route the 340 following packets of this flow to the same ASN as the initial packet. 341 Furthermore it MUST route all the response packets of this flow to 342 the ASN which was last one in the list. 344 If the option space is full, the carrier MUST NOT add an offer to the 345 list. This way the access providers have a first opportunity to 346 place an offer, fulfilling their request to compensate the broadband 347 access costs. 349 3.4. Accepting offers 351 Any new connection containing this ASN option, SHOULD be signalled to 352 the application level. Processing of any of the payment headers as 353 defined in Section 2.2 SHOULD be suppressed unless the application 354 got this signal. This way normal "links" are processed as usual, 355 while "rights" can be handled correctly. 357 On receiving the initial packet at the final destination, the option 358 values are examined. For each offer the payload MUST be replaced by 359 the contractually defined, computed response. The list MUST NOT be 360 reordered. If an offer is rejected, the payload is set to "0". So 361 the TCP syn/ack packet contains a ASN option with all the acceptance 362 values. 364 On the way back each ASN, which put in an offer, MUST examine the 365 option, and MUST remove the last item from the list, if AS number 366 matches. Depending on the response to the offer, the TCP flow SHOULD 367 be handled accordingly to the contractual requirements. 369 Finally the carrier SHOULD route toward the next ASN in the option. 371 4. Acknowledgements 373 This memo is influenced by the legislative process in the EU [11]. 374 Special thanks go to Julia Reda [12] for keeping the public updated. 375 The basic idea was contributed by Bernd Paysan. Very valuable input 376 came from many discussions over the IETF lists. 378 5. IANA Considerations 380 This memo adds an TCP ExID into the IANA registry 381 according the the rules of RFC 6994 [5]. 384 +--------+--------------------------------+ 385 | Value | Description | 386 +--------+--------------------------------+ 387 | 0x0a0d | Autonomous System Compensation | 388 +--------+--------------------------------+ 390 6. Security Considerations 392 Filtering the TCP option on intermediate devices might render the 393 resource in question unreachable. 395 The TCP option is designed to implement a challenge response 396 mechanism, which should withstand a MITM attack. All details of such 397 a mechanism are out of the scope of this memo. 399 Attribute values might be copied from a document and reused 400 elsewhere. This might result in theft of access rights and should be 401 prevented by appropriate actions (i.e. checking Referer, Cookies). 403 7. References 405 7.1. Normative References 407 [1] Postel, J., "Transmission Control Protocol", STD 7, 408 RFC 793, DOI 10.17487/RFC0793, September 1981, 409 . 411 [2] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 412 Resource Identifier (URI): Generic Syntax", STD 66, 413 RFC 3986, DOI 10.17487/RFC3986, January 2005, 414 . 416 [3] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 417 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 418 DOI 10.17487/RFC4271, January 2006, 419 . 421 [4] Josefsson, S., "The Base16, Base32, and Base64 Data 422 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 423 . 425 [5] Touch, J., "Shared Use of Experimental TCP Options", 426 RFC 6994, DOI 10.17487/RFC6994, August 2013, 427 . 429 [6] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 430 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 431 . 433 [7] Bray, T., "An HTTP Status Code to Report Legal Obstacles", 434 RFC 7725, DOI 10.17487/RFC7725, February 2016, 435 . 437 [8] World Wide Web Consortium, "The link element", 2018, 438 . 441 [9] World Wide Web Consortium, "The a element", 2018, 442 . 445 7.2. Informative References 447 [10] Bradner, S., "Key words for use in RFCs to Indicate 448 Requirement Levels", BCP 14, RFC 2119, 449 DOI 10.17487/RFC2119, March 1997, 450 . 452 [11] EUROPEAN COMMISSION, "Proposal for a DIRECTIVE OF THE 453 EUROPEAN PARLIAMENT AND OF THE COUNCIL on copyright in the 454 Digital Single Market", 2016, . 457 [12] Reda, J., "Homepage", . 459 [13] Marx, K., "Kritik des Gothaer Programms", 1875. 461 Author's Address 463 Lutz Donnerhacke 464 Fitug e.V. 465 Leutragraben 1 466 Jena 07743 467 DE 469 Phone: +49 3641 573561 470 Email: lutz@fitug.de