idnits 2.17.1 draft-flinck-mobile-throughput-guidance-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 19) being 70 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 27 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 plaintext contains type-value pair elements of the variable length data. The plaintext is divided into blocks of 16 bytes. A block of plain text MUST not exceed 16 bytes in a single run. Encryption takes a key (16 bytes), an IV or Nonce (16 bytes), the plain-text (at most 16 bytes) and produces a cipher text of 16 bytes. Note: multiple keys, at most 256, may be available (can be negotiated via out-of-band key management; this out of scope of this document) for encryption key index. The keys MUST be different from those used for authentication. -- The document date (October 26, 2014) is 3470 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3168' is mentioned on line 191, but not defined == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 745, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 758, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 761, but no explicit reference was found in the text == Unused Reference: 'RFC4413' is defined on line 765, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 7 3 Internet Engineering Task Force A. Jain 4 Internet-Draft A. Terzis 5 Intended status: Informational Google 6 Expires: April 29, 2015 N. Sprecher 7 P. Szilagyi 8 H. Flinck 9 Nokia Networks 10 October 26, 2014 12 Mobile Throughput Guidance Signaling Protocol 13 draft-flinck-mobile-throughput-guidance-00.txt 15 Abstract 17 The behaviour of the Transmission Control Protocol (TCP), which 18 assumes that network congestion is the primary cause for packet loss 19 and high delay, can lead to inefficient use of a cellular network's 20 resources and degrade application performance. The root cause for 21 this inefficiency is that TCP has difficulty adapting to the rapidly 22 varying network conditions. In cellular networks, the bandwidth 23 available for end devices can vary by an order of magnitude over a 24 few seconds due to changes in the underlying radio channel 25 conditions, as devices move, as well as changes in system load as 26 other devices enter and leave the network. 28 This document proposes a mechanism and protocol elements that can be 29 used to assist TCP in cellular networks, ensuring high utilization 30 and high service delivery performance. 32 The document describes the applicability of the proposed mechanism 33 for video delivery over cellular networks; it also presents test 34 results. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 50 This Internet-Draft will expire on April 29, 2015. 52 Copyright Notice 54 Copyright (c) 2014 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 70 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . 3 71 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . 3 73 1.4. Problem statement . . . . . . . . . . . . . . . . . . . . 3 74 1.5. Mechanism Principles . . . . . . . . . . . . . . . . . . 4 75 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3. Applicability to Video Delivery Optimization . . . . . . . . 6 77 3.1. Test Results . . . . . . . . . . . . . . . . . . . . . . 7 78 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 4.1. Common Kind-Length-Value header . . . . . . . . . . . . . 8 80 4.2. Plane text mode Throughput Guidance Options . . . . . . . 10 81 4.3. Encrypted mode . . . . . . . . . . . . . . . . . . . . . 11 82 4.4. Nonce (Initialization Vector) . . . . . . . . . . . . . 14 83 4.5. Authentication . . . . . . . . . . . . . . . . . . . . . 15 84 5. Manageability considerations . . . . . . . . . . . . . . . . 16 85 6. Security considerations . . . . . . . . . . . . . . . . . . . 16 86 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 90 9.2. Informative References . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 The following sub-sections present the problem statement and the 96 solution principles. 98 1.1. Contributing Authors 100 The editors gratefully acknowledge the following additional 101 contributors: Swaminathan Arunachalam and Csaba Vulkan. 103 1.2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 1.3. Acronyms and Abbreviations 111 This document uses the following acronyms: 113 ECGI E-UTRAN Cell Global Identifier format 114 ECN Explicit Congestion Notification 115 HMAC Hash-based Message Authentication Code 116 IP Internet Protocol 117 IV Initialization Vector 118 LTE Long Term Evolution 119 MTG Mobile Throughput Guidance 120 RAN Radio Access Network 121 RTT Round Trip Time 122 SACK Selective Acknowledgement 123 TCP Transmission Control Protocol 124 UE User Equipment 126 1.4. Problem statement 128 The bandwidth available for end devices in a cellular network can 129 vary by an order of magnitude over a few seconds. This variation is 130 due to changes in the underlying radio channel conditions, as devices 131 move, as well as system load variations driven by the arrival and 132 departure of devices to/from the network. On the other hand, packet 133 losses tend to be sporadic and temporary because retransmissions 134 mechanisms at the physical and link layers repair most packet 135 corruptions. 137 Transport protocols that derive network capacity through implicit 138 signals, such as packet loss and delay variation, can have difficulty 139 adapting to such rapidly changing network conditions. In turn, this 140 difficulty leads to poorer quality of experience for applications 141 like video playback as well as inefficient use of the cellular 142 network's resources. 144 1.5. Mechanism Principles 146 This document proposes that the cellular network provides information 147 on throughput guidance to the TCP server; this information will 148 indicate the throughput estimated to be available at the radio 149 downlink interface. The network SHOULD provide this information in 150 near real time in situations where the network conditions are 151 changing frequently or the user is moving. 153 While the implementation details will vary according to the access 154 technology, the resource allocation can be abstracted as the capacity 155 of the "radio link" between the network and the UE. For example, in 156 the case of an LTE network, the number of physical resource blocks 157 allocated to a UE, along with the modulation scheme and coding rate 158 used, can be translated into radio link capacity in Megabits per 159 second (Mbps). 161 The TCP server can use this explicit information to inform several 162 congestion control decisions. For example: (1) selecting the initial 163 window size, (2) deciding the value of the congestion window during 164 the congestion avoidance phase, and (3) adjusting the size of the 165 congestion window when the conditions on the "radio link" 166 deteriorate. In other words, with this additional information, TCP 167 does neither have to congest the network when probing for available 168 resource, nor rely on heuristics to reduce its sending rate after a 169 congestion episode. 171 The same explicit information can also be used to optimize 172 application behaviour given the available resources. For example, 173 when video is encoded in multiple bitrates, the application server 174 can select the highest encoding rate that the network can deliver. 176 This document proposes an in-band exposure mechanism where the 177 information elements are added to the TCP headers of the relevant 178 upstream packets. In particular, the throughput guidance information 179 is added into the Options field of the TCP header (see RFC 0793 180 [RFC0793]) of packets from the TCP client to the TCP server. An in- 181 band mechanism is proposed because it does not require a separate 182 interface, reference value, or correlation mechanism. Furthermore, 183 an in-band mechanism can keep up with the rapid changes in the 184 underlying radio link throughput. 186 Section 4 describes the definition details and semantics of the 187 Options field of the TCP header. 189 The proposed scheme is similar to existing mechanisms such as ECN, 190 where an ECN-aware router sets a mark in the IP header in order to 191 signal impending congestion (see [RFC3168]). Note, however, that the 192 proposed scheme provides explicit information, (termed "Throughput 193 Guidance") about the estimated throughput available at the radio link 194 between the Radio Access Network (RAN) and the UE. 196 The following issues are not covered: (1)the throughput estimation 197 for the uplink between the UE and the RAN, and (2)the capacity of the 198 network path between the RAN and the server communicating with the 199 UE. 201 2. Architecture 203 A Mobile Throughput Guidance Signaling Protocol (MTGSP) is specified 204 to allow a functional entity that resides in the RAN to signal 205 throughput guidance information to the TCP server. The TCP server 206 resides behind the core network of the operator or in the Internet. 208 As Figure 1 depicts below, the functional element of the Throughput 209 Guidance Provider signals to the TCP server the information on the 210 (near-real time) throughput estimated to be available at the radio 211 downlink interface. 213 The TCP server MAY use the information to optimize the TCP behaviour. 214 The information MAY also be used to adapt the application behaviour 215 accordingly and to optimize service delivery performance. 217 TCP flow behaviour based on 218 +-+-+-+-+-+-+-+ Throughput Guidance Information +-+-+-+-+-+-+-+ 219 | | <---------------------------------------- | | 220 | TCP client | +-+-+-+-+-+-+-+-+-+-+-+ | TCP Server | 221 | | | Througput Guidance | (x) | | 222 | | | Provider | ----------> | | 223 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 225 UE <--------------- RAN -------------------> x = Mobile Thourghput 226 Guidance Signaling 228 Figure 1 230 As described above, MTGSP SHALL use the Options field of the TCP 231 header of the same TCP flow to provide throughput guidance 232 information. 234 The information source and the algorithm used by the Throughput 235 Guidance Provider to calculate the throughput guidance are beyond the 236 scope of this document. 238 The TCP server MAY use the throughput guidance information to assist 239 TCP in any of the following ways: 241 o Determine the size of the initial congestion window 243 o Determine when to exit the slow start phase 245 o Determine the size of the congestion window during the congestion 246 avoidance phase 248 o Determine the size of the window after a congestion event 250 3. Applicability to Video Delivery Optimization 252 The applicability of the protocol specified in this document to 253 mobile video delivery optimization has been evaluated and tested in 254 different network load scenarios. 256 In this use case, TCP traffic, for which throughput guidance 257 information is required, passes through a Radio Analytics application 258 which resides in a Mobile-edge Computing (MEC) server (see 259 [MEC_White_Paper]). This Radio Analytics application acts as the 260 Throughput Guidance Provider and sends throughput guidance 261 information for a TCP flow using the Options field in the TCP header 262 (according to the message specification provided below in section 4). 263 The TCP server MAY use this information to assist TCP congestion 264 control decisions as described above. The information MAY also be 265 used to select the application level coding so that it matches the 266 estimated capacity at the radio downlink. 268 All of these improvements aim to enhance the quality of experience of 269 the end user by reducing the time-to-start of the content as well as 270 video stall occurrences. 272 With Mobile-edge Computing, the Radio Analytics application can be 273 deployed on top of platforms implemented by different vendors and 274 across multi-operator networks. This means that efficient 275 utilization of the network resources can be expected as well as 276 enhanced quality of experience for the vast majority of the end 277 users. 279 3.1. Test Results 281 Nokia Networks and Google tested the video delivery optimization use 282 case in a laboratory environment, simulating (as closely as possible) 283 a live production network. Different network load scenarios were 284 simulated. 286 All network level metrics showed an average improvement of 40-80%, as 287 detailed below: 289 o Reduction of end-to-end RTT by 40-60% 291 o TCP retransmissions reduced by 70-80% 293 o Buffer bloat reduced by 70-80% 295 The application-level metrics also improved, as detailed below: 297 o Click-to-play time reduced by 12-34% 299 o Stalling occurrences reduced by 46-100% 301 o Reduction in the number of format changes by 21-27% 303 4. Protocol 305 The Mobile Throughput Guidance Signaling message conveys information 306 on the throughput estimated to be available at the down link path of 307 a given TCP connection. The information is sent to the uplink end- 308 point of the connection (e.g., the TCP server). The TCP server MAY 309 use this information to optimize TCP behavior and to adjust 310 application-level behavior to the link conditions. 312 A good example is a content optimizer or a cache that can adapt the 313 application-level coding to match the indicated downlink radio 314 conditions. As radio link conditions may change rapidly, this 315 guidance information is best carried in-band using TCP options 316 headers rather than through an out-of-band protocol. 318 Using the TCP options to carry throughput guidance associates the 319 guidance information with an ongoing TCP connection and explicitly 320 avoids separate session identification information. The proposed 321 mechanism neither impacts the TCP state machine nor the congestion 322 control algorithms of the TCP protocol. 324 The Options field enables information elements to be inserted into 325 each packet with a 40-byte overall limit; this needs to be shared 326 with the standardized and widely-used option elements, such as the 327 TimeStamp and SACK. The TCP Options field uses a Kind-Length-Value 328 structure that enables TCP implementations to interpret or ignore 329 information elements in the Options field based on the Kind. 331 In this draft, we define a Kind-Length-Value structure for encoding 332 information about the estimated capacity of a radio access link 333 between the RAN and the UE which is traversed by a TCP connection. 334 Note that the Mobile Throughput Guidance Signaling defines an 335 extendible framework that can convey confidential information to an 336 information receiver. The intention is to define a generic container 337 to convey in-band information within the limited TCP Option space 338 with optional authentication and/or encryption capabilities. 339 Throughput guidance is provided in this document. Additional 340 information can be specified in future documents. 342 The TCP options for Mobile Throughput Guidance Signaling are added by 343 the Throughput Guidance Provider functional element (which resides on 344 top of a radio network element), when there is enough space in the 345 TCP header. 347 Confidential information must be delivered in a secure way. The 348 information can be provided as plain text in a secure and closed 349 network. In other cases, the information should be authenticated and 350 encrypted at the TCP-header level (between the Throughput Guidance 351 Provider and the TCP server). An acceptable level of authentication 352 and encryption (according to best common practices) may require more 353 data than can be fitted into a single TCP header (maximum of 40 if no 354 other options are present). As described below, packet fragmentation 355 will be used is such a case. 357 Two transfer modes are defined to deal with data confidentiality in 358 this document; namely, plain-text mode and authenticated encryption 359 mode. A third mode, authentication-only mode, is equally feasible. 360 However, we do not currently provide the authentication-only mode but 361 will consider it for later updates. Both modes share a common Kind- 362 Length-Value "option header" structure with a flag field separating 363 the two cases. 365 4.1. Common Kind-Length-Value header 367 To make Mobile Throughput Guidance Signaling extendible to different 368 use cases a common Kind-Length-Value header is defined below. 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 |Kind | Length | Flags| variable length data | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Figure 2 376 Kind: 378 The Option Kind field indicates that the subsequent options are 379 part of Mobile Throughput Guidance Signaling. The size of this 380 field is 1 byte. 382 Length: 384 A 1 byte field, indicating the length of the kind and the length 385 fields, as well as the length of the following Options field(s): 387 Flags: 389 One byte of MTG protocol flag field as defined below. 391 0 1 2 3 4 5 6 7 392 +-+-+-+-+-+-+-+-+ 393 | Seq |Frag |P|T| 394 +-+-+-+-+-+-+-+-+ 396 Flag field of common Kind-Lenght-Value header 398 Figure 3 400 Seq: 402 Three-bit sequence number that maintains context across different 403 packet types as defined by P- and T-bits below. The scope of the 404 sequence number is to protect against packet reordering, not to 405 provide a globally unique identifier or sequence number. The use 406 of these bits are reserved for possible transfer mode extensions. 408 Frag: 410 Three bits that provide information about how to reassemble 411 information if fragmented into multiple packets. If no 412 fragmentation across multiple TCP packet headers is needed, these 413 bits are set to zero. Otherwise, Frag is a counter starting from 414 1 and incremented by 1 for each subsequent packet of the same type 415 (see P- and T-bits below). For the last fragment, the Fragment is 416 always 7 (binary 111) to indicate that the information is 417 complete. 419 P and T bits: 421 These two bits encode the packet type: Plaintext (P=0, T= 0), 422 Cipher text (P=0, T=1), Nonce (IV) (P=1, T=0) or Authentication 423 (P=1, T=1). For Plaintext, the Fragment bits are always zero. 425 Variable length data: 427 The variable length content in type, value format. The content 428 depends of the transfer mode as defined in the following sections 429 of this document. 431 As an example for the use of Flag-field, consider a cipher text of a 432 single block. For it the T-bit is set one, P-bit is set to zero, 433 Fragment and Seq-fields are zero in the Flag-field. In case the 434 cipher text option that cannot fit into a single TCP packet option, 435 the cipher text is fragmented across multiple TCP headers. The first 436 fragment has value Frag= 001, and the value is incremented for each 437 subsequent fragment. The last fragment is marked with all Frag-bits 438 set to 1 (Frag= 111 for the last fragment). Details follow in the 439 next sections. 441 4.2. Plane text mode Throughput Guidance Options 443 The plain text mode can be used in secure and closed networks or with 444 information that has no confidentiality requirement. The plane text 445 mode is made of one or more type, value -pairs. The type defines 446 fixed the length of the following value. 448 Table of Type Value pairs of Throughput Guidance option data 450 +---------------------+------+----------+---------------------------+ 451 | Name | Type | Length | Value Unit | 452 +---------------------+------+----------+---------------------------+ 453 | Throughput Guidance | 1 | 2 bytes | kbits/s | 454 | Access point ID | 4 | 7 bytes | global identifier (ECGI) | 455 +---------------------+------+----------+---------------------------+ 457 Table 1: MTG type-vale pairs 459 The Type 1 element carries the actual throughput estimate in the 460 16-bit value unit. The throughput value is encoded using a fixed- 461 point number representation. The 12 most significant bits are used 462 for the integer value while the bottom 4 bits correspond to the 463 decimal portion of the throughput value. Throughput is expressed in 464 Megabits per second. 466 The type-value pair elements are laid out consecutively in the 467 header. At the end padding (i.e., the NO-OP TCP Option header with 468 kind equal to 1, or the End of Option List TCP Option header with 469 kind equal to 0) may be required to align the header size to the 470 multiple of 4 bytes (required by the TCP standard). All bits in the 471 Flag field are set to zero. 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 |Kind | Length | Flags| Type1|Value-1| Type2|Value-2| ...Padding| 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 Kind: Value for Mobile Throughput Guidance Signaling 477 Type: as defined in the table of Type Value pairs of MTG option data 478 Flags: P- and T-bits set to zero 480 Layout of plain text option data in the TCP header options space. 482 Figure 4 484 4.3. Encrypted mode 486 Encryption requires authentication for integrity protection, as it is 487 insecure to use encryption without it. Thus, the encrypted contains 488 authentication as well. Encryption and authentication must use 489 different keys. The following diagram shows the encryption process. 491 +-+-+-+-+ +-+-+-+-+-+ 492 +-+-+-+-+-+ | key1 | |IV(Nonce)| 493 |key index| --> +-+-+-+-+ +-+-+-+-+-+ 494 +-+-+-+-+-+ | key 2 | | 495 +-+-+-+-+ key +-+-+-V-+-+-+-+ 496 ... ----> | AES 128-CNT| 497 +-+-+-+-+ +-+-+-+-+-+-+-+ 498 | key n | | 499 +-+-+-+-+ +<------ Plain text 500 | 501 +-+-+-V-+-+-+-+ 502 | Cipher text | 503 +-+-+-+-+-+-+-+ 505 Encryption method 507 Figure 5 509 The encryption uses Advanced Encryption Standard (AES), 128 bits (16 510 bytes) block size, 128 bits (16 bytes) key size, Counter (CTR) block 511 cipher mode. Integrity protection with CTR mode is MUST; this is be 512 provided via HMAC based message authentication (see Authentication 513 section below). 515 The plaintext contains type-value pair elements of the variable 516 length data. The plaintext is divided into blocks of 16 bytes. A 517 block of plain text MUST not exceed 16 bytes in a single run. 518 Encryption takes a key (16 bytes), an IV or Nonce (16 bytes), the 519 plain-text (at most 16 bytes) and produces a cipher text of 16 bytes. 520 Note: multiple keys, at most 256, may be available (can be negotiated 521 via out-of-band key management; this out of scope of this document) 522 for encryption key index. The keys MUST be different from those used 523 for authentication. 525 The Nonce is 16 bytes. A unique Nonce is generated for each 526 encrypted block. The same Initialization Vector, IV or Nonce MUST 527 NOT be used with the same encryption key more than once. This is be 528 enforced by the Throughput Guidance Provider; otherwise security 529 scheme will be broken. 531 The resulting cipher text is in blocks of 16 bytes. The cipher text 532 blocks are packed into the option space together with the used Key 533 Index in a following way if they fit into singe option space of a 534 single TCP header. 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 |Kind | Length | Flags | Key Index |first block of 16 bytes | | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 Kind: Value for Mobile Throughput Guidance Signaling 541 Flags: Type of cipher text T-bit set to 1, only one block Frag= 000. 542 Key Index is the index used in encryption 544 Cipher text layout in the TCP options without fragmentation 546 Figure 6 548 The flag field of the common option header indicates that the content 549 is cipher text by having the T bit set to one. Since the ciphered 550 block is not fragmented the Frag-bits of the flag field are set to 551 zero (Frag= 000). (Use of Seq bits is left for later submissions). 553 If there are multiple cipher text blocks of 16 bytes, the flag field 554 shows the type of the option being cipher text with the T-bit set to 555 one, and by Frag-field showing the fragment number starting from 001 556 and incremented by one for each subsequent fragment of a packet of 557 the same type. For the last fragment, the Frag-field is always 558 binary 111 to indicate the last fragment. 560 First fragment: 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 |Kind |Length|Flags|KeyIndex| 1st blocks of 16 bytes | fragmented block | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Kind: Value for Mobile Throughput Guidance Signaling 567 Flags: Type of cipher text T-bit = 1, Frag field = 001 first fragment 568 Key Index is the index used in encryption 570 Second fragment: 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 |Kind | Length | Flags | Key Index | Rest of the fragmented block | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Kind: Value for Mobile Throughput Guidance Signaling 577 Flags: Type of cipher text T-bit = 1, Frag field = 111 last fragment 578 Key Index is the index used in encryption 580 Cipher text layout extending to two consecutive headers 582 Figure 7 584 4.4. Nonce (Initialization Vector) 586 The 16 byte Nonce (or IV) is transmitted along with the cipher text 587 to protect against de-synchronization between the encryption- 588 decryption points. 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 |Kind | Length | Flags | Key Index | Nonce (IV) 16 bytes | | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 Kind: Value for Mobile Throughput Guidance Signaling 595 Flags: Type of IV/Nonce P-bit set to 1, only one block Frag= 000 596 Key Index is the index used in encryption 598 Nonce (IV) in a single header 600 Figure 8 602 If the Nonce (IV) doesn't fit into the remaining free bytes of the 603 option field it needs to be fragmented using the Frag-field in the 604 same way as cipher text layout is extending across two or more 605 consecutive TCP headers but with the option type field set to 606 indicate Nonce/IV by P-bit set to 1. 608 4.5. Authentication 610 The authentication covers the cipher text, the Nonce (IV) and 611 includes additional TCP protocol header fields to protect against 612 replay attacks. The authentication uses HMAC codes (e.g. HMAC- 613 SHA2-224), 128 bits (16 bytes) key size, 224 bits (28 bytes) digest 614 size. Multiple keys (at most 256) for authentication with the same 615 information receiver can be used. The keys MUST be different from 616 those used for encryption. Truncation is possible but at least 160 617 bits (20 bytes) must be used from the digest to meet the typical 618 security level of mobile networks. 620 Authentication takes a key, the input (arbitrary length) and produces 621 a 28 byte long digest, which is truncated to 20 bytes (keeping the 622 most significant bytes). The HMAC algorithm and truncation can be 623 negotiated via key management (out of scope of this document). 625 The authentication covers the TCP sequence number, ACK number, and 626 TimeStamp (TSval, TSecr not the possible 2 bytes of padding) fields 627 of the TCP header as well as the Common Kind-Length-Value header with 628 its data in all cipher text option and IV/Nonce option packets. (The 629 Authentication type options itself cannot be covered by the 630 authentication.) 632 The order in which the fields are included into the message 633 authentication code is the following. From the TCP header: TCP Seq, 634 ACK, TSval, TSecr. Followed by the following fields from the 635 ciphered text: Kind, Length, Flags, Key Index, cipher text, and from 636 the IV/Nonce type of option packets TCP Seq, ACK, TSval, TSecr (note 637 cipher text and IV/Nonce type of options may be in different TCP 638 packets) followed by Kind, Length, Flags, Key Index, Nonce/IV. 640 In case the option packets used as input to the HMAC are fragmented 641 into multiple TCP headers, they are processed so that headers with 642 cipher text option are processed first, followed by IV/Nonce option 643 packets. 645 The options containing the result of the HMAC are marked by setting 646 both P- and T-bits of the flag-field to one. Key Index is set to 647 point to the used authentication key, followed by the resulting 648 authentication code. If the option doesn't fit into the free option 649 space in the TCP header, it is fragmented across multiple TCP headers 650 in the same way as the cipher text options use the Frag-field. 652 5. Manageability considerations 654 There SHOULD be a mechanism to configure the application in the RAN 655 with a list of destinations to which throughput guidance should be 656 provided. 658 In addition, it SHOULD be possible to configure the frequency (in 659 milliseconds) at which throughput guidance needs to be signaled as 660 well as the required security level and parameters for the encryption 661 and the authentication if supported. 663 6. Security considerations 665 The introduction of explicit information from the cellular network 666 that can affect the behavior of a transport connection endpoint 667 introduces a set of security considerations. 669 First, the identity of the network entity that injects the throughput 670 guidance header must be explicitly known to the endpoint receiving 671 the information. Omitting such information would enable malicious 672 third parties to inject erroneous information. 674 Fortunately, the issue of malicious disinformation can be easily 675 addressed using well known techniques. First, the network entity 676 responsible for injecting the throughput guidance header can encrypt 677 the header and include a cryptographically secure message 678 authentication code. In this way the transport endpoint that 679 receives the throughput guidance header can check that the 680 information was sent by a legitimate entity and that the information 681 has not been tampered. 683 Section 4 described how the TCP Header information can be signed and 684 encrypted for security purposes. An out-of-band mechanism is 685 currently used to agree upon the set of keys used to encrypt and 686 authenticate the messages exchanged between the endpoint and the 687 network element that generate the throughput guidance headers. 689 Furthermore, the throughput guidance information should be treated 690 only as a hint to the congestion control algorithm running at the 691 transport endpoint. The endpoint that receives this information 692 should not assume that it is always correct and accurate. 693 Specifically, endpoints should check the validity of the information 694 received and if they find it erroneous they should discard it and 695 possibly take other corrective actions (e.g., discard all future 696 throughput guidance information from a particular IP prefix). 698 One way to check if the throughput guidance information overestimates 699 the capacity available on the radio link is to check whether any 700 packet losses or other signs of congestion (e.g., increasing RTT) 701 occur after the guidance is used. Notably, the same mechanism can be 702 used to deal with bottlenecks in other parts of the the end-to-end 703 network path. To check if the throughput guidance underestimates the 704 available network capacity, the source can periodically attempt to 705 send faster and then check for signs of congestion. 707 7. IANA considerations 709 In the current version of the document and for field tests, the 710 experimental value 253 is used for the "Throughput Guidance" TCP 711 option kind. 713 Note that in this case, following RFC 6994 [RFC6994], a two-byte 714 experiment ID field SHOULD follow immediately after the Length field 715 to allow for shared use of the experimental values. The figure below 716 shows how the throughput guidance option header will look in this 717 case. ExpID SHOULD be set to 0x6006 (16 bits). 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 |Kind | Length | ExpID | Flags | Variable Data | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 Figure 9 725 In future versions of the document, a code point should be assigned 726 for the MTGSP Kind field. 728 8. Acknowledgements 730 9. References 732 9.1. Normative References 734 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 735 793, September 1981. 737 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 738 Requirement Levels", BCP 14, RFC 2119, March 1997. 740 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 741 6994, August 2013. 743 9.2. Informative References 745 [I-D.narten-iana-considerations-rfc2434bis] 746 Narten, T. and H. Alvestrand, "Guidelines for Writing an 747 IANA Considerations Section in RFCs", draft-narten-iana- 748 considerations-rfc2434bis-09 (work in progress), March 749 2008. 751 [MEC_White_Paper] 752 "Mobile-Edge Computing - Introductory Technical White 753 Paper", September 2014, 754 . 758 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 759 June 1999. 761 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 762 Text on Security Considerations", BCP 72, RFC 3552, July 763 2003. 765 [RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, 766 March 2006. 768 Authors' Addresses 770 Ankur Jain 771 Google 772 1600 Amphitheatre Parkway 773 Mountain View, CA 94043 774 US 776 Phone: +1-925-526-5879 777 Email: jankur@google.com 779 Andreas Terzis 780 Google 781 1600 Amphitheatre Parkway 782 Mountain View, CA 94043 783 US 785 Phone: +1-650-214-5270 786 Email: aterzis@google.com 787 Nurit Sprecher 788 Nokia Networks 789 Hod HaSharon 790 IL 792 Phone: +97297751229 793 Email: nurit.sprecher@nsn.com 795 Peter Szilagyi 796 Nokia Networks 797 Budapest 798 Hungary 800 Phone: +36209777797 801 Email: peter.1.szilagyi@nsn.com 803 Hannu Flinck 804 Nokia Networks 805 Helsinki 806 FI 808 Phone: +358504839522 809 Email: hannu.flinck@nsn.com 811 Swaminathan Arunachalam 812 Nokia Networks 813 Irving 814 US 816 Phone: +19723303204 817 Email: swaminathan.arunachalam@nsn.com 819 Csaba Vulkan 820 Nokia Networks 821 Budapest 822 Hungary 824 Phone: +36209777797 825 Email: csaba.vulkan@nsn.com