draft-ietf-ippm-6man-pdm-option-03.txt   draft-ietf-ippm-6man-pdm-option-04.txt 
INTERNET-DRAFT N. Elkins INTERNET-DRAFT N. Elkins
Inside Products Inside Products
R. Hamilton R. Hamilton
Chemical Abstracts Service Chemical Abstracts Service
M. Ackermann M. Ackermann
Intended Status: Proposed Standard BCBS Michigan Intended Status: Proposed Standard BCBS Michigan
Expires: December 9, 2016 June 7, 2016 Expires: March 17, 2017 September 13, 2016
IPv6 Performance and Diagnostic Metrics (PDM) Destination Option IPv6 Performance and Diagnostic Metrics (PDM) Destination Option
draft-ietf-ippm-6man-pdm-option-03 draft-ietf-ippm-6man-pdm-option-04
Table of Contents
1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 End User Quality of Service (QoS) . . . . . . . . . . . . . 4
1.3 Need for a Packet Sequence Number . . . . . . . . . . . . . 5
1.4 Rationale for proposed solution . . . . . . . . . . . . . . 5
1.5 PDM Works in Collaboration with Other Headers . . . . . . . 6
1.6 IPv6 Transition Technologies . . . . . . . . . . . . . . . . 6
2 Measurement Information Derived from PDM . . . . . . . . . . . . 6
2.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 7
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.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 11
3.5 Implementation Considerations . . . . . . . . . . . . . . . 11
3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 12
3.6 5-tuple Aging . . . . . . . . . . . . . . . . . . . . . . . 12
4 Considerations of Timing Representation . . . . . . . . . . . . 12
4.1 Encoding the Delta-Time Values . . . . . . . . . . . . . . . 12
4.2 Timer registers are different on different hardware . . . . 13
4.3 Timer Units on Other Systems . . . . . . . . . . . . . . . . 13
4.4 Time Base . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5 Timer-value scaling . . . . . . . . . . . . . . . . . . . . 14
4.6 Limitations with this encoding method . . . . . . . . . . . 15
4.7 Lack of precision induced by timer value truncation . . . . 16
5 PDM Flow - Simple Client Server . . . . . . . . . . . . . . . . 17
5.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . . . 21
6.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . . . 22
6.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . . . 23
7 Potential Overhead Considerations . . . . . . . . . . . . . . . 25
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 26
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1 Normative References . . . . . . . . . . . . . . . . . . . 27
10.2 Informative References . . . . . . . . . . . . . . . . . . 27
11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Abstract Abstract
To assess performance problems, measurements based on optional To assess performance problems, measurements based on optional
sequence numbers and timing may be embedded in each packet. Such sequence numbers and timing may be embedded in each packet. Such
measurements may be interpreted in real-time or after the fact. An measurements may be interpreted in real-time or after the fact. An
implementation of the existing IPv6 Destination Options extension implementation of the existing IPv6 Destination Options extension
header, the Performance and Diagnostic Metrics (PDM) Destination header, the Performance and Diagnostic Metrics (PDM) Destination
Options extension header as well as the field limits, calculations, Options extension header as well as the field limits, calculations,
and usage of the PDM in measurement are included in this document. and usage of the PDM in measurement are included in this document.
skipping to change at page 4, line 5 skipping to change at page 3, line 5
3: This document is subject to BCP 78 and the IETF Trust's Legal 3: This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents
1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 End User Quality of Service (QoS) . . . . . . . . . . . . . 4
1.3 Need for a Packet Sequence Number . . . . . . . . . . . . . 5
1.4 Rationale for defined solution . . . . . . . . . . . . . . . 5
1.5 PDM Works in Collaboration with Other Headers . . . . . . . 6
1.6 IPv6 Transition Technologies . . . . . . . . . . . . . . . . 6
2 Measurement Information Derived from PDM . . . . . . . . . . . . 6
2.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 7
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.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 11
3.5 Implementation Considerations . . . . . . . . . . . . . . . 12
3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 12
3.6 5-tuple Aging . . . . . . . . . . . . . . . . . . . . . . . 12
4 Considerations of Timing Representation . . . . . . . . . . . . 12
4.1 Encoding the Delta-Time Values . . . . . . . . . . . . . . . 12
4.2 Timer registers are different on different hardware . . . . 13
4.3 Timer Units on Other Systems . . . . . . . . . . . . . . . . 13
4.4 Time Base . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5 Timer-value scaling . . . . . . . . . . . . . . . . . . . . 14
4.6 Limitations with this encoding method . . . . . . . . . . . 15
4.7 Lack of precision induced by timer value truncation . . . . 16
5 PDM Flow - Simple Client Server . . . . . . . . . . . . . . . . 17
5.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . . . 21
6.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . . . 22
6.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . . . 23
7 Potential Overhead Considerations . . . . . . . . . . . . . . . 25
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 26
8.1. SYN Flood and Resource Consumption Attacks . . . . . . . . 26
8.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . 26
8.3 PDM as a Covert Channel . . . . . . . . . . . . . . . . . . 27
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1 Normative References . . . . . . . . . . . . . . . . . . . 28
10.2 Informative References . . . . . . . . . . . . . . . . . . 28
11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1 Background 1 Background
To assess performance problems, measurements based on optional To assess performance problems, measurements based on optional
sequence numbers and timing may be embedded in each packet. Such sequence numbers and timing may be embedded in each packet. Such
measurements may be interpreted in real-time or after the fact. An measurements may be interpreted in real-time or after the fact.
implementation of the existing IPv6 Destination Options extension
header, the Performance and Diagnostic Metrics (PDM) Destination
Options extension header has been proposed in a companion document.
This document specifies the layout, field limits, calculations, and
usage of the PDM in measurement.
As defined in RFC2460 [RFC2460], destination options are carried by As defined in RFC2460 [RFC2460], destination options are carried by
the IPv6 Destination Options extension header. Destination options the IPv6 Destination Options extension header. Destination options
include optional information that need be examined only by the IPv6 include optional information that need be examined only by the IPv6
node given as the destination address in the IPv6 header, not by node given as the destination address in the IPv6 header, not by
routers or other "middle boxes". This document specifies a new routers or other "middle boxes". This document specifies a new
destination option, the Performance and Diagnostic Metrics (PDM) destination option, the Performance and Diagnostic Metrics (PDM)
destination option. destination option. This document specifies the layout, field
limits, calculations, and usage of the PDM in measurement.
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2 End User Quality of Service (QoS) 1.2 End User Quality of Service (QoS)
The timing values in the PDM embedded in the packet will be used to The timing values in the PDM embedded in the packet will be used to
skipping to change at page 5, line 28 skipping to change at page 5, line 28
packet provides sufficient basis for the matching process. If need packet provides sufficient basis for the matching process. If need
be, the timing fields may be used along with the sequence number to be, the timing fields may be used along with the sequence number to
ensure uniqueness. ensure uniqueness.
This method of data collection along the path is of special use to This method of data collection along the path is of special use to
determine where packet loss or packet corruption is happening. determine where packet loss or packet corruption is happening.
The packet sequence number needs to be unique in the context of the The packet sequence number needs to be unique in the context of the
session (5-tuple). See section 2 for a definition of 5-tuple. session (5-tuple). See section 2 for a definition of 5-tuple.
1.4 Rationale for proposed solution 1.4 Rationale for defined solution
The current IPv6 specification does not provide timing nor a similar The current IPv6 specification does not provide timing nor a similar
field in the IPv6 main header or in any extension header. So, we field in the IPv6 main header or in any extension header. So, we
propose the IPv6 Performance and Diagnostic Metrics destination define the IPv6 Performance and Diagnostic Metrics destination option
option (PDM). (PDM).
Advantages include: Advantages include:
1. Real measure of actual transactions. 1. Real measure of actual transactions.
2. Independence from transport layer protocols. 2. Independence from transport layer protocols.
3. Ability to span organizational boundaries with consistent 3. Ability to span organizational boundaries with consistent
instrumentation instrumentation
4. No time synchronization needed between session partners 4. No time synchronization needed between session partners
5. Ability to handle all transport protocols (TCP, UDP, SCTP, etc)
in a uniform way
The PDM provides the ability to quickly determine if the (latency) The PDM provides the ability to quickly determine if the (latency)
problem is in the network or in the server (application). More problem is in the network or in the server (application). More
intermediate measurements may be needed if the host or network intermediate measurements may be needed if the host or network
discrimination is not sufficient. At the client, TCP/IP stack time discrimination is not sufficient. At the client, TCP/IP stack time
vs. applications time may still need to be broken out by client vs. applications time may still need to be broken out by client
software. software.
1.5 PDM Works in Collaboration with Other Headers 1.5 PDM Works in Collaboration with Other Headers
skipping to change at page 9, line 40 skipping to change at page 9, line 44
Packet Sequence Number Last Received (PSNLR) Packet Sequence Number Last Received (PSNLR)
16-bit unsigned integer. This is the PSNTP of the packet last 16-bit unsigned integer. This is the PSNTP of the packet last
received on the 5-tuple. received on the 5-tuple.
Delta Time Last Received (DELTATLR) Delta Time Last Received (DELTATLR)
A 16-bit unsigned integer field. The value is set according to the A 16-bit unsigned integer field. The value is set according to the
scale in SCALEDTLR. scale in SCALEDTLR.
DELTATLR = Send time packet 2 - Receive time packet 1 Delta Time Last Received = (Send time packet 2 - Receive time packet
1)
Delta TimeLast Sent (DELTATLS) Delta Time Last Sent (DELTATLS)
A 16-bit unsigned integer field. The value is set according to the A 16-bit unsigned integer field. The value is set according to the
scale in SCALEDTLS. scale in SCALEDTLS.
Delta Time Last Sent = Receive time packet 2 - Send time packet 1 Delta Time Last Sent = (Receive time packet 2 - Send time packet 1)
Option Type Option Type
The two highest-order bits of the Option Type field are encoded to The two highest-order bits of the Option Type field are encoded to
indicate specific processing of the option; for the PDM destination indicate specific processing of the option; for the PDM destination
option, these two bits MUST be set to 00. This indicates the option, these two bits MUST be set to 00. This indicates the
following processing requirements: following processing requirements:
00 - skip over this option and continue processing the header. 00 - skip over this option and continue processing the header.
skipping to change at page 12, line 17 skipping to change at page 12, line 23
If implemented, each operating system MUST have a default If implemented, each operating system MUST have a default
configuration parameter, e.g. diag_header_sys_default_value=yes/no. configuration parameter, e.g. diag_header_sys_default_value=yes/no.
The operating system MAY also have a dynamic configuration option to The operating system MAY also have a dynamic configuration option to
change the configuration setting as needed. change the configuration setting as needed.
If the PDM destination options extension header is used, then it MAY If the PDM destination options extension header is used, then it MAY
be turned on for all packets flowing through the host, applied to an be turned on for all packets flowing through the host, applied to an
upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP
address only. These are at the discretion of the implementation. address only. These are at the discretion of the implementation.
The PDM MUST NOT be changed dynamically via packet flow as this may
create potential security violation or DoS attack by numerous packets
turning the header on and off.
As with all other destination options extension headers, the PDM is As with all other destination options extension headers, the PDM is
for destination nodes only. As specified above, intermediate devices for destination nodes only. As specified above, intermediate devices
MUST neither set nor modify this field. MUST neither set nor modify this field.
3.6 5-tuple Aging 3.6 5-tuple Aging
Within the operating system, metrics must be kept on a 5-tuple basis. Within the operating system, metrics must be kept on a 5-tuple basis.
The 5-tuple is: The 5-tuple is:
skipping to change at page 14, line 18 skipping to change at page 14, line 18
use different binary points. For some clocks, a value of 1 could use different binary points. For some clocks, a value of 1 could
indicate 1 microsecond, whereas other clocks could use the value 1 to indicate 1 microsecond, whereas other clocks could use the value 1 to
indicate 1 millisecond. In the former case, the binary digits to the indicate 1 millisecond. In the former case, the binary digits to the
right of that binary point measure 2**(-n) microseconds, and in the right of that binary point measure 2**(-n) microseconds, and in the
latter case, 2**(-n) milliseconds. latter case, 2**(-n) milliseconds.
The Time Base allows us to ensure we have a common reference, at the The Time Base allows us to ensure we have a common reference, at the
very least, common knowledge of what the binary point is for the very least, common knowledge of what the binary point is for the
transmitted values. transmitted values.
We propose a base unit for the time. This is a 2-bit integer We define a base unit for the time. This is a 2-bit integer
indicating the lowest granularity possible for this device. That is, indicating the lowest granularity possible for this device. That is,
for a value of 00 in the Time Base field, a value of 1 in the DELTA for a value of 00 in the Time Base field, a value of 1 in the DELTA
fields indicates 1 picosecond. fields indicates 1 picosecond.
The possible values of Time Base are as follows: The possible values of Time Base are as follows:
00 - milliseconds 00 - milliseconds
01 - microseconds 01 - microseconds
10 - nanoseconds 10 - nanoseconds
11 - picoseconds 11 - picoseconds
skipping to change at page 14, line 41 skipping to change at page 14, line 41
That is, on many, if not all, systems, the timer tick value will not That is, on many, if not all, systems, the timer tick value will not
be in complete units of nanoseconds, milliseconds, etc. For example, be in complete units of nanoseconds, milliseconds, etc. For example,
on an IBM zSeries machine, one timer tick (or clock unit) is 2 to the on an IBM zSeries machine, one timer tick (or clock unit) is 2 to the
-12th microseconds. -12th microseconds.
Therefore, some amount of conversion may be needed to approximate Therefore, some amount of conversion may be needed to approximate
Time Base units. Time Base units.
4.5 Timer-value scaling 4.5 Timer-value scaling
As discussed in [TRAM-TCPM] we propose storing not an entire time- As discussed in [TRAM-TCPM] we define storing not an entire time-
interval value, but just the most significant bits of that value, interval value, but just the most significant bits of that value,
along with a scaling factor to indicate the magnitude of the time- along with a scaling factor to indicate the magnitude of the time-
interval value. In our case, we will use the high-order 16 bits. The interval value. In our case, we will use the high-order 16 bits. The
scaling value will be the number of bits in the timer register to the scaling value will be the number of bits in the timer register to the
right of the 16th significant bit. That is, if the timer register right of the 16th significant bit. That is, if the timer register
contains this binary value: contains this binary value:
1110100011010100101001010001000000000000 1110100011010100101001010001000000000000
<-16 bits -><-24 bits -> <-16 bits -><-24 bits ->
skipping to change at page 18, line 50 skipping to change at page 18, line 50
5.3 Step 3 5.3 Step 3
Packet 2 is sent by Host B to Host A. Note, the initial packet Packet 2 is sent by Host B to Host A. Note, the initial packet
sequence number (PSNTP) from Host B starts at a random number. In sequence number (PSNTP) from Host B starts at a random number. In
this case, 12. Before sending the packet, Host B does a calculation this case, 12. Before sending the packet, Host B does a calculation
of deltas. Since Host B knows when it is sending the packet, and it of deltas. Since Host B knows when it is sending the packet, and it
knows when it received the previous packet, it can do the following knows when it received the previous packet, it can do the following
calculation: calculation:
Sending time (packet 2) - receive time (packet 1) Sending time : packet 2 - receive time : packet 1
We will call the result of this calculation: Delta Time Last We will call the result of this calculation: Delta Time Last Received
Received (DELTATLR)
That is: That is:
DELTATLR = Sending time (packet 2) - receive time (packet 1) Delta Time Last Received = (Sending time: packet 2 - receive time:
packet 1)
Note, both sending time and receive time are saved internally in Host Note, both sending time and receive time are saved internally in Host
B. They do not travel in the packet. Only the Delta is in the B. They do not travel in the packet. Only the Delta is in the
packet. packet.
Assume that within Host B is the following: Assume that within Host B is the following:
Packet Sequence Number of the last packet received: 25 Packet Sequence Number of the last packet received: 25
Time the last packet was received: 11:00:03 Time the last packet was received: 11:00:03
Packet Sequence Number of this packet: 12 Packet Sequence Number of this packet: 12
skipping to change at page 20, line 27 skipping to change at page 20, line 28
End-to-End Time = Time Last Received - Time Last Sent End-to-End Time = Time Last Received - Time Last Sent
For example, packet 25 was sent by Host A at 10:00:00. Packet 12 was For example, packet 25 was sent by Host A at 10:00:00. Packet 12 was
received by Host A at 10:00:12 so: received by Host A at 10:00:12 so:
End-to-End time = 10:00:12 - 10:00:00 or 12 (Server and Network RT End-to-End time = 10:00:12 - 10:00:00 or 12 (Server and Network RT
delay combined). This time may also be called total Overall Round- delay combined). This time may also be called total Overall Round-
trip time (which includes Network RTT and Host Response Time). trip time (which includes Network RTT and Host Response Time).
This derived metric we will call DELTATLS or Delta Time Last Sent. This derived metric we will call Delta Time Last Sent (DELTATLS)
We can now also calculate round trip delay. The formula is: We can now also calculate round trip delay. The formula is:
Round trip delay = DELTATLS - DELTATLR Round trip delay = (Delta Time Last Sent - Delta Time Last Received)
Or: Or:
Round trip delay = 12 - 4 or 8 Round trip delay = 12 - 4 or 8
Now, the only problem is that at this point all metrics are in Host A Now, the only problem is that at this point all metrics are in Host A
only and not exposed in a packet. To do that, we need a third packet. only and not exposed in a packet. To do that, we need a third packet.
Note: this simple example assumes one send and one receive. That Note: this simple example assumes one send and one receive. That
is done only for purposes of explaining the function of the PDM. In is done only for purposes of explaining the function of the PDM. In
skipping to change at page 22, line 27 skipping to change at page 22, line 27
middle-boxes, etc. middle-boxes, etc.
Now, true one-way traffic is quite rare. What people often mean by Now, true one-way traffic is quite rare. What people often mean by
"one-way" traffic is an application such as FTP where a group of "one-way" traffic is an application such as FTP where a group of
packets (for example, a TCP window size worth) is sent, then the packets (for example, a TCP window size worth) is sent, then the
sender waits for acknowledgment. This type of flow would actually sender waits for acknowledgment. This type of flow would actually
fall into the "multiple-send" traffic model. fall into the "multiple-send" traffic model.
6.2 PDM Flow - Multiple Send Traffic 6.2 PDM Flow - Multiple Send Traffic
Assume that two packets are sent for each ACK from the server. Assume that two packets are sent for each ACK from the server. For
example, a TCP flow will do this, per RFC1122 [RFC1122] Section-
4.2.3.
Packet Sender PSN PSN Delta Time Delta Time Packet Sender PSN PSN Delta Time Delta Time
This Packet Last Recvd Last Recvd Last Sent This Packet Last Recvd Last Recvd Last Sent
===================================================================== =====================================================================
1 Server 1 0 0 0 1 Server 1 0 0 0
2 Server 2 0 0 5 2 Server 2 0 0 5
3 Client 1 2 20 0 3 Client 1 2 20 0
4 Server 3 1 10 15 4 Server 3 1 10 15
How might this be used? How might this be used?
skipping to change at page 23, line 27 skipping to change at page 23, line 29
make sure of the interpretation of this data. That is, to make make sure of the interpretation of this data. That is, to make
sure that the Delta Last Received corresponds to the packet of sure that the Delta Last Received corresponds to the packet of
interest. interest.
The benefits of PDM are that we have such information available in a The benefits of PDM are that we have such information available in a
uniform manner for all applications and all protocols without uniform manner for all applications and all protocols without
extensive changes required to applications. extensive changes required to applications.
6.3 PDM Flow - Multiple Send with Errors 6.3 PDM Flow - Multiple Send with Errors
One might wonder if all of the functions of PDM might be better Let us now look at a case of how PDM may be able to help in a case of
suited to TCP or a TCP option. Let us take the case of how PDM may TCP retransmission and add to the information that is sent in the TCP
help in a case of TCP retransmissions in a way that TCP options or header.
TCP ACK / SEQ would not.
Assume that three packets are sent with each send from the server. Assume that three packets are sent with each send from the server.
From the server, this is what is seen. From the server, this is what is seen.
Pkt Sender PSN PSN Delta Time Delta Time TCP Data Pkt Sender PSN PSN Delta Time Delta Time TCP Data
This Pkt LastRecvd LastRecvd LastSent SEQ Bytes This Pkt LastRecvd LastRecvd LastSent SEQ Bytes
===================================================================== =====================================================================
1 Server 1 0 0 0 123 100 1 Server 1 0 0 0 123 100
2 Server 2 0 0 5 223 100 2 Server 2 0 0 5 223 100
3 Server 3 0 0 5 333 100 3 Server 3 0 0 5 333 100
The client however, does not get all the packets. From the client, The client, however, does not receive all the packets. From the
this is what is seen for the packets sent from the server. client, this is what is seen for the packets sent from the server.
Pkt Sender PSN PSN Delta Time Delta Time TCP Data Pkt Sender PSN PSN Delta Time Delta Time TCP Data
This Pkt LastRecvd LastRecvd LastSent SEQ Bytes This Pkt LastRecvd LastRecvd LastSent SEQ Bytes
===================================================================== =====================================================================
1 Server 1 0 0 0 123 100 1 Server 1 0 0 0 123 100
2 Server 3 0 0 5 333 100 2 Server 3 0 0 5 333 100
Let's assume that the server now retransmits the packet. Let's assume that the server now retransmits the packet.
(Obviously, a duplicate acknowledgment sequence for fast retransmit (Obviously, a duplicate acknowledgment sequence for fast retransmit
or a retransmit timeout would occur. To illustrate the point, these or a retransmit timeout would occur. To illustrate the point, these
skipping to change at page 24, line 29 skipping to change at page 24, line 29
Pkt Sender PSN PSN Delta Time Delta Time TCP Data Pkt Sender PSN PSN Delta Time Delta Time TCP Data
This Pkt LastRecvd LastRecvd LastSent SEQ Bytes This Pkt LastRecvd LastRecvd LastSent SEQ Bytes
===================================================================== =====================================================================
1 Server 4 0 0 30 223 100 1 Server 4 0 0 30 223 100
The server has resent the old packet 2 with TCP sequence number of The server has resent the old packet 2 with TCP sequence number of
223. The retransmitted packet now has a PSN This Packet value of 4. 223. The retransmitted packet now has a PSN This Packet value of 4.
The Delta Last Sent is 30 - the time between sending the packet with The Delta Last Sent is 30 - the time between sending the packet with
PSN of 3 and this current packet. PSN of 3 and this current packet.
Let's say that packet 4 STILL does not make it. Then, after some Let's say that packet 4 is lost again. Then, after some amount of
amount of time (RTO) then the packet with TCP sequence number of 223 time (RTO) then the packet with TCP sequence number of 223 is resent.
is resent.
From the client, this is what is seen for the packets sent from the From the client, this is what is seen for the packets sent from the
server. server.
Pkt Sender PSN PSN Delta Time Delta Time TCP Data Pkt Sender PSN PSN Delta Time Delta Time TCP Data
This Pkt LastRecvd LastRecvd LastSent SEQ Bytes This Pkt LastRecvd LastRecvd LastSent SEQ Bytes
===================================================================== =====================================================================
1 Server 5 0 0 60 223 100 1 Server 5 0 0 60 223 100
If now, this packet makes it, one has a very good idea that packets If now, this packet arrives at the destination, one has a very good
exist which are being sent from the server as retransmissions and not idea that packets exist which are being sent from the server as
making it to the client. This is because the PSN of the resent retransmissions and not arriving at the client. This is because the
packet from the server is 5 rather than 4. If we had used TCP PSN of the resent packet from the server is 5 rather than 4. If we
sequence number alone, we would never have seen this situation. had used TCP sequence number alone, we would never have seen this
Because the TCP sequence number in all situations is 223. situation. The TCP sequence number in all situations is 223.
This situation would be experienced by the user of the application This situation would be experienced by the user of the application
(the human being actually sitting somewhere) as a "hangs" or long (the human being actually sitting somewhere) as a "hangs" or long
delay between packets. On large networks, to diagnose problems such delay between packets. On large networks, to diagnose problems such
as these where packets are lost somewhere on the network, one has to as these where packets are lost somewhere on the network, one has to
take multiple traces to find out exactly where. take multiple traces to find out exactly where.
The first thing is to start with doing a trace at the client and the The first thing is to start with doing a trace at the client and the
server. So, we can see if the server sent a particular packet and server. So, we can see if the server sent a particular packet and
the client received it. If the client did not receive it, then we the client received it. If the client did not receive it, then we
skipping to change at page 26, line 12 skipping to change at page 26, line 12
within a data center. Notice that the scale is now in microseconds within a data center. Notice that the scale is now in microseconds
rather than milliseconds. rather than milliseconds.
Bytes RTT Bytes Bytes New Overhead Bytes RTT Bytes Bytes New Overhead
in Packet Per Micro in PDM RTT in Packet Per Micro in PDM RTT
===================================================================== =====================================================================
1000 20 micro 50 16 20.320 .320 micro 1000 20 micro 50 16 20.320 .320 micro
8 Security Considerations 8 Security Considerations
The PDM MUST NOT be changed dynamically via packet flow as this PDM does not introduce any new security weakness.
creates a possibility for potential security violations or DoS
attacks by numerous packets turning the header on and off.
Attackers may also send many packets from multiple ports, for example 8.1. SYN Flood and Resource Consumption Attacks
by doing a port scan. This will cause the stack to create many
control blocks. This is the same problem as seen for SYN flood PDM needs to calculate the deltas for time and keep track of the
attacks. Similar protections should be implemented by the stack to sequence numbers. This means that control blocks must be kept at the
preserve the integrity of memory. end hosts per 5-tuple. Any time a control block is kept, an
attacker can try to mis-use the control blocks such that there is a
compromise of the end host.
PDM is used only at the end hosts and the control blocks are only
kept at the end host and not at routers or middle boxes. Remember,
PDM is an implementation of the Destination Option extension header.
A "SYN flood" type of attack succeeds because a TCP SYN packet is
small but it causes the end host to start creating a place holder for
the session such that quite a bit of control block and other storage
is used. This is an asynchronous type of attack in that a small
amount of work by the attacker creates a large amount of work by the
resource attacked.
For PDM, the amount of data to be kept is quite small. That is, the
control block is quite lightweight. Concerns about SYN Flood and
other type of resource consumption attacks (memory, processing power,
etc) can be alleviated by having a limit on the size of the control
block.
We recommend that implementation of PDM SHOULD have a limit on the
size of the control blocks used.
8.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.
8.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
expected to vary widely. The biggest problem though is how an
attacker would get access to PDM in the first place to leak data.
The attacker would have to either compromise the end host or have Man
in the Middle (MitM). It is possible that either one could change
the fields. But, then the other end host would get sequence numbers
and deltas that don't make any sense. Presumably, one is using PDM
and doing packet tracing for diagnostic purposes, so the changes
would be obvious. 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, an implementation SHOULD stop using PDM if it gets
some number of "nonsensical" sequence numbers.
9 IANA Considerations 9 IANA Considerations
This draft requests an Option Type assignment in the Destination This draft requests an Option Type assignment in the Destination
Options and Hop-by-Hop Options sub-registry of Internet Protocol Options and Hop-by-Hop Options sub-registry of Internet Protocol
Version 6 (IPv6) Parameters [ref to RFCs and URL below]. Version 6 (IPv6) Parameters [ref to RFCs and URL below].
http://www.iana.org/assignments/ipv6-parameters/ipv6- http://www.iana.org/assignments/ipv6-parameters/ipv6-
parameters.xhtml#ipv6-parameters-2 parameters.xhtml#ipv6-parameters-2
skipping to change at page 27, line 12 skipping to change at page 28, line 14
Diagnostic Metrics Diagnostic Metrics
(PDM) (PDM)
10 References 10 References
10.1 Normative References 10.1 Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", RFC 1122, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999. Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
 End of changes. 25 change blocks. 
100 lines changed or deleted 163 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/