idnits 2.17.1 draft-fear-ippm-mpdm-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: ---------------------------------------------------------------------------- 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 1, 2018) is 2154 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 Intended Status: Proposed Standard BCBS Michigan 8 Expires: December 2, 2018 June 1, 2018 10 IPv6 Marking and Performance and Diagnostic Metrics (MPDM) 11 draft-fear-ippm-mpdm-00 13 Abstract 15 To assess performance problems, this document describes optional 16 headers embedded in each packet that provide marking, sequence 17 numbers and timing information as a basis for measurements. Such 18 measurements may be interpreted in real-time or after the fact. This 19 document specifies the IPv6 Marking and Performance and Diagnostic 20 Metrics (M-PDM) Hop-byHop and Destination Options extension headers. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 49 3: This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.2 Rationale for defined solution . . . . . . . . . . . . . . . 4 64 1.3 IPv6 Transition Technologies . . . . . . . . . . . . . . . . 4 65 2 Measurement Information Derived from PDM . . . . . . . . . . . . 5 66 3 Marking and Performance and Diagnostic Metrics (M-PDM) 67 Destination Option Layout . . . . . . . . . . . . . . . . . . . 5 68 3.1 Destination Options Header . . . . . . . . . . . . . . . . . 5 69 3.2 Marking and Performance and Diagnostic Metrics (M-PDM) 70 Destination Option . . . . . . . . . . . . . . . . . . . . . 5 71 3.2.1 M-PDM Layout . . . . . . . . . . . . . . . . . . . . . . 5 72 3.2.2 Base Unit for Time Measurement . . . . . . . . . . . . . 8 73 3.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 8 74 3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 9 75 3.4.1 Using ESP Transport Mode . . . . . . . . . . . . . . . . 9 76 3.4.2 Using ESP Tunnel Mode . . . . . . . . . . . . . . . . . 9 77 3.5 Implementation Considerations . . . . . . . . . . . . . . . 9 78 3.5.1 M-PDM Activation . . . . . . . . . . . . . . . . . . . . 9 79 3.5.2 M-PDM Timestamps . . . . . . . . . . . . . . . . . . . . 9 80 3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 10 81 3.7 Information Access and Storage . . . . . . . . . . . . . . . 10 82 4 M-PDM HBH Extension Header . . . . . . . . . . . . . . . . . . . 10 83 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 84 5.1 Resource Consumption and Resource Consumption Attacks . . . 12 85 5.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . . 13 86 5.3 M-PDM as a Covert Channel . . . . . . . . . . . . . . . . . 13 87 5.4 Timing Attacks . . . . . . . . . . . . . . . . . . . . . . . 14 88 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 89 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 91 7.2 Informative References . . . . . . . . . . . . . . . . . . . 15 92 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 95 1 Background 97 To assess performance problems, measurements based on marking, 98 sequence numbers and timing may be embedded in each packet. Such 99 measurements may be interpreted in real-time or after the fact. 101 As defined in RFC8200 [RFC8200], destination options are carried by 102 the IPv6 Destination Options extension header. Destination options 103 include information that need be examined only by the IPv6 node given 104 as the destination address in the IPv6 header, not by routers or 105 "middle boxes". 107 RFC8200 [RFC8200] additionally defines the IPv6 Hop-by-Hop (HBH) 108 extension header. This header may be processed and examined by 109 routers and "middle boxes". 111 This document specifies both the Marking Performance and Diagnostic 112 Metrics (M-PDM) destination option as well as the M-PDM HBH extension 113 header. 115 1.1 Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 1.2 Rationale for defined solution 123 1.3 IPv6 Transition Technologies 125 In the path to full implementation of IPv6, transition technologies 126 such as translation or tunneling may be employed. It is possible 127 that an IPv6 packet containing M-PDM may be dropped if using IPv6 128 transition technologies. For example, an implementation using a 129 translation technique (IPv6 to IPv4) which does not support or 130 recognize the IPv6 Destination Options extension header may simply 131 drop the packet rather than translating it without the extension 132 header. 134 [Note to ourselves: what to do about HBH and transition technologies] 136 It is also possible that some devices in the network may not 137 correctly handle multiple IPv6 Extension Headers, including the IPv6 138 Destination Option. For example, adding the PDM header to a packet 139 may push the layer 4 information to a point in the packet where it is 140 not visible to filtering logic, and may be dropped. This kind of 141 situation is expected to become rare over time. 143 2 Measurement Information Derived from PDM 145 Each packet contains information about the sender and receiver. In IP 146 protocol, the identifying information is called a "5-tuple". 148 The 5-tuple consists of: 150 SADDR : IP address of the sender 151 SPORT : Port for sender 152 DADDR : IP address of the destination 153 DPORT : Port for destination 154 PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.) 156 The PDM contains the following base fields: 158 PSNTP : Packet Sequence Number This Packet 159 PSNLR : Packet Sequence Number Last Received 160 DELTATLR : Delta Time Last Received 161 DELTATLS : Delta Time Last Sent 163 This information, combined with the 5-tuple, allows the measurement 164 of the following metrics: 166 1. Round-trip delay 167 2. Server delay 169 These are further described in RFC8250 [RFC8250]. 171 Performance measurements described in [RFC8321] are allowed. 173 3 Marking and Performance and Diagnostic Metrics (M-PDM) Destination 174 Option Layout 176 3.1 Destination Options Header 178 The IPv6 Destination Options Header is used to carry information that 179 needs to be examined only by a packet's destination node(s). The 180 Destination Options Header is identified by a Next Header value of 60 181 in the immediately preceding header and is defined in RFC8200 182 [RFC8200]. The IPv6 Marking and Performance and Diagnostic Metrics 183 Destination Option (M-PDM) is implemented as an IPv6 Option carried 184 in the Destination Options Header. M-PDM does not require time 185 synchronization. 187 3.2 Marking and Performance and Diagnostic Metrics (M-PDM) Destination 188 Option 190 3.2.1 M-PDM Layout 192 The IPv6 Marking and Performance and Diagnostic Metrics Destination 193 Option (M-PDM) contains the following fields: 195 PSNTP : Packet Sequence Number This Packet 196 PSNLR : Packet Sequence Number Last Received 197 DELTATLR : Delta Time Last Received 198 DELTATLS : Delta Time Last Sent 200 PDM has alignment requirements. Following the convention in IPv6, 201 these options are aligned in a packet so that multi-octet values 202 within the Option Data field of each option fall on natural 203 boundaries (i.e., fields of width n octets are placed at an integer 204 multiple of n octets from the start of the header, for n = 1, 2, 4, 205 or 8) [RFC8200]. 207 The M-PDM destination option is encoded in type-length-value (TLV) 208 format as follows: 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Option Type | Option Length | Vrsn | RSVD | Marking | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | PSN This Packet | PSN Last Received | 216 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Delta Time Last Sent | Delta Time Last Received | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Option Type 222 0x0F 224 In keeping with RFC8200 [RFC8200], the two high-order bits of the 225 Option Type field are encoded to indicate specific processing of the 226 option; for the PDM destination option, these two bits MUST be set to 227 00. 229 The third high-order bit of the Option Type field specifies whether 230 or not the Option Data of that option can change en route to the 231 packet's final destination. 233 In M-PDM, the value of the third high-order bit MUST be 0. 235 Option Length 237 8-bit unsigned integer. Length of the option, in octets, excluding 238 the Option Type and Option Length fields. This field MUST be set to 239 10. 241 Version 243 4-bit unsigned integer. 245 Reserved 247 4-bit unsigned integer. 249 Marking 251 8-bit unsigned integer. (2 currently used - 6 reserved) 253 Packet Sequence Number This Packet (PSNTP) 255 16-bit unsigned integer. This field will wrap. It is intended for 256 use while analyzing packet traces. 258 This field is initialized at a random number and incremented 259 monotonically for each packet of the session flow of the IP stack. 260 The random-number initialization is intended to make it harder to 261 spoof and insert such packets. 263 Packet Sequence Number Last Received (PSNLR) 265 16-bit unsigned integer. This is the PSNTP of the packet last 266 received by the IP stack. 268 This field is initialized to 0. 270 Delta Time Last Sent (DELTATLS) 272 16-bit unsigned integer. 274 Delta Time Last Sent = (receive time packet n - send time packet (n 275 - 1)) 277 Delta Time Last Received (DELTATLR) 279 16-bit unsigned integer. 281 Delta Time Last Received = (send time packet n - receive time packet 282 (n - 1)) 284 3.2.2 Base Unit for Time Measurement 286 Fixed base. TBD. 288 3.3 Header Placement 290 The M-PDM Destination Option is placed as defined in RFC8200 291 [RFC8200]. There may be a choice of where to place the Destination 292 Options header. If using ESP mode, please see section 3.4 of this 293 document for placement of the M-PDM Destination Options header. 295 For each IPv6 packet header, the M-PDM MUST NOT appear more than 296 once. However, an encapsulated packet MAY contain a separate M-PDM 297 associated with each encapsulated IPv6 header. 299 3.4 Header Placement Using IPSec ESP Mode 301 IPSec Encapsulating Security Payload (ESP) is defined in [RFC4303] 302 and is widely used. Section 3.1.1 of [RFC4303] discusses placement 303 of Destination Options Headers. 305 The placement of M-PDM is different depending on if ESP is used in 306 tunnel or transport mode. 308 In ESP case, no 5-tuple is available, as there are no port numbers. 309 ESP flow should be identified only by using SADDR, DADDR and PROTOC. 310 The SPI numbers SHOULD be ignored when considering the flow over 311 which M-PDM information is measured. 313 3.4.1 Using ESP Transport Mode 315 Note that Destination Options may be placed before or after ESP or 316 both. If using M-PDM in ESP transport mode, M-PDM MUST be placed 317 after the ESP header so as not to leak information. 319 3.4.2 Using ESP Tunnel Mode 321 Note that Destination Options may be placed before or after ESP or 322 both in both the outer set of IP headers and the inner set of IP 323 headers. A tunnel endpoint that creates a new packet may decide to 324 use M-PDM independent of the use of M-PDM of the original packet to 325 enable delay measurements between the two tunnel endpoints. 327 3.5 Implementation Considerations 329 3.5.1 M-PDM Activation 331 An implementation should provide an interface to enable or disable 332 the use of M-PDM. This specification recommends having M-PDM off by 333 default. 335 M-PDM MUST NOT be turned on merely if a packet is received with an M- 336 PDM header. The received packet could be spoofed by another device. 338 3.5.2 M-PDM Timestamps 340 The M-PDM timestamps are intended to isolate wire time from server or 341 host time, but may necessarily attribute some host processing time to 342 network latency. 344 RFC2330 [RFC2330] "Framework for IP Performance Metrics" describes 345 two notions of wire time in section 10.2. These notions are only 346 defined in terms of an Internet host H observing an Internet link L 347 at a particular location: 349 + For a given IP packet P, the 'wire arrival time' of P at H on L 350 is the first time T at which any bit of P has appeared at H's 351 observational position on L. 353 + For a given IP packet P, the 'wire exit time' of P at H on L is 354 the first time T at which all the bits of P have appeared at H's 355 observational position on L. 357 This specification does not define the exact H's observing position 358 on L. That is left for the deployment setups to define. However, the 359 position where PDM timestamps are taken SHOULD be as close to the 360 physical network interface as possible. Not all implementations will 361 be able to achieve the ideal level of measurement. 363 3.6 Dynamic Configuration Options 365 If the M-PDM destination options extension header is used, then it 366 MAY be turned on for all packets flowing through the host, applied to 367 an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP 368 address only. These are at the discretion of the implementation. 370 3.7 Information Access and Storage 372 Measurement information provided by M-PDM may be made accessible for 373 higher layers or the user itself. Similar to activating the use of M- 374 PDM, the implementation may also provide an interface to indicate if 375 received 377 M-PDM information may be stored, if desired. If a packet with M-PDM 378 information is received and the information should be stored, the 379 upper layers may be notified. Furthermore, the implementation should 380 define a configurable maximum lifetime after which the information 381 can be removed as well as a configurable maximum amount of memory 382 that should be allocated for PDM information. 384 4 M-PDM HBH Extension Header 386 The M-PDM Hop by Hop option is encoded in type-length-value (TLV) 387 format. It has an alignment requirement of 4n + 2. (See [IPv6, 388 Section 4.2] for discussion of option alignment.) The option has the 389 following format: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Option Type | Option Length |Version|LastM |M | MType | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Middlebox Identifier | Timestamp In | 397 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Timestamp Out | PSN This Packet | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Middlebox Identifier | Timestamp In | 401 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Timestamp Out | PSN This Packet | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Middlebox Identifier | Timestamp In | 405 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Timestamp Out | PSN This Packet | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Middlebox Identifier | Timestamp In | 409 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Timestamp Out | PSN This Packet | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Middlebox Identifier | Timestamp In | 413 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Timestamp Out | PSN This Packet | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Option Type 419 0x0F 421 In keeping with RFC 8200 [RFC8200], the two high-order bits of the 422 Option Type field are encoded to indicate specific processing of the 423 option; for the M-PDM HBH option, these two bits MUST be set to 00. 425 The third high-order bit of the Option Type field specifies whether 426 or not the Option Data of that option can change en route to the 427 packet's final destination. 429 In M-PDM, the value of the third high-order bit MUST be 0. 431 Option Length 433 8-bit unsigned integer. Length of the option, in octets, excluding 434 the Option Type and Option Length fields. This field MUST be set to 435 10. 437 Version 439 4-bit unsigned integer. 441 Last Middlebox 443 4-bit unsigned integer. Indicates which middlebox number was last 444 done. For example, 3 would indicate that this is the third 445 middlebox. This field could be used to quickly find which set of 446 data to fill. If there have been more than 5 middleboxes, then 447 wrapping will happen and fields will get overwritten. 449 Marking 451 2-bit unsigned integer. 453 Marking Type (M-Type) 455 4-bit unsigned integer. This indicates the type of marking method 456 being used for the timestamp. 458 If marking is not used, then the timestamp will be when the packet 459 left the IP interface on this middlebox. 461 If marking method is used, then this field will contain: 463 1 - the timestamp of the first packet of a marked batch 2 - the 464 average timestamp of the packets of a batch 3 - a double-marked 465 packet 467 RSVD 469 2-bit unsigned integer 470 Middle Box Identifier 472 16-bit unsigned integer. 474 This field MUST be zero if not used. The zeros are intended to make 475 it harder to leak data via the HBH header. 477 This could be some portion of the IPv4 or IPv6 address or the router 478 ID. [Note to readers: any suggestions for this field are most 479 welcome!] 481 Timestamp In 483 16-bit unsigned integer. This can be the timestamp of the packet 484 received by the IP interface on this middlebox. If marking method is 485 used, it can identify the timestamp of the first packet of a marked 486 batch or the average timestamp of the packets of a batch or a double- 487 marked packet, depending on which method is used to perform delay 488 measurements. 490 This field is initialized to 0. 492 Timestamp Out 494 16-bit unsigned integer. This can be the timestamp of the packet 495 left the IP interface on this middlebox. If marking method is used, 496 it can identify the timestamp of the first packet of a marked batch 497 or the average timestamp of the packets of a batch or a double-marked 498 packet, depending on which method is used to perform delay 499 measurements. 501 This field is initialized to 0. 503 Packet Sequence Number This Packet (PSNTP) 505 16-bit unsigned integer. This field will wrap. It is intended for 506 use while analyzing packet traces. 508 This field is initialized at a random number and incremented 509 monotonically for each packet of the session flow of the IP stack. 510 The random-number initialization is intended to make it harder to 511 spoof and insert such packets. 513 5. Marking Field 515 The 2 currently used bits from the 8 bit Marking fied are designated 516 as Mark Field (MF). 518 +-+-+-+-+-+-+-+-+ 519 | reserved | MF| 520 +-+-+-+-+-+-+-+-+ 522 Mark Field (MF) is: 524 +-+-+-+-+ 525 | S | D | 526 +-+-+-+-+ 528 6. Alternate Marking Method Operation 530 [RFC8321] describes in detail the methodology, that we briefly 531 illustrate also here. 533 6.1. Single Mark Measurement 535 As explained in the [RFC8321], marking can be applied to delineate 536 blocks of packets based either on equal number of packets in a block 537 or based on equal time interval. The latter method offers better 538 control as it allows better account for capabilities of downstream 539 nodes to report statistics related to batches of packets and, at the 540 same time, time resolution that affects defect detection interval. 542 If the Single Mark measurement used, then the D flag MUST be set to 543 zero on transmit and ignored by monitoring point. 545 The S flag is used to create alternate flows to measure the packet 546 loss by switching value of the S flag. Delay metrics MAY be 547 calculated with the alternate flow using any of the following 548 methods: 550 o First/Last Batch Packet Delay calculation: timestamps are 551 collected based on order of arrival so this method is sensitive to 552 packet loss and re-ordering. 554 o Average Packet Delay calculation: an average delay is calculated 555 by considering the average arrival time of the packets within a 556 single block. This method only provides single metric for the 557 duration of the block and it doesn't give information about the 558 delay distribution. 560 6.2. Double Mark Measurement 562 Double Mark method allows more detailed measurement of delays for the 563 monitored flow but it requires more nodal and network resources. If 564 the Double Mark method used, then the S flag MUST be used to create 565 the alternate flow. The D flag MUST be used to mark single packets 566 to measure delay jitter. 568 The first marking (S flag alternation) is needed for packet loss and 569 also for average delay measurement. The second marking (D flag is 570 put to one) creates a new set of marked packets that are fully 571 identified and dedicated for delay. This method is useful to have 572 not only the average delay but also to know more about the statistic 573 distribution of delay values. 575 7 Security Considerations 577 M-PDM may introduce some new security weaknesses. 579 7.1 Resource Consumption and Resource Consumption Attacks 581 M-PDM needs to calculate the deltas for time and keep track of the 582 sequence numbers. This means that control blocks which reside in 583 memory may be kept at the end hosts per 5-tuple. 585 A limit on how much memory is being used SHOULD be implemented. 586 Without a memory limit, any time a control block is kept in memory, 587 an attacker can try to misuse the control blocks to cause excessive 588 resource consumption. This could be used to compromise the end host. 590 M-PDM as a Destination is used at the end hosts and memory is used 591 only at the end host M-PDM as an HBH header is used at routers or 592 middle boxes. 594 7.2 Pervasive monitoring 596 Since M-PDM passes in the clear, a concern arises as to whether the 597 data can be used to fingerprint the system or somehow obtain 598 information about the contents of the payload. 600 Let us discuss fingerprinting of the end host first. It is possible 601 that seeing the pattern of deltas or the absolute values could give 602 some information as to the speed of the end host - that is, if it is 603 a very fast system or an older, slow device. This may be useful to 604 the attacker. However, if the attacker has access to PDM, the 605 attacker also has access to the entire packet and could make such a 606 deduction based merely on the time frames elapsed between packets 607 WITHOUT PDM. 609 As far as deducing the content of the payload, in terms of the 610 application level information such as web page, user name, user 611 password and so on, it appears to us that PDM is quite unhelpful in 612 this regard. Having said that, the ability to separate wire-time 613 from processing time may potentially provide an attacker with 614 additional information. It is conceivable that an attacker could 615 attempt to deduce the type of application in use by noting the server 616 time and payload length. Some encryption algorithms attempt to 617 obfuscate the packet length to avoid just such vulnerabilities. In 618 the future, encryption algorithms may wish to obfuscate the server 619 time as well. 621 7.3 M-PDM as a Covert Channel 623 PDM provides a set of fields in the packet which could be used to 624 leak data. But, there is no real reason to suspect that PDM would be 625 chosen rather than another part of the payload or another Extension 626 Header. 628 A firewall or another device could sanity check the fields within the 629 PDM but randomly assigned sequence numbers and delta times might be 630 expected to vary widely. The biggest problem though is how an 631 attacker would get access to PDM in the first place to leak data. The 632 attacker would have to either compromise the end host or have Man in 633 the Middle (MitM). It is possible that either one could change the 634 fields. But, then the other end host would get sequence numbers and 635 deltas that don't make any sense. 637 It is conceivable that someone could compromise an end host and make 638 it start sending packets with PDM without the knowledge of the host. 639 But, again, the bigger problem is the compromise of the end host. 640 Once that is done, the attacker probably has better ways to leak 641 data. 643 Having said that, if a PDM aware middle box or an implementation 644 (destination host) detects some number of "nonsensical" sequence 645 numbers or timing information, it could take action to block, 646 discard, or alert on this traffic. 648 7.4 Timing Attacks 650 The fact that PDM can help in the separation of node processing time 651 from network latency brings value to performance monitoring. Yet, it 652 is this very characteristic of PDM which may be misused to make 653 certain new type of timing attacks against protocols and 654 implementations possible. 656 Depending on the nature of the cryptographic protocol used, it may be 657 possible to leak the credentials of the device. For example, if an 658 attacker can see that PDM is being used, then the attacker might use 659 PDM to launch a timing attack against the keying material used by the 660 cryptographic protocol. 662 An implementation may want to be sure that PDM is enabled only for 663 certain ip addresses, or only for some ports. Additionally, the 664 implementation SHOULD require an explicit restart of monitoring after 665 a certain time period (for example for 1 hour), to make sure that PDM 666 is not accidentally left on after debugging has been done etc. 668 Even so, if using PDM, a user "Consent to be Measured" SHOULD be a 669 pre-requisite for using PDM. Consent is common in enterprises and 670 with some subscription services. The actual content of "Consent to 671 be Measured" will differ by site but it SHOULD make clear that the 672 traffic is being measured for quality of service and to assist in 673 diagnostics as well as to make clear that there may be potential 674 risks of certain vulnerabilities if the traffic is captured during a 675 diagnostic session. 677 8 IANA Considerations 679 This draft requests an Destination Option Type assignment with the 680 act bits set to 00 and the chg bit set to 0 from the Destination 681 Options and Hop-by-Hop Options sub-registry of Internet Protocol 682 Version 6 (IPv6) Parameters [ref to RFCs and URL below. 684 http://www.iana.org/assignments/ipv6-parameters/ipv6- 685 parameters.xhtml#ipv6-parameters-2 687 Hex Value Binary Value Description Reference 688 act chg rest 689 ------------------------------------------------------------------- 690 TBD TBD Performance and [This draft] 691 Diagnostic Metrics 692 (PDM) 694 9 References 696 9.1 Normative References 698 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 699 Requirement Levels", BCP 14, RFC 2119, March 1997. 701 [RFC4303] Kent, S, "IP Encapsulating Security Payload (ESP)", RFC 702 4303, December 2005. 704 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 705 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 706 2017, . 708 [RFC8250] Elkins, N., Ackermann, M. and Hamilton, R. "IPv6 709 Performance and Diagnostic Metrics (PDM) Destination Option", RFC 710 8250, September 2017. 712 7.2 Informative References 714 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 715 "Framework for IP Performance Metrics", RFC 2330, May 1998. 717 [RFC8321] Fioccola, G. et al, "Alternate-Marking Method for Passive 718 and Hybrid Performance Monitoring", RFC 8321, January 2018. 720 Acknowledgments 722 The authors would like to thank Rob Hamilton for his review. 724 Authors' Addresses 726 Nalini Elkins 727 Inside Products, Inc. 728 36A Upper Circle 729 Carmel Valley, CA 93924 730 United States 731 Phone: +1 831 659 8360 732 Email: nalini.elkins@insidethestack.com 733 http://www.insidethestack.com 735 Giuseppe Fioccola 736 Telecom Italia 737 Via Reiss Romoli, 274 738 Torino 10148 739 Italy 740 Email: giuseppe.fioccola@telecomitalia.it 742 Michael S. Ackermann 743 Blue Cross Blue Shield of Michigan 744 P.O. Box 2888 745 Detroit, Michigan 48231 746 United States 747 Phone: +1 310 460 4080 748 Email: mackermann@bcbsm.com 749 http://www.bcbsm.com