idnits 2.17.1 draft-fear-ippm-mpdm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 25, 2018) is 2124 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: December 27, 2018 June 25, 2018 12 IPv6 Marking and Performance and Diagnostic Metrics (MPDM) 13 draft-fear-ippm-mpdm-01 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 . . . . . . . . . . . . . . . . . 11 80 3.5 Implementation Considerations . . . . . . . . . . . . . . . 11 81 3.5.1 M-PDM Activation . . . . . . . . . . . . . . . . . . . . 11 82 3.5.2 M-PDM Timestamps . . . . . . . . . . . . . . . . . . . . 11 83 3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 12 84 3.7 Information Access and Storage . . . . . . . . . . . . . . . 12 85 4 M-PDM HBH Option . . . . . . . . . . . . . . . . . . . . . . . . 13 86 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 16 87 5.1 Resource Consumption and Resource Consumption Attacks . . . 16 88 5.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . . 16 89 5.3 M-PDM as a Covert Channel . . . . . . . . . . . . . . . . . 17 90 5.4 Timing Attacks . . . . . . . . . . . . . . . . . . . . . . . 17 91 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18 92 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 94 7.2 Informative References . . . . . . . . . . . . . . . . . . . 19 95 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 98 1 Background 100 To assess performance problems, measurements based on marking, 101 sequence numbers and timing may be embedded in each packet. Such 102 measurements may be interpreted in real-time or after the fact. 104 As defined in RFC8200 [RFC8200], destination options are carried by 105 the IPv6 Destination Options extension header. Destination options 106 include information that need be examined only by the IPv6 node given 107 as the destination address in the IPv6 header, not by routers or 108 "middle boxes". 110 RFC8200 [RFC8200] additionally defines the IPv6 Hop-by-Hop (HBH) 111 Options extension header. This header may be processed and examined 112 by end nodes, routers and "middle boxes". 114 This document specifies both the Marking Performance and Diagnostic 115 Metrics (M-PDM) destination option as well as the M-PDM HBH Option. 117 1.1 Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 1.2 Rationale for defined solution 125 The M-PDM Destination Option and M-PDM Hop-By-Hop Option are a 126 combining of PDM [RFC8250] with Marking [RFC8321] to obtain path and 127 middle box information. 129 The Marking Field is designed as: 131 The 2 currently used bits from the 8 bit Marking field are designated 132 as Mark Field (MF). 134 +-+-+-+-+-+-+-+-+ 135 | reserved | MF| 136 +-+-+-+-+-+-+-+-+ 138 Mark Field (MF) is: 140 +-+-+-+-+ 141 | S | D | 142 +-+-+-+-+ 144 1.2.1 Alternate Marking Method Operation 146 [RFC8321] describes in detail the methodology, that we briefly 147 illustrate also here. 149 1.2.1.1 Single Mark Measurement 151 As explained in the [RFC8321], marking can be applied to delineate 152 blocks of packets based either on equal number of packets in a block 153 or based on equal time interval. The latter method offers better 154 control as it allows better account for capabilities of downstream 155 nodes to report statistics related to batches of packets and, at the 156 same time, time resolution that affects defect detection interval. 158 If the Single Mark measurement used, then the D flag MUST be set to 159 zero on transmit and ignored by monitoring point. 161 The S flag is used to create alternate flows to measure the packet 162 loss by switching value of the S flag. Delay metrics MAY be 163 calculated with the alternate flow using any of the following 164 methods: 166 - First/Last Batch Packet Delay calculation: timestamps are collected 167 based on order of arrival so this method is sensitive to packet loss 168 and re-ordering. 170 - Average Packet Delay calculation: an average delay is calculated by 171 considering the average arrival time of the packets within a single 172 block. This method only provides single metric for the duration of 173 the block and it doesn't give information about the delay 174 distribution. 176 1.2.2.2 Double Mark Measurement 178 Double Mark method allows more detailed measurement of delays for the 179 monitored flow but it requires more nodal and network resources. If 180 the Double Mark method used, then the S flag MUST be used to create 181 the alternate flow. The D flag MUST be used to mark single packets 182 to measure delay jitter. 184 The first marking (S flag alternation) is needed for packet loss and 185 also for average delay measurement. The second marking (D flag is 186 put to one) creates a new set of marked packets that are fully 187 identified and dedicated for delay. This method is useful to have 188 not only the average delay but also to know more about the statistic 189 distribution of delay values. 191 1.3 IPv6 Transition Technologies 193 In the path to full implementation of IPv6, transition technologies 194 such as translation or tunneling may be employed. It is possible 195 that an IPv6 packet containing M-PDM may be dropped if using IPv6 196 transition technologies. For example, an implementation using a 197 translation technique (IPv6 to IPv4) which does not support or 198 recognize the IPv6 Destination Options extension header or a new HBH 199 option may simply drop the packet rather than translating it without 200 the extension header. 202 It is also possible that some devices in the network may not 203 correctly handle multiple IPv6 Extension Headers, including the IPv6 204 Destination Option. For example, adding the PDM header to a packet 205 may push the layer 4 information to a point in the packet where it is 206 not visible to filtering logic, and may be dropped. This kind of 207 situation is expected to become rare over time. 209 2 Measurement Information Derived from PDM 211 Each packet contains information about the sender and receiver. In IP 212 protocol, the identifying information is called a "5-tuple". 214 The 5-tuple consists of: 216 SADDR : IP address of the sender 217 SPORT : Port for sender 218 DADDR : IP address of the destination 219 DPORT : Port for destination 220 PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.) 222 The PDM contains the following base fields: 224 PSNTP : Packet Sequence Number This Packet 225 PSNLR : Packet Sequence Number Last Received 226 DELTATLR : Delta Time Last Received 227 DELTATLS : Delta Time Last Sent 229 This information, combined with the 5-tuple, allows the measurement 230 of the following metrics: 232 1. Round-trip delay 233 2. Server delay 235 These are further described in RFC8250 [RFC8250]. 237 Performance measurements described in [RFC8321] are allowed. 239 3 Marking and Performance and Diagnostic Metrics (M-PDM) Destination 240 Option Layout 242 3.1 Destination Options Header 244 The IPv6 Destination Options Header is used to carry information that 245 needs to be examined only by a packet's destination node(s). The 246 Destination Options Header is identified by a Next Header value of 60 247 in the immediately preceding header and is defined in RFC8200 248 [RFC8200]. The IPv6 Marking and Performance and Diagnostic Metrics 249 Destination Option (M-PDM) is implemented as an IPv6 Option carried 250 in the Destination Options Header. M-PDM does not require time 251 synchronization. 253 3.2 Marking and Performance and Diagnostic Metrics (M-PDM) Destination 254 Option 256 3.2.1 M-PDM Layout 258 The IPv6 Marking and Performance and Diagnostic Metrics Destination 259 Option (M-PDM) contains the following fields: 261 PSNTP : Packet Sequence Number This Packet 262 PSNLR : Packet Sequence Number Last Received 263 DELTATLR : Delta Time Last Received 264 DELTATLS : Delta Time Last Sent 266 PDM has alignment requirements. Following the convention in IPv6, 267 these options are aligned in a packet so that multi-octet values 268 within the Option Data field of each option fall on natural 269 boundaries (i.e., fields of width n octets are placed at an integer 270 multiple of n octets from the start of the header, for n = 1, 2, 4, 271 or 8) [RFC8200]. 273 The M-PDM destination option is encoded in type-length-value (TLV) 274 format as follows: 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Option Type | Option Length | Vrsn | RSVD | Marking | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | PSN This Packet | PSN Last Received | 282 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Delta Time Last Sent | Delta Time Last Received | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Option Type 287 TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780] 289 In keeping with RFC8200 [RFC8200], the two high-order bits of the 290 Option Type field are encoded to indicate specific processing of the 291 option; for the PDM destination option, these two bits MUST be set to 292 00. 294 The third high-order bit of the Option Type field specifies whether 295 or not the Option Data of that option can change en route to the 296 packet's final destination. 298 In M-PDM, the value of the third high-order bit MUST be 0. 300 Option Length 302 8-bit unsigned integer. Length of the option, in octets, excluding 303 the Option Type and Option Length fields. This field MUST be set to 304 10. 306 Version 308 4-bit unsigned integer. 310 Reserved 312 4-bit unsigned integer. 314 Marking 316 8-bit unsigned integer. (2 currently used - 6 reserved) 318 Packet Sequence Number This Packet (PSNTP) 320 16-bit unsigned integer. This field will wrap. It is intended for 321 use while analyzing packet traces. 323 This field is initialized at a random number and incremented 324 monotonically for each packet of the session flow of the IP stack. 325 The random-number initialization is intended to make it harder to 326 spoof and insert such packets. 328 Packet Sequence Number Last Received (PSNLR) 330 16-bit unsigned integer. This is the PSNTP of the packet last 331 received by the IP stack. 333 This field is initialized to 0. 335 Delta Time Last Sent (DELTATLS) 337 16-bit unsigned integer. 339 Delta Time Last Sent = (receive time packet n - send time packet (n 340 - 1)) 342 Delta Time Last Received (DELTATLR) 344 16-bit unsigned integer. 346 Delta Time Last Received = (send time packet n - receive time packet 347 (n - 1)) 349 3.2.2 Base Unit for Time Measurement 351 Fixed base. TBD. [More information needs to be added here.] 353 3.3 Header Placement 355 The M-PDM Destination Option is placed as defined in RFC8200 356 [RFC8200]. There may be a choice of where to place the Destination 357 Options header. If using ESP mode, please see section 3.4 of this 358 document for placement of the M-PDM Destination Options header. 360 For each IPv6 packet header, the M-PDM MUST NOT appear more than 361 once. However, an encapsulated packet MAY contain a separate M-PDM 362 associated with each encapsulated IPv6 header. 364 3.4 Header Placement Using IPSec ESP Mode 366 IPSec Encapsulating Security Payload (ESP) is defined in [RFC4303] 367 and is widely used. Section 3.1.1 of [RFC4303] discusses placement 368 of Destination Options Headers. 370 The placement of M-PDM is different depending on if ESP is used in 371 tunnel or transport mode. 373 In ESP case, no 5-tuple is available, as there are no port numbers. 374 ESP flow should be identified only by using SADDR, DADDR and PROTOC. 375 The SPI numbers SHOULD be ignored when considering the flow over 376 which M-PDM information is measured. 378 3.4.1 Using ESP Transport Mode 380 Note that Destination Options may be placed before or after ESP or 381 both. If using M-PDM in ESP transport mode, M-PDM MUST be placed 382 after the ESP header so as not to leak information. 384 3.4.2 Using ESP Tunnel Mode 386 Note that Destination Options may be placed before or after ESP or 387 both in both the outer set of IP headers and the inner set of IP 388 headers. A tunnel endpoint that creates a new packet may decide to 389 use M-PDM independent of the use of M-PDM of the original packet to 390 enable delay measurements between the two tunnel endpoints. 392 3.5 Implementation Considerations 394 3.5.1 M-PDM Activation 396 An implementation should provide an interface to enable or disable 397 the use of M-PDM. This specification recommends having M-PDM off by 398 default. 400 M-PDM MUST NOT be turned on merely if a packet is received with an M- 401 PDM header. The received packet could be spoofed by another device. 403 3.5.2 M-PDM Timestamps 405 The M-PDM timestamps are intended to isolate wire time from server or 406 host time, but may necessarily attribute some host processing time to 407 network latency. 409 RFC2330 [RFC2330] "Framework for IP Performance Metrics" describes 410 two notions of wire time in section 10.2. These notions are only 411 defined in terms of an Internet host H observing an Internet link L 412 at a particular location: 414 + For a given IP packet P, the 'wire arrival time' of P at H on L 415 is the first time T at which any bit of P has appeared at H's 416 observational position on L. 418 + For a given IP packet P, the 'wire exit time' of P at H on L is 419 the first time T at which all the bits of P have appeared at H's 420 observational position on L. 422 This specification does not define the exact H's observing position 423 on L. That is left for the deployment setups to define. However, the 424 position where PDM timestamps are taken SHOULD be as close to the 425 physical network interface as possible. Not all implementations will 426 be able to achieve the ideal level of measurement. 428 3.6 Dynamic Configuration Options 430 If the M-PDM destination options extension header is used, then it 431 MAY be turned on for all packets flowing through the host, applied to 432 an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP 433 address only. These are at the discretion of the implementation. 435 3.7 Information Access and Storage 437 Measurement information provided by M-PDM may be made accessible for 438 higher layers or the user itself. Similar to activating the use of M- 439 PDM, the implementation may also provide an interface to indicate if 440 received 442 M-PDM information may be stored, if desired. If a packet with M-PDM 443 information is received and the information should be stored, the 444 upper layers may be notified. Furthermore, the implementation should 445 define a configurable maximum lifetime after which the information 446 can be removed as well as a configurable maximum amount of memory 447 that should be allocated for PDM information. 449 4 M-PDM HBH Option 451 The M-PDM Hop-by-Hop option is encoded in type-length-value (TLV) 452 format. It has an alignment requirement of 4n + 2. (See [IPv6, 453 Section 4.2] for discussion of option alignment.) The option has the 454 following format: 456 0 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Option Type | Option Length |Version|LastM |M | MType | | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Middlebox Identifier | Timestamp In | 462 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Timestamp Out | PSN This Packet | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Middlebox Identifier | Timestamp In | 466 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Timestamp Out | PSN This Packet | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Middlebox Identifier | Timestamp In | 470 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Timestamp Out | PSN This Packet | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Middlebox Identifier | Timestamp In | 474 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Timestamp Out | PSN This Packet | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Middlebox Identifier | Timestamp In | 478 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Timestamp Out | PSN This Packet | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 Option Type 484 TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780] 486 In keeping with RFC 8200 [RFC8200], the two high-order bits of the 487 Option Type field are encoded to indicate specific processing of the 488 option; for the M-PDM HBH option, these two bits MUST be set to 00. 490 The third high-order bit of the Option Type field specifies whether 491 or not the Option Data of that option can change en route to the 492 packet's final destination. 494 In M-PDM, the value of the third high-order bit MUST be 0. 496 Option Length 498 8-bit unsigned integer. Length of the option, in octets, excluding 499 the Option Type and Option Length fields. This field MUST be set to 500 10. 502 Version 504 4-bit unsigned integer. 506 Last Middlebox 508 4-bit unsigned integer. Indicates which middlebox number was last 509 done. For example, 3 would indicate that this is the third 510 middlebox. This field could be used to quickly find which set of 511 data to fill. If there have been more than 5 middleboxes, then 512 wrapping will happen and fields will get overwritten. 514 Marking 516 2-bit unsigned integer. 518 Marking Type (M-Type) 520 4-bit unsigned integer. This indicates the type of marking method 521 being used for the timestamp. 523 If marking is not used, then the timestamp will be when the packet 524 left the IP interface on this middlebox. 526 If marking method is used, then this field will contain: 528 1 - the timestamp of the first packet of a marked batch 2 - the 529 average timestamp of the packets of a batch 3 - a double-marked 530 packet 532 RSVD 534 2-bit unsigned integer 535 Middle Box Identifier 537 16-bit unsigned integer. 539 This field MUST be zero if not used. The zeros are intended to make 540 it harder to leak data via the HBH header. 542 This could be some portion of the IPv4 or IPv6 address or the router 543 ID. [Note to readers: any suggestions for this field are most 544 welcome!] 546 Timestamp In 548 16-bit unsigned integer. This can be the timestamp of the packet 549 received by the IP interface on this middlebox. If marking method is 550 used, it can identify the timestamp of the first packet of a marked 551 batch or the average timestamp of the packets of a batch or a double- 552 marked packet, depending on which method is used to perform delay 553 measurements. 555 This field is initialized to 0. 557 Timestamp Out 559 16-bit unsigned integer. This can be the timestamp of the packet 560 left the IP interface on this middlebox. If marking method is used, 561 it can identify the timestamp of the first packet of a marked batch 562 or the average timestamp of the packets of a batch or a double-marked 563 packet, depending on which method is used to perform delay 564 measurements. 566 This field is initialized to 0. 568 Packet Sequence Number This Packet (PSNTP) 570 16-bit unsigned integer. This field will wrap. It is intended for 571 use while analyzing packet traces. 573 This field is initialized at a random number and incremented 574 monotonically for each packet of the session flow of the IP stack. 575 The random-number initialization is intended to make it harder to 576 spoof and insert such packets. 578 5 Security Considerations 580 M-PDM may introduce some new security weaknesses. 582 5.1 Resource Consumption and Resource Consumption Attacks 584 M-PDM needs to calculate the deltas for time and keep track of the 585 sequence numbers. This means that control blocks which reside in 586 memory may be kept at the end hosts per 5-tuple. 588 A limit on how much memory is being used SHOULD be implemented. 589 Without a memory limit, any time a control block is kept in memory, 590 an attacker can try to misuse the control blocks to cause excessive 591 resource consumption. This could be used to compromise the end host. 593 M-PDM as a Destination is used at the end hosts and memory is used 594 only at the end host M-PDM as an HBH header is used at routers or 595 middle boxes. 597 5.2 Pervasive monitoring 599 Since M-PDM passes in the clear, a concern arises as to whether the 600 data can be used to fingerprint the system or somehow obtain 601 information about the contents of the payload. 603 Let us discuss fingerprinting of the end host first. It is possible 604 that seeing the pattern of deltas or the absolute values could give 605 some information as to the speed of the end host - that is, if it is 606 a very fast system or an older, slow device. This may be useful to 607 the attacker. However, if the attacker has access to PDM, the 608 attacker also has access to the entire packet and could make such a 609 deduction based merely on the time frames elapsed between packets 610 WITHOUT PDM. 612 As far as deducing the content of the payload, in terms of the 613 application level information such as web page, user name, user 614 password and so on, it appears to us that PDM is quite unhelpful in 615 this regard. Having said that, the ability to separate wire-time 616 from processing time may potentially provide an attacker with 617 additional information. It is conceivable that an attacker could 618 attempt to deduce the type of application in use by noting the server 619 time and payload length. Some encryption algorithms attempt to 620 obfuscate the packet length to avoid just such vulnerabilities. In 621 the future, encryption algorithms may wish to obfuscate the server 622 time as well. 624 5.3 M-PDM as a Covert Channel 626 PDM provides a set of fields in the packet which could be used to 627 leak data. But, there is no real reason to suspect that PDM would be 628 chosen rather than another part of the payload or another Extension 629 Header. 631 A firewall or another device could sanity check the fields within the 632 PDM but randomly assigned sequence numbers and delta times might be 633 expected to vary widely. The biggest problem though is how an 634 attacker would get access to PDM in the first place to leak data. The 635 attacker would have to either compromise the end host or have Man in 636 the Middle (MitM). It is possible that either one could change the 637 fields. But, then the other end host would get sequence numbers and 638 deltas that don't make any sense. 640 It is conceivable that someone could compromise an end host and make 641 it start sending packets with PDM without the knowledge of the host. 642 But, again, the bigger problem is the compromise of the end host. 643 Once that is done, the attacker probably has better ways to leak 644 data. 646 Having said that, if a PDM aware middle box or an implementation 647 (destination host) detects some number of "nonsensical" sequence 648 numbers or timing information, it could take action to block, 649 discard, or alert on this traffic. 651 5.4 Timing Attacks 653 The fact that PDM can help in the separation of node processing time 654 from network latency brings value to performance monitoring. Yet, it 655 is this very characteristic of PDM which may be misused to make 656 certain new type of timing attacks against protocols and 657 implementations possible. 659 Depending on the nature of the cryptographic protocol used, it may be 660 possible to leak the credentials of the device. For example, if an 661 attacker can see that PDM is being used, then the attacker might use 662 PDM to launch a timing attack against the keying material used by the 663 cryptographic protocol. 665 An implementation may want to be sure that PDM is enabled only for 666 certain ip addresses, or only for some ports. Additionally, the 667 implementation SHOULD require an explicit restart of monitoring after 668 a certain time period (for example for 1 hour), to make sure that PDM 669 is not accidentally left on after debugging has been done etc. 671 Even so, if using PDM, a user "Consent to be Measured" SHOULD be a 672 pre-requisite for using PDM. Consent is common in enterprises and 673 with some subscription services. The actual content of "Consent to 674 be Measured" will differ by site but it SHOULD make clear that the 675 traffic is being measured for quality of service and to assist in 676 diagnostics as well as to make clear that there may be potential 677 risks of certain vulnerabilities if the traffic is captured during a 678 diagnostic session. 680 6 IANA Considerations 682 This draft requests an Destination Option Type assignment with the 683 act bits set to 00 and the chg bit set to 0 from the Destination 684 Options and Hop-by-Hop Options sub-registry of Internet Protocol 685 Version 6 (IPv6) Parameters [ref to RFCs and URL below. 687 http://www.iana.org/assignments/ipv6-parameters/ipv6- 688 parameters.xhtml#ipv6-parameters-2 690 Hex Value Binary Value Description Reference 691 act chg rest 692 ------------------------------------------------------------------- 693 TBD TBD Performance and [This draft] 694 Diagnostic Metrics 695 (PDM) 697 7 References 699 7.1 Normative References 701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 702 Requirement Levels", BCP 14, RFC 2119, March 1997. 704 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines 705 For Values In the Internet Protocol and Related Headers", BCP 37, RFC 706 2780, March 2000. 708 [RFC4303] Kent, S, "IP Encapsulating Security Payload (ESP)", RFC 709 4303, December 2005. 711 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 712 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 713 2017, . 715 [RFC8250] Elkins, N., Ackermann, M. and Hamilton, R. "IPv6 716 Performance and Diagnostic Metrics (PDM) Destination Option", RFC 717 8250, September 2017. 719 7.2 Informative References 721 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 722 "Framework for IP Performance Metrics", RFC 2330, May 1998. 724 [RFC8321] Fioccola, G. et al, "Alternate-Marking Method for Passive 725 and Hybrid Performance Monitoring", RFC 8321, January 2018. 727 Acknowledgments 729 The authors would like to C.M. Heard for his review. 731 Authors' Addresses 733 Nalini Elkins 734 Inside Products, Inc. 735 36A Upper Circle 736 Carmel Valley, CA 93924 737 United States 738 Phone: +1 831 659 8360 739 Email: nalini.elkins@insidethestack.com 740 http://www.insidethestack.com 742 Giuseppe Fioccola 743 Telecom Italia 744 Via Reiss Romoli, 274 745 Torino 10148 746 Italy 747 Email: giuseppe.fioccola@telecomitalia.it 749 Michael S. Ackermann 750 Blue Cross Blue Shield of Michigan 751 P.O. Box 2888 752 Detroit, Michigan 48231 753 United States 754 Phone: +1 310 460 4080 755 Email: mackermann@bcbsm.com 757 Robert M. Hamilton 758 Chemical Abstracts Service 759 A Division of the American Chemical Society 760 2540 Olentangy River Road 761 Columbus, Ohio 43202 762 United States of America 763 Phone: +1 614 447 3600 x2517 764 Email: rhamilton@cas.org