idnits 2.17.1 draft-fear-ippm-mpdm-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 date (October 21, 2018) is 2014 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT N. Elkins 3 Inside Products 4 G. Fioccola 5 Telecom Italia 6 M. Ackermann 7 BCBS Michigan 8 R. Hamilton 9 Intended Status: Proposed Standard Chemical Abstract Services 10 Expires: April 24, 2018 October 21, 2018 12 IPv6 Marking and Performance and Diagnostic Metrics (MPDM) 13 draft-fear-ippm-mpdm-02 15 Abstract 17 To assess performance problems, this document describes optional 18 headers embedded in each packet that provide marking, sequence 19 numbers and timing information as a basis for measurements. Such 20 measurements may be interpreted in real-time or after the fact. This 21 document specifies the IPv6 Marking and Performance and Diagnostic 22 Metrics (M-PDM) Hop-byHop and Destination Options extension headers. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 51 3: This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2 Rationale for defined solution . . . . . . . . . . . . . . . 4 66 1.2.1 Alternate Marking Method Operation . . . . . . . . . . 5 67 1.2.1.1 Single Mark Measurement . . . . . . . . . . . . . . 5 68 1.2.2.2 Double Mark Measurement . . . . . . . . . . . . . . 5 69 1.3 IPv6 Transition Technologies . . . . . . . . . . . . . . . . 6 70 2 Measurement Information Derived from PDM . . . . . . . . . . . . 6 71 3 Marking and Performance and Diagnostic Metrics (M-PDM) 72 Destination . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.1 Destination Options Header . . . . . . . . . . . . . . . . . 7 74 3.2.1 M-PDM Layout . . . . . . . . . . . . . . . . . . . . . . 7 75 3.2.2 Base Unit for Time Measurement . . . . . . . . . . . . . 9 76 3.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 9 77 3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 9 78 3.4.1 Using ESP Transport Mode . . . . . . . . . . . . . . . . 10 79 3.4.2 Using ESP Tunnel Mode . . . . . . . . . . . . . . . . . 10 80 3.5 Implementation Considerations . . . . . . . . . . . . . . . 10 81 3.5.1 M-PDM Activation . . . . . . . . . . . . . . . . . . . . 10 82 3.5.2 M-PDM Timestamps . . . . . . . . . . . . . . . . . . . . 10 83 3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 11 84 3.7 Information Access and Storage . . . . . . . . . . . . . . . 11 85 4 M-PDM HBH Option . . . . . . . . . . . . . . . . . . . . . . . . 12 86 4.1 HBH Timestamps In and Out . . . . . . . . . . . . . . . . . 15 87 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 15 88 5.1 Resource Consumption and Resource Consumption Attacks . . . 15 89 5.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . . 15 90 5.3 M-PDM as a Covert Channel . . . . . . . . . . . . . . . . . 16 91 5.4 Timing Attacks . . . . . . . . . . . . . . . . . . . . . . . 16 92 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 93 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 95 7.2 Informative References . . . . . . . . . . . . . . . . . . . 18 96 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 99 1 Background 101 To assess performance problems, measurements based on marking, 102 sequence numbers and timing may be embedded in each packet. Such 103 measurements may be interpreted in real-time or after the fact. 105 As defined in RFC8200 [RFC8200], destination options are carried by 106 the IPv6 Destination Options extension header. Destination options 107 include information that need be examined only by the IPv6 node given 108 as the destination address in the IPv6 header, not by routers or 109 "middle boxes". 111 RFC8200 [RFC8200] additionally defines the IPv6 Hop-by-Hop (HBH) 112 Options extension header. This header may be processed and examined 113 by end nodes, routers and "middle boxes". 115 This document specifies both the Marking Performance and Diagnostic 116 Metrics (M-PDM) destination option as well as the M-PDM HBH Option. 118 1.1 Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 1.2 Rationale for defined solution 126 The M-PDM Destination Option and M-PDM Hop-By-Hop Option are a 127 combining of PDM [RFC8250] with Marking [RFC8321] to obtain path and 128 middle box information. 130 The Marking Field is designed as: 132 The 2 currently used bits from the 8 bit Marking field are designated 133 as Mark Field (MF). 135 +-+-+-+-+-+-+-+-+ 136 | reserved | MF| 137 +-+-+-+-+-+-+-+-+ 139 Mark Field (MF) is: 141 +-+-+-+-+ 142 | S | D | 143 +-+-+-+-+ 145 1.2.1 Alternate Marking Method Operation 147 [RFC8321] describes in detail the methodology, that we briefly 148 illustrate also here. 150 1.2.1.1 Single Mark Measurement 152 As explained in the [RFC8321], marking can be applied to delineate 153 blocks of packets based either on equal number of packets in a block 154 or based on equal time interval. The latter method offers better 155 control as it allows better account for capabilities of downstream 156 nodes to report statistics related to batches of packets and, at the 157 same time, time resolution that affects defect detection interval. 159 If the Single Mark measurement used, then the D flag MUST be set to 160 zero on transmit and ignored by monitoring point. 162 The S flag is used to create alternate flows to measure the packet 163 loss by switching value of the S flag. Delay metrics MAY be 164 calculated with the alternate flow using any of the following 165 methods: 167 - First/Last Batch Packet Delay calculation: timestamps are collected 168 based on order of arrival so this method is sensitive to packet loss 169 and re-ordering. 171 - Average Packet Delay calculation: an average delay is calculated by 172 considering the average arrival time of the packets within a single 173 block. This method only provides single metric for the duration of 174 the block and it doesn't give information about the delay 175 distribution. 177 1.2.2.2 Double Mark Measurement 179 Double Mark method allows more detailed measurement of delays for the 180 monitored flow but it requires more nodal and network resources. If 181 the Double Mark method used, then the S flag MUST be used to create 182 the alternate flow. The D flag MUST be used to mark single packets 183 to measure delay jitter. 185 The first marking (S flag alternation) is needed for packet loss and 186 also for average delay measurement. The second marking (D flag is 187 put to one) creates a new set of marked packets that are fully 188 identified and dedicated for delay. This method is useful to have 189 not only the average delay but also to know more about the statistic 190 distribution of delay values. 192 1.3 IPv6 Transition Technologies 194 In the path to full implementation of IPv6, transition technologies 195 such as translation or tunneling may be employed. It is possible 196 that an IPv6 packet containing M-PDM may be dropped if using IPv6 197 transition technologies. For example, an implementation using a 198 translation technique (IPv6 to IPv4) which does not support or 199 recognize the IPv6 Destination Options extension header or a new HBH 200 option may simply drop the packet rather than translating it without 201 the extension header. 203 It is also possible that some devices in the network may not 204 correctly handle multiple IPv6 Extension Headers, including the IPv6 205 Destination Option. For example, adding the PDM header to a packet 206 may push the layer 4 information to a point in the packet where it is 207 not visible to filtering logic, and may be dropped. This kind of 208 situation is expected to become rare over time. 210 2 Measurement Information Derived from PDM 212 Each packet contains information about the sender and receiver. In IP 213 protocol, the identifying information is called a "5-tuple". 215 The 5-tuple consists of: 217 SADDR : IP address of the sender 218 SPORT : Port for sender 219 DADDR : IP address of the destination 220 DPORT : Port for destination 221 PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.) 223 The PDM contains the following base fields: 225 PSNTP : Packet Sequence Number This Packet 226 PSNLR : Packet Sequence Number Last Received 227 DELTATLR : Delta Time Last Received 228 DELTATLS : Delta Time Last Sent 230 This information, combined with the 5-tuple, allows the measurement 231 of the following metrics: 233 1. Round-trip delay 234 2. Server delay 236 These are further described in RFC8250 [RFC8250]. 238 Performance measurements described in [RFC8321] are allowed. 240 3 Marking and Performance and Diagnostic Metrics (M-PDM) Destination 241 Option Layout 243 3.1 Destination Options Header 245 The IPv6 Destination Options Header is used to carry information that 246 needs to be examined only by a packet's destination node(s). The 247 Destination Options Header is identified by a Next Header value of 60 248 in the immediately preceding header and is defined in RFC8200 249 [RFC8200]. The IPv6 Marking and Performance and Diagnostic Metrics 250 Destination Option (M-PDM) is implemented as an IPv6 Option carried 251 in the Destination Options Header. M-PDM does not require time 252 synchronization. 254 3.2 Marking and Performance and Diagnostic Metrics (M-PDM) Destination 255 Option 257 3.2.1 M-PDM Layout 259 The IPv6 Marking and Performance and Diagnostic Metrics Destination 260 Option (M-PDM) contains the following fields: 262 PSNTP : Packet Sequence Number This Packet 263 PSNLR : Packet Sequence Number Last Received 264 DELTATLR : Delta Time Last Received 265 DELTATLS : Delta Time Last Sent 267 PDM has alignment requirements. Following the convention in IPv6, 268 these options are aligned in a packet so that multi-octet values 269 within the Option Data field of each option fall on natural 270 boundaries (i.e., fields of width n octets are placed at an integer 271 multiple of n octets from the start of the header, for n = 1, 2, 4, 272 or 8) [RFC8200]. 274 The M-PDM destination option is encoded in type-length-value (TLV) 275 format as follows: 277 0 1 2 3 278 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Option Type | Option Length | Vrsn | RSVD | Marking | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | PSN This Packet | PSN Last Received | 283 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Delta Time Last Sent | Delta Time Last Received | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Option Type 288 TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780] 290 In keeping with RFC8200 [RFC8200], the two high-order bits of the 291 Option Type field are encoded to indicate specific processing of the 292 option; for the PDM destination option, these two bits MUST be set to 293 00. 295 The third high-order bit of the Option Type field specifies whether 296 or not the Option Data of that option can change en route to the 297 packet's final destination. 299 In M-PDM, the value of the third high-order bit MUST be 0. 301 Option Length 303 8-bit unsigned integer. Length of the option, in octets, excluding 304 the Option Type and Option Length fields. This field MUST be set to 305 10. 307 Version 309 4-bit unsigned integer. 311 Reserved 313 4-bit unsigned integer. 315 Marking 317 8-bit unsigned integer. (2 currently used - 6 reserved) 319 Packet Sequence Number This Packet (PSNTP) 321 16-bit unsigned integer. This field will wrap. It is intended for 322 use while analyzing packet traces. 324 This field is initialized at a random number and incremented 325 monotonically for each packet of the session flow of the IP stack. 326 The random-number initialization is intended to make it harder to 327 spoof and insert such packets. 329 Packet Sequence Number Last Received (PSNLR) 331 16-bit unsigned integer. This is the PSNTP of the packet last 332 received by the IP stack. 334 This field is initialized to 0. 336 Delta Time Last Sent (DELTATLS) 338 16-bit unsigned integer. 340 Delta Time Last Sent = (receive time packet n - send time packet (n 341 - 1)) 343 Delta Time Last Received (DELTATLR) 345 16-bit unsigned integer. 347 Delta Time Last Received = (send time packet n - receive time packet 348 (n - 1)) 350 3.2.2 Base Unit for Time Measurement 352 Fixed base. TBD. [More information needs to be added here.] 354 3.3 Header Placement 356 The M-PDM Destination Option is placed as defined in RFC8200 357 [RFC8200]. There may be a choice of where to place the Destination 358 Options header. If using ESP mode, please see section 3.4 of this 359 document for placement of the M-PDM Destination Options header. 361 For each IPv6 packet header, the M-PDM MUST NOT appear more than 362 once. However, an encapsulated packet MAY contain a separate M-PDM 363 associated with each encapsulated IPv6 header. 365 3.4 Header Placement Using IPSec ESP Mode 367 IPSec Encapsulating Security Payload (ESP) is defined in [RFC4303] 368 and is widely used. Section 3.1.1 of [RFC4303] discusses placement 369 of Destination Options Headers. 371 The placement of M-PDM is different depending on if ESP is used in 372 tunnel or transport mode. 374 In ESP case, no 5-tuple is available, as there are no port numbers. 375 ESP flow should be identified only by using SADDR, DADDR and PROTOC. 376 The SPI numbers SHOULD be ignored when considering the flow over 377 which M-PDM information is measured. 379 3.4.1 Using ESP Transport Mode 381 Note that Destination Options may be placed before or after ESP or 382 both. If using M-PDM in ESP transport mode, M-PDM MUST be placed 383 after the ESP header so as not to leak information. 385 3.4.2 Using ESP Tunnel Mode 387 Note that Destination Options may be placed before or after ESP or 388 both in both the outer set of IP headers and the inner set of IP 389 headers. A tunnel endpoint that creates a new packet may decide to 390 use M-PDM independent of the use of M-PDM of the original packet to 391 enable delay measurements between the two tunnel endpoints. 393 3.5 Implementation Considerations 395 3.5.1 M-PDM Activation 397 An implementation should provide an interface to enable or disable 398 the use of M-PDM. This specification recommends having M-PDM off by 399 default. 401 M-PDM MUST NOT be turned on merely if a packet is received with an M- 402 PDM header. The received packet could be spoofed by another device. 404 3.5.2 M-PDM Timestamps 406 The M-PDM timestamps are intended to isolate wire time from server or 407 host time, but may necessarily attribute some host processing time to 408 network latency. 410 RFC2330 [RFC2330] "Framework for IP Performance Metrics" describes 411 two notions of wire time in section 10.2. These notions are only 412 defined in terms of an Internet host H observing an Internet link L 413 at a particular location: 415 + For a given IP packet P, the 'wire arrival time' of P at H on L 416 is the first time T at which any bit of P has appeared at H's 417 observational position on L. 419 + For a given IP packet P, the 'wire exit time' of P at H on L is 420 the first time T at which all the bits of P have appeared at H's 421 observational position on L. 423 This specification does not define the exact H's observing position 424 on L. That is left for the deployment setups to define. However, the 425 position where PDM timestamps are taken SHOULD be as close to the 426 physical network interface as possible. Not all implementations will 427 be able to achieve the ideal level of measurement. 429 3.6 Dynamic Configuration Options 431 If the M-PDM destination options extension header is used, then it 432 MAY be turned on for all packets flowing through the host, applied to 433 an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP 434 address only. These are at the discretion of the implementation. 436 3.7 Information Access and Storage 438 Measurement information provided by M-PDM may be made accessible for 439 higher layers or the user itself. Similar to activating the use of M- 440 PDM, the implementation may also provide an interface to indicate if 441 received. 443 M-PDM information may be stored, if desired. If a packet with M-PDM 444 information is received and the information should be stored, the 445 upper layers may be notified. Furthermore, the implementation should 446 define a configurable maximum lifetime after which the information 447 can be removed as well as a configurable maximum amount of memory 448 that should be allocated for PDM information. 450 4 M-PDM HBH Option 452 The M-PDM Hop-by-Hop option is encoded in type-length-value (TLV) 453 format. It has an alignment requirement of 4n + 2. (See [IPv6, 454 Section 4.2] for discussion of option alignment.) The option has the 455 following format: 457 0 1 2 3 458 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Option Type | Option Length |Version|LastM |M | MType | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Middlebox Identifier | Timestamp In | 463 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Timestamp Out | PSN This Packet | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Middlebox Identifier | Timestamp In | 467 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Timestamp Out | PSN This Packet | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Middlebox Identifier | Timestamp In | 471 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Timestamp Out | PSN This Packet | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Middlebox Identifier | Timestamp In | 475 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Timestamp Out | PSN This Packet | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Middlebox Identifier | Timestamp In | 479 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Timestamp Out | PSN This Packet | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Option Type 485 TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780] 487 In keeping with RFC 8200 [RFC8200], the two high-order bits of the 488 Option Type field are encoded to indicate specific processing of the 489 option; for the M-PDM HBH option, these two bits MUST be set to 00. 491 The third high-order bit of the Option Type field specifies whether 492 or not the Option Data of that option can change en route to the 493 packet's final destination. 495 In M-PDM, the value of the third high-order bit MUST be 0. 497 Option Length 499 8-bit unsigned integer. Length of the option, in octets, excluding 500 the Option Type and Option Length fields. This field MUST be set to 501 10. 503 Version 505 4-bit unsigned integer. 507 Last Middlebox 509 4-bit unsigned integer. Indicates which middlebox number was last 510 done. For example, 3 would indicate that this is the third 511 middlebox. This field could be used to quickly find which set of 512 data to fill. If there have been more than 5 middleboxes, then 513 wrapping will happen and fields will get overwritten. 515 Marking 517 2-bit unsigned integer. 519 Marking Type (M-Type) 521 4-bit unsigned integer. This indicates the type of marking method 522 being used for the timestamp. 524 If marking is not used, then the timestamp will be when the packet 525 left the IP interface on this middlebox. 527 If marking method is used, then this field will contain: 529 1 - the timestamp of the first packet of a marked batch 2 - the 530 average timestamp of the packets of a batch 3 - a double-marked 531 packet 533 RSVD 535 2-bit unsigned integer 537 Middle Box Identifier 539 16-bit unsigned integer. 541 This field MUST be zero if not used. The zeros are intended to make 542 it harder to leak data via the HBH header. 544 This could be some portion of the IPv4 or IPv6 address or the router 545 ID. [Note to readers: any suggestions for this field are most 546 welcome!] 548 Timestamp In 550 16-bit unsigned integer. This can be the timestamp of the packet 551 received by the IP interface on this middlebox. If marking method is 552 used, it can identify the timestamp of the first packet of a marked 553 batch or the average timestamp of the packets of a batch or a double- 554 marked packet, depending on which method is used to perform delay 555 measurements. 557 This field is initialized to 0. 559 This timestamp is the delta in nanoseconds from the initial starting 560 timestamp of January 1, 2019 00:00:00.0000000000. 562 See the section on HBH Timestamps for more on this measurement. 564 Timestamp Out 566 16-bit unsigned integer. This can be the timestamp of the packet 567 left the IP interface on this middlebox. If marking method is used, 568 it can identify the timestamp of the first packet of a marked batch 569 or the average timestamp of the packets of a batch or a double-marked 570 packet, depending on which method is used to perform delay 571 measurements. 573 This field is initialized to 0. 575 This timestamp is the delta in nanoseconds from the initial starting 576 timestamp of January 1, 2019 00:00:00.0000000000. 578 See the section on HBH Timestamps for more on this measurement. 580 Packet Sequence Number This Packet (PSNTP) 582 16-bit unsigned integer. This field will wrap. It is intended for 583 use while analyzing packet traces. 585 This field is initialized at a random number and incremented 586 monotonically for each packet of the session flow of the IP stack. 588 The random-number initialization is intended to make it harder to 589 spoof and insert such packets. 591 4.1 HBH Timestamps In and Out 593 The timestamp fields will contain the 16 high-order or most 594 significant bits of the delta between a fixed starting value of 595 January 1, 2019 00:00:00.0000000000 and the current time at the 596 middlebox. 598 For more on truncation of timestamp values, please see [TCPM]. 600 5 Security Considerations 602 M-PDM may introduce some new security weaknesses. 604 5.1 Resource Consumption and Resource Consumption Attacks 606 M-PDM needs to calculate the deltas for time and keep track of the 607 sequence numbers. This means that control blocks which reside in 608 memory may be kept at the end hosts per 5-tuple. 610 A limit on how much memory is being used SHOULD be implemented. 611 Without a memory limit, any time a control block is kept in memory, 612 an attacker can try to misuse the control blocks to cause excessive 613 resource consumption. This could be used to compromise the end host. 615 M-PDM as a Destination is used at the end hosts and memory is used 616 only at the end host M-PDM as an HBH header is used at routers or 617 middle boxes. 619 5.2 Pervasive monitoring 621 Since M-PDM passes in the clear, a concern arises as to whether the 622 data can be used to fingerprint the system or somehow obtain 623 information about the contents of the payload. 625 Let us discuss fingerprinting of the end host first. It is possible 626 that seeing the pattern of deltas or the absolute values could give 627 some information as to the speed of the end host - that is, if it is 628 a very fast system or an older, slow device. This may be useful to 629 the attacker. However, if the attacker has access to PDM, the 630 attacker also has access to the entire packet and could make such a 631 deduction based merely on the time frames elapsed between packets 632 WITHOUT PDM. 634 As far as deducing the content of the payload, in terms of the 635 application level information such as web page, user name, user 636 password and so on, it appears to us that PDM is quite unhelpful in 637 this regard. Having said that, the ability to separate wire-time 638 from processing time may potentially provide an attacker with 639 additional information. It is conceivable that an attacker could 640 attempt to deduce the type of application in use by noting the server 641 time and payload length. Some encryption algorithms attempt to 642 obfuscate the packet length to avoid just such vulnerabilities. In 643 the future, encryption algorithms may wish to obfuscate the server 644 time as well. 646 5.3 M-PDM as a Covert Channel 648 PDM provides a set of fields in the packet which could be used to 649 leak data. But, there is no real reason to suspect that PDM would be 650 chosen rather than another part of the payload or another Extension 651 Header. 653 A firewall or another device could sanity check the fields within the 654 PDM but randomly assigned sequence numbers and delta times might be 655 expected to vary widely. The biggest problem though is how an 656 attacker would get access to PDM in the first place to leak data. The 657 attacker would have to either compromise the end host or have Man in 658 the Middle (MitM). It is possible that either one could change the 659 fields. But, then the other end host would get sequence numbers and 660 deltas that don't make any sense. 662 It is conceivable that someone could compromise an end host and make 663 it start sending packets with PDM without the knowledge of the host. 664 But, again, the bigger problem is the compromise of the end host. 665 Once that is done, the attacker probably has better ways to leak 666 data. 668 Having said that, if a PDM aware middle box or an implementation 669 (destination host) detects some number of "nonsensical" sequence 670 numbers or timing information, it could take action to block, 671 discard, or alert on this traffic. 673 5.4 Timing Attacks 675 The fact that PDM can help in the separation of node processing time 676 from network latency brings value to performance monitoring. Yet, it 677 is this very characteristic of PDM which may be misused to make 678 certain new type of timing attacks against protocols and 679 implementations possible. 681 Depending on the nature of the cryptographic protocol used, it may be 682 possible to leak the credentials of the device. For example, if an 683 attacker can see that PDM is being used, then the attacker might use 684 PDM to launch a timing attack against the keying material used by the 685 cryptographic protocol. 687 An implementation may want to be sure that PDM is enabled only for 688 certain ip addresses, or only for some ports. Additionally, the 689 implementation SHOULD require an explicit restart of monitoring after 690 a certain time period (for example for 1 hour), to make sure that PDM 691 is not accidentally left on after debugging has been done etc. 693 Even so, if using PDM, a user "Consent to be Measured" SHOULD be a 694 pre-requisite for using PDM. Consent is common in enterprises and 695 with some subscription services. The actual content of "Consent to 696 be Measured" will differ by site but it SHOULD make clear that the 697 traffic is being measured for quality of service and to assist in 698 diagnostics as well as to make clear that there may be potential 699 risks of certain vulnerabilities if the traffic is captured during a 700 diagnostic session. 702 6 IANA Considerations 704 This draft requests an Destination Option Type assignment with the 705 act bits set to 00 and the chg bit set to 0 from the Destination 706 Options and Hop-by-Hop Options sub-registry of Internet Protocol 707 Version 6 (IPv6) Parameters [ref to RFCs and URL below. 709 http://www.iana.org/assignments/ipv6-parameters/ipv6- 710 parameters.xhtml#ipv6-parameters-2 712 Hex Value Binary Value Description Reference 713 act chg rest 714 ------------------------------------------------------------------- 715 TBD TBD Performance and [This draft] 716 Diagnostic Metrics 717 (M-PDM) 719 7 References 721 7.1 Normative References 723 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 724 Requirement Levels", BCP 14, RFC 2119, March 1997. 726 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines 727 For Values In the Internet Protocol and Related Headers", BCP 37, RFC 728 2780, March 2000. 730 [RFC4303] Kent, S, "IP Encapsulating Security Payload (ESP)", RFC 731 4303, December 2005. 733 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 734 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 735 2017, . 737 [RFC8250] Elkins, N., Ackermann, M. and Hamilton, R. "IPv6 738 Performance and Diagnostic Metrics (PDM) Destination Option", RFC 739 8250, September 2017. 741 7.2 Informative References 743 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 744 "Framework for IP Performance Metrics", RFC 2330, May 1998. 746 [RFC8321] Fioccola, G. et al, "Alternate-Marking Method for Passive 747 and Hybrid Performance Monitoring", RFC 8321, January 2018. 749 [TCPM] Scheffenegger, R., Kuehlewind, M., and B. Trammell, "Encoding 750 of Time Intervals for the TCP Timestamp Option", Work in Progress, 751 draft-trammell-tcpm-timestamp-interval-01, July 2013 753 Acknowledgments 755 The authors would like to C.M. Heard for his review. 757 Authors' Addresses 759 Nalini Elkins 760 Inside Products, Inc. 761 36A Upper Circle 762 Carmel Valley, CA 93924 763 United States 764 Phone: +1 831 659 8360 765 Email: nalini.elkins@insidethestack.com 766 http://www.insidethestack.com 768 Giuseppe Fioccola 769 Telecom Italia 770 Via Reiss Romoli, 274 771 Torino 10148 772 Italy 773 Email: giuseppe.fioccola@telecomitalia.it 775 Michael S. Ackermann 776 Blue Cross Blue Shield of Michigan 777 P.O. Box 2888 778 Detroit, Michigan 48231 779 United States 780 Phone: +1 310 460 4080 781 Email: mackermann@bcbsm.com 783 Robert M. Hamilton 784 Chemical Abstracts Service 785 A Division of the American Chemical Society 786 2540 Olentangy River Road 787 Columbus, Ohio 43202 788 United States of America 789 Phone: +1 614 447 3600 x2517 790 Email: rhamilton@cas.org