--- 1/draft-ietf-ippm-6man-pdm-option-10.txt 2017-06-06 10:13:10.526920940 -0700 +++ 2/draft-ietf-ippm-6man-pdm-option-11.txt 2017-06-06 10:13:10.586922370 -0700 @@ -1,21 +1,21 @@ INTERNET-DRAFT N. Elkins Inside Products R. Hamilton Chemical Abstracts Service M. Ackermann Intended Status: Proposed Standard BCBS Michigan -Expires: November 10, 2017 May 9, 2017 +Expires: December 8, 2017 June 6, 2017 IPv6 Performance and Diagnostic Metrics (PDM) Destination Option - draft-ietf-ippm-6man-pdm-option-10 + draft-ietf-ippm-6man-pdm-option-11 Abstract To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real-time or after the fact. An implementation of the existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header as well as the field limits, calculations, and usage @@ -59,68 +59,68 @@ described in the Simplified BSD License. Table of Contents 1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Rationale for defined solution . . . . . . . . . . . . . . . 5 1.3 IPv6 Transition Technologies . . . . . . . . . . . . . . . . 6 2 Measurement Information Derived from PDM . . . . . . . . . . . . 6 2.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 6 - 2.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3 Performance and Diagnostic Metrics Destination Option Layout . . 7 - 3.1 Destination Options Header . . . . . . . . . . . . . . . . . 7 - 3.2 Performance and Diagnostic Metrics Destination Option . . . 7 - 3.2.1 PDM Layout . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2.2 Base Unit for Time Measurement . . . . . . . . . . . . . 9 - 3.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 10 - 3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 10 - 3.4.1 Using ESP Transport Mode . . . . . . . . . . . . . . . . 10 - 3.4.2 Using ESP Tunnel Mode . . . . . . . . . . . . . . . . . 10 - 3.5 Implementation Considerations . . . . . . . . . . . . . . . 11 - 3.5.1 PDM Activation . . . . . . . . . . . . . . . . . . . . . 11 - 3.5.2 PDM Timestamps . . . . . . . . . . . . . . . . . . . . . 11 - 3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 11 - 3.7 Information Access and Storage . . . . . . . . . . . . . . . 11 - 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 - 4.1 Resource Consumption and Resource Consumption Attacks . . . 12 - 4.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . . 12 - 4.3 PDM as a Covert Channel . . . . . . . . . . . . . . . . . . 13 - 4.4 Timing Attacks . . . . . . . . . . . . . . . . . . . . . . . 13 - 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 - 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 - 6.2 Informative References . . . . . . . . . . . . . . . . . . . 15 - Appendix A: Context for PDM . . . . . . . . . . . . . . . . . . . 15 - A.1 End User Quality of Service (QoS) . . . . . . . . . . . . . 15 - A.2 Need for a Packet Sequence Number (PSN) . . . . . . . . . . 15 - A.3 Rationale for Defined Solution . . . . . . . . . . . . . . . 16 - A.4 Use PDM with Other Headers . . . . . . . . . . . . . . . . . 16 - Appendix B : Timing Considerations . . . . . . . . . . . . . . . . 17 - B.1 Timing Differential Calculations . . . . . . . . . . . . . . 17 - B.2 Considerations of this time-differential representation . . 18 - B.2.1 Limitations with this encoding method . . . . . . . . . 18 - B.2.2 Loss of precision induced by timer value truncation . . 19 - Appendix C: Sample Packet Flows . . . . . . . . . . . . . . . . . 20 - C.1 PDM Flow - Simple Client Server . . . . . . . . . . . . . . 20 - C.1.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . 21 - C.1.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . 21 - C.1.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . 22 - C.1.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . 23 - C.1.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . 24 - C.2 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . 24 - C.2.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . 24 - C.2.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . 26 - C.2.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . 27 - Appendix D: Potential Overhead Considerations . . . . . . . . . . 28 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 + 2.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3 Performance and Diagnostic Metrics Destination Option Layout . . 8 + 3.1 Destination Options Header . . . . . . . . . . . . . . . . . 8 + 3.2 Performance and Diagnostic Metrics Destination Option . . . 8 + 3.2.1 PDM Layout . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.2.2 Base Unit for Time Measurement . . . . . . . . . . . . . 10 + 3.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 11 + 3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 11 + 3.4.1 Using ESP Transport Mode . . . . . . . . . . . . . . . . 11 + 3.4.2 Using ESP Tunnel Mode . . . . . . . . . . . . . . . . . 11 + 3.5 Implementation Considerations . . . . . . . . . . . . . . . 12 + 3.5.1 PDM Activation . . . . . . . . . . . . . . . . . . . . . 12 + 3.5.2 PDM Timestamps . . . . . . . . . . . . . . . . . . . . . 12 + 3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 12 + 3.7 Information Access and Storage . . . . . . . . . . . . . . . 12 + 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 + 4.1 Resource Consumption and Resource Consumption Attacks . . . 13 + 4.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . . 13 + 4.3 PDM as a Covert Channel . . . . . . . . . . . . . . . . . . 14 + 4.4 Timing Attacks . . . . . . . . . . . . . . . . . . . . . . . 14 + 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15 + 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 + 6.2 Informative References . . . . . . . . . . . . . . . . . . . 16 + Appendix A: Context for PDM . . . . . . . . . . . . . . . . . . . 16 + A.1 End User Quality of Service (QoS) . . . . . . . . . . . . . 16 + A.2 Need for a Packet Sequence Number (PSN) . . . . . . . . . . 16 + A.3 Rationale for Defined Solution . . . . . . . . . . . . . . . 17 + A.4 Use PDM with Other Headers . . . . . . . . . . . . . . . . . 17 + Appendix B : Timing Considerations . . . . . . . . . . . . . . . . 18 + B.1 Timing Differential Calculations . . . . . . . . . . . . . . 18 + B.2 Considerations of this time-differential representation . . 19 + B.2.1 Limitations with this encoding method . . . . . . . . . 19 + B.2.2 Loss of precision induced by timer value truncation . . 20 + Appendix C: Sample Packet Flows . . . . . . . . . . . . . . . . . 21 + C.1 PDM Flow - Simple Client Server . . . . . . . . . . . . . . 21 + C.1.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . 22 + C.1.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . 22 + C.1.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . 23 + C.1.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . 24 + C.1.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . 25 + C.2 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . 25 + C.2.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . 25 + C.2.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . 27 + C.2.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . 28 + Appendix D: Potential Overhead Considerations . . . . . . . . . . 29 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 1 Background To assess performance problems, measurements based on optional sequence numbers and timing may be embedded in each packet. Such measurements may be interpreted in real-time or after the fact. As defined in RFC2460 [RFC2460], destination options are carried by the IPv6 Destination Options extension header. Destination options include optional information that need be examined only by the IPv6 @@ -158,24 +158,27 @@ a uniform way The PDM provides the ability to determine quickly if the (latency) problem is in the network or in the server (application). That is, it is a fast way to do triage. For more information on background and usage of PDM, see Appendix A. 1.3 IPv6 Transition Technologies In the path to full implementation of IPv6, transition technologies - such as translation or tunneling may be employed. The PDM header is - not expected to work in such scenarios. It is likely that an IPv6 - packet containing PDM will be dropped if using IPv6 transition - technologies. + such as translation or tunneling may be employed. It is possible + that an IPv6 packet containing PDM may be dropped if using IPv6 + transition technologies. For example, an implementation using a + translation technique (IPv6 to IPv4) which does not support or + recognize the IPv6 Destination Options extension header may simply + drop the packet rather than translating it without the extension + header. 2 Measurement Information Derived from PDM Each packet contains information about the sender and receiver. In IP protocol, the identifying information is called a "5-tuple". The 5-tuple consists of: SADDR : IP address of the sender SPORT : Port for sender @@ -222,37 +226,40 @@ 3 Performance and Diagnostic Metrics Destination Option Layout 3.1 Destination Options Header The IPv6 Destination Options Header is used to carry optional information that needs to be examined only by a packet's destination node(s). The Destination Options Header is identified by a Next Header value of 60 in the immediately preceding header and is defined in RFC2460 [RFC2460]. The IPv6 Performance and Diagnostic Metrics - Destination Option (PDM) is an implementation of the Destination - Options Header. The PDM does not require time synchronization. + Destination Option (PDM) is implemented as an IPv6 Option carried in + the Destination Options Header. The PDM does not require time + synchronization. 3.2 Performance and Diagnostic Metrics Destination Option 3.2.1 PDM Layout The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) contains the following fields: SCALEDTLR: Scale for Delta Time Last Received SCALEDTLS: Scale for Delta Time Last Sent PSNTP : Packet Sequence Number This Packet PSNLR : Packet Sequence Number Last Received DELTATLR : Delta Time Last Received DELTATLS : Delta Time Last Sent + The alignment for PDM is per RFC2460 [RFC2460]. + The PDM destination option is encoded in type-length-value (TLV) format as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | ScaleDTLR | ScaleDTLS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSN This Packet | PSN Last Received | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -271,21 +278,21 @@ The third high order bit of the Option Type specifies whether or not the Option Data of that option can change en-route to the packet's final destination. In the PDM, the value of the third high order bit MUST be 0. Option Length 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to - 16. + 10. Scale Delta Time Last Received (SCALEDTLR) 8-bit unsigned integer. This is the scaling value for the Delta Time Last Received (DELTATLR) field. The possible values are from 0-255. See Section 4 for further discussion on Timing Considerations and formatting of the scaling values. Scale Delta Time Last Sent (SCALEDTLS) @@ -329,36 +336,37 @@ 3.2.2 Base Unit for Time Measurement A time differential is always a whole number in a CPU; it is the unit specification -- hours, seconds, nanoseconds -- that determine what the numeric value means. For PDM, the base time unit is 1 attosecond (asec). This allows for a common unit and scaling of the time differential among all IP stacks and hardware implementations. Note that PDM provides the ability to measure both time differentials - that are extremely small, and time differentials in a DTN-type - environment where the delays may be very great. To store a time - differential in just 16 bits that must range in this way will require - some scaling of the time differential value. + that are extremely small, and time differentials in a + Delay/Disruption Tolerant Networking (DTN) environment where the + delays may be very great. To store a time differential in just 16 + bits that must range in this way will require some scaling of the + time differential value. One issue is the conversion from the native time base in the CPU hardware of whatever device is in use to some number of attoseconds. It might seem this will be an astronomical number, but the conversion is straightforward. It involves multiplication by an appropriate power of 10 to change the value into a number of attoseconds. Then, to scale the value so that it fits into DELTATLR or DELTATLS, the value is shifted by of a number of bits, retaining the 16 high-order or most significant bits. The number of bits shifted becomes the - scaling factor, stored as SCALEDTLR or SCALEDTLS, respectively. For a - full description of this process, including examples, please see - Appendix A. + scaling factor, stored as SCALEDTLR or SCALEDTLS, respectively. For + additional information of this process, including examples, please + see Appendix A. 3.3 Header Placement The PDM Destination Option is placed as defined in RFC2460 [RFC2460]. There may be a choice of where to place the Destination Options header. If using ESP mode, please see section 3.4 of this document for placement of the PDM Destination Options header. For each IPv6 packet header, the PDM MUST NOT appear more than once. However, an encapsulated packet MAY contain a separate PDM associated @@ -368,27 +376,27 @@ IPSec Encapsulating Security Payload (ESP) is defined in [RFC4303] and is widely used. Section 3.1.1 of [RFC4303] discusses placement of Destination Options Headers. The placement of PDM is different depending on if ESP is used in tunnel or transport mode. 3.4.1 Using ESP Transport Mode - Note that Destination Options MAY be placed before or after ESP or + Note that Destination Options may be placed before or after ESP or both. If using PDM in ESP transport mode, PDM MUST be placed after the ESP header so as not to leak information. 3.4.2 Using ESP Tunnel Mode - Note that Destination Options MAY be placed before or after ESP or + Note that Destination Options may be placed before or after ESP or both in both the outer set of IP headers and the inner set of IP headers. A tunnel endpoint that creates a new packet may decide to use PDM independent of the use of PDM of the original packet to enable delay measurements between the two tunnel endpoints 3.5 Implementation Considerations 3.5.1 PDM Activation An implementation should provide an interface to enable or disable @@ -450,43 +457,47 @@ 4.1 Resource Consumption and Resource Consumption Attacks PDM needs to calculate the deltas for time and keep track of the sequence numbers. This means that control blocks which reside in memory may be kept at the end hosts per 5-tuple. A limit on how much memory is being used SHOULD be implemented. Without a memory limit, any time a control block is kept in memory, - an attacker can try to mis-use the control blocks to cause excessive + an attacker can try to misuse the control blocks to cause excessive resource consumption. This could be used to compromise the end host. PDM is used only at the end hosts and memory is used only at the end host and not at routers or middle boxes. 4.2 Pervasive monitoring Since PDM passes in the clear, a concern arises as to whether the data can be used to fingerprint the system or somehow obtain information about the contents of the payload. Let us discuss fingerprinting of the end host first. It is possible that seeing the pattern of deltas or the absolute values could give some information as to the speed of the end host - that is, if it is a very fast system or an older, slow device. This may be useful to the attacker. However, if the attacker has access to PDM, the attacker also has access to the entire packet and could make such a deduction based merely on the time frames elapsed between packets WITHOUT PDM. - As far as deducing the content of the payload, it appears to us that - PDM is quite unhelpful in this regard. + As far as deducing the content of the payload, it is conceivable that + an attacker could attempt to deduce the type of application in use by + noting the server time and payload length. Having said that, some + encryption algorithms attempt to obfuscate the packet length to avoid + just such vulnerabilities. In the future, encryption algorithms may + wish to obfuscate the server time as well. 4.3 PDM as a Covert Channel PDM provides a set of fields in the packet which could be used to leak data. But, there is no real reason to suspect that PDM would be chosen rather than another part of the payload or another Extension Header. A firewall or another device could sanity check the fields within the PDM but randomly assigned sequence numbers and delta times might be @@ -498,56 +509,56 @@ and deltas that don't make any sense. It is conceivable that someone could compromise an end host and make it start sending packets with PDM without the knowledge of the host. But, again, the bigger problem is the compromise of the end host. Once that is done, the attacker probably has better ways to leak data. Having said that, if a PDM aware middle box or an implementation detects some number of "nonsensical" sequence numbers it could take - action to block (or alert on) this traffic. + action to block to block, discard, or alert on this traffic. 4.4 Timing Attacks The fact that PDM can help in the separation of node processing time from network latency brings value to performance monitoring. Yet, it is this very characteristic of PDM which may be misused to make certain new type of timing attacks against protocols and implementations possible. Depending on the nature of the cryptographic protocol used, it may be possible to leak the long term credentials of the device. For example, if an attacker is able to create an attack which causes the enterprise to turn on PDM to diagnose the attack, then the attacker might use PDM during that debugging time to launch a timing attack - against the long term keying material used by the cryptographic - protocol. + against the keying material used by the cryptographic protocol. An implementation may want to be sure that PDM is enabled only for certain ip addresses, or only for some ports. Additionally, the implementation SHOULD require an explicit restart of monitoring after a certain time period (for example for 1 hour), to make sure that PDM is not accidentally left on after debugging has been done etc. Even so, if using PDM, a user "Consent to be Measured" SHOULD be a pre-requisite for using PDM. Consent is common in enterprises and with some subscription services. The actual content of "Consent to be Measured" will differ by site but it SHOULD make clear that the traffic is being measured for quality of service and to assist in diagnostics as well as to make clear that there may be potential risks of certain vulnerabilities if the traffic is captured during a diagnostic session 5 IANA Considerations - This draft requests an Option Type assignment in the Destination + This draft requests an Destination Option Type assignment with the + act bits set to 00 and the chg bit set to 0 from the Destination Options and Hop-by-Hop Options sub-registry of Internet Protocol Version 6 (IPv6) Parameters [ref to RFCs and URL below]. http://www.iana.org/assignments/ipv6-parameters/ipv6- parameters.xhtml#ipv6-parameters-2 Hex Value Binary Value Description Reference act chg rest ------------------------------------------------------------------- TBD TBD Performance and [This draft]