Internet DRAFT - draft-fear-ippm-mpdm
draft-fear-ippm-mpdm
INTERNET-DRAFT N. Elkins
Inside Products
G. Fioccola
Telecom Italia
M. Ackermann
BCBS Michigan
R. Hamilton
Intended Status: Proposed Standard Chemical Abstract Services
Expires: April 24, 2018 October 21, 2018
IPv6 Marking and Performance and Diagnostic Metrics (MPDM)
draft-fear-ippm-mpdm-02
Abstract
To assess performance problems, this document describes optional
headers embedded in each packet that provide marking, sequence
numbers and timing information as a basis for measurements. Such
measurements may be interpreted in real-time or after the fact. This
document specifies the IPv6 Marking and Performance and Diagnostic
Metrics (M-PDM) Hop-byHop and Destination Options extension headers.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Elkins Expires April 24, 2019 [Page 1]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
Copyright and License Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph
3: This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Elkins Expires April 24, 2019 [Page 2]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
Table of Contents
1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Rationale for defined solution . . . . . . . . . . . . . . . 4
1.2.1 Alternate Marking Method Operation . . . . . . . . . . 5
1.2.1.1 Single Mark Measurement . . . . . . . . . . . . . . 5
1.2.2.2 Double Mark Measurement . . . . . . . . . . . . . . 5
1.3 IPv6 Transition Technologies . . . . . . . . . . . . . . . . 6
2 Measurement Information Derived from PDM . . . . . . . . . . . . 6
3 Marking and Performance and Diagnostic Metrics (M-PDM)
Destination . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Destination Options Header . . . . . . . . . . . . . . . . . 7
3.2.1 M-PDM Layout . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2 Base Unit for Time Measurement . . . . . . . . . . . . . 9
3.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 9
3.4.1 Using ESP Transport Mode . . . . . . . . . . . . . . . . 10
3.4.2 Using ESP Tunnel Mode . . . . . . . . . . . . . . . . . 10
3.5 Implementation Considerations . . . . . . . . . . . . . . . 10
3.5.1 M-PDM Activation . . . . . . . . . . . . . . . . . . . . 10
3.5.2 M-PDM Timestamps . . . . . . . . . . . . . . . . . . . . 10
3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 11
3.7 Information Access and Storage . . . . . . . . . . . . . . . 11
4 M-PDM HBH Option . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 HBH Timestamps In and Out . . . . . . . . . . . . . . . . . 15
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 15
5.1 Resource Consumption and Resource Consumption Attacks . . . 15
5.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . . 15
5.3 M-PDM as a Covert Channel . . . . . . . . . . . . . . . . . 16
5.4 Timing Attacks . . . . . . . . . . . . . . . . . . . . . . . 16
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 17
7.2 Informative References . . . . . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Elkins Expires April 24, 2019 [Page 3]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
1 Background
To assess performance problems, measurements based on marking,
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 RFC8200 [RFC8200], destination options are carried by
the IPv6 Destination Options extension header. Destination options
include information that need be examined only by the IPv6 node given
as the destination address in the IPv6 header, not by routers or
"middle boxes".
RFC8200 [RFC8200] additionally defines the IPv6 Hop-by-Hop (HBH)
Options extension header. This header may be processed and examined
by end nodes, routers and "middle boxes".
This document specifies both the Marking Performance and Diagnostic
Metrics (M-PDM) destination option as well as the M-PDM HBH Option.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2 Rationale for defined solution
The M-PDM Destination Option and M-PDM Hop-By-Hop Option are a
combining of PDM [RFC8250] with Marking [RFC8321] to obtain path and
middle box information.
The Marking Field is designed as:
The 2 currently used bits from the 8 bit Marking field are designated
as Mark Field (MF).
+-+-+-+-+-+-+-+-+
| reserved | MF|
+-+-+-+-+-+-+-+-+
Mark Field (MF) is:
+-+-+-+-+
| S | D |
+-+-+-+-+
Elkins Expires April 24, 2019 [Page 4]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
1.2.1 Alternate Marking Method Operation
[RFC8321] describes in detail the methodology, that we briefly
illustrate also here.
1.2.1.1 Single Mark Measurement
As explained in the [RFC8321], marking can be applied to delineate
blocks of packets based either on equal number of packets in a block
or based on equal time interval. The latter method offers better
control as it allows better account for capabilities of downstream
nodes to report statistics related to batches of packets and, at the
same time, time resolution that affects defect detection interval.
If the Single Mark measurement used, then the D flag MUST be set to
zero on transmit and ignored by monitoring point.
The S flag is used to create alternate flows to measure the packet
loss by switching value of the S flag. Delay metrics MAY be
calculated with the alternate flow using any of the following
methods:
- First/Last Batch Packet Delay calculation: timestamps are collected
based on order of arrival so this method is sensitive to packet loss
and re-ordering.
- Average Packet Delay calculation: an average delay is calculated by
considering the average arrival time of the packets within a single
block. This method only provides single metric for the duration of
the block and it doesn't give information about the delay
distribution.
1.2.2.2 Double Mark Measurement
Double Mark method allows more detailed measurement of delays for the
monitored flow but it requires more nodal and network resources. If
the Double Mark method used, then the S flag MUST be used to create
the alternate flow. The D flag MUST be used to mark single packets
to measure delay jitter.
The first marking (S flag alternation) is needed for packet loss and
also for average delay measurement. The second marking (D flag is
put to one) creates a new set of marked packets that are fully
identified and dedicated for delay. This method is useful to have
not only the average delay but also to know more about the statistic
distribution of delay values.
Elkins Expires April 24, 2019 [Page 5]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
1.3 IPv6 Transition Technologies
In the path to full implementation of IPv6, transition technologies
such as translation or tunneling may be employed. It is possible
that an IPv6 packet containing M-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 or a new HBH
option may simply drop the packet rather than translating it without
the extension header.
It is also possible that some devices in the network may not
correctly handle multiple IPv6 Extension Headers, including the IPv6
Destination Option. For example, adding the PDM header to a packet
may push the layer 4 information to a point in the packet where it is
not visible to filtering logic, and may be dropped. This kind of
situation is expected to become rare over time.
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
DADDR : IP address of the destination
DPORT : Port for destination
PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.)
The PDM contains the following base fields:
PSNTP : Packet Sequence Number This Packet
PSNLR : Packet Sequence Number Last Received
DELTATLR : Delta Time Last Received
DELTATLS : Delta Time Last Sent
This information, combined with the 5-tuple, allows the measurement
of the following metrics:
1. Round-trip delay
2. Server delay
These are further described in RFC8250 [RFC8250].
Performance measurements described in [RFC8321] are allowed.
Elkins Expires April 24, 2019 [Page 6]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
3 Marking and Performance and Diagnostic Metrics (M-PDM) Destination
Option Layout
3.1 Destination Options Header
The IPv6 Destination Options Header is used to carry 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 RFC8200
[RFC8200]. The IPv6 Marking and Performance and Diagnostic Metrics
Destination Option (M-PDM) is implemented as an IPv6 Option carried
in the Destination Options Header. M-PDM does not require time
synchronization.
3.2 Marking and Performance and Diagnostic Metrics (M-PDM) Destination
Option
3.2.1 M-PDM Layout
The IPv6 Marking and Performance and Diagnostic Metrics Destination
Option (M-PDM) contains the following fields:
PSNTP : Packet Sequence Number This Packet
PSNLR : Packet Sequence Number Last Received
DELTATLR : Delta Time Last Received
DELTATLS : Delta Time Last Sent
PDM has alignment requirements. Following the convention in IPv6,
these options are aligned in a packet so that multi-octet values
within the Option Data field of each option fall on natural
boundaries (i.e., fields of width n octets are placed at an integer
multiple of n octets from the start of the header, for n = 1, 2, 4,
or 8) [RFC8200].
The M-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 | Vrsn | RSVD | Marking |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN This Packet | PSN Last Received |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time Last Sent | Delta Time Last Received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Elkins Expires April 24, 2019 [Page 7]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
Option Type
TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780]
In keeping with RFC8200 [RFC8200], the two high-order bits of the
Option Type field are encoded to indicate specific processing of the
option; for the PDM destination option, these two bits MUST be set to
00.
The third high-order bit of the Option Type field specifies whether
or not the Option Data of that option can change en route to the
packet's final destination.
In M-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
10.
Version
4-bit unsigned integer.
Reserved
4-bit unsigned integer.
Marking
8-bit unsigned integer. (2 currently used - 6 reserved)
Packet Sequence Number This Packet (PSNTP)
16-bit unsigned integer. This field will wrap. It is intended for
use while analyzing packet traces.
This field is initialized at a random number and incremented
monotonically for each packet of the session flow of the IP stack.
The random-number initialization is intended to make it harder to
spoof and insert such packets.
Elkins Expires April 24, 2019 [Page 8]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
Packet Sequence Number Last Received (PSNLR)
16-bit unsigned integer. This is the PSNTP of the packet last
received by the IP stack.
This field is initialized to 0.
Delta Time Last Sent (DELTATLS)
16-bit unsigned integer.
Delta Time Last Sent = (receive time packet n - send time packet (n
- 1))
Delta Time Last Received (DELTATLR)
16-bit unsigned integer.
Delta Time Last Received = (send time packet n - receive time packet
(n - 1))
3.2.2 Base Unit for Time Measurement
Fixed base. TBD. [More information needs to be added here.]
3.3 Header Placement
The M-PDM Destination Option is placed as defined in RFC8200
[RFC8200]. 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 M-PDM Destination Options header.
For each IPv6 packet header, the M-PDM MUST NOT appear more than
once. However, an encapsulated packet MAY contain a separate M-PDM
associated with each encapsulated IPv6 header.
3.4 Header Placement Using IPSec ESP Mode
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 M-PDM is different depending on if ESP is used in
tunnel or transport mode.
Elkins Expires April 24, 2019 [Page 9]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
In ESP case, no 5-tuple is available, as there are no port numbers.
ESP flow should be identified only by using SADDR, DADDR and PROTOC.
The SPI numbers SHOULD be ignored when considering the flow over
which M-PDM information is measured.
3.4.1 Using ESP Transport Mode
Note that Destination Options may be placed before or after ESP or
both. If using M-PDM in ESP transport mode, M-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
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 M-PDM independent of the use of M-PDM of the original packet to
enable delay measurements between the two tunnel endpoints.
3.5 Implementation Considerations
3.5.1 M-PDM Activation
An implementation should provide an interface to enable or disable
the use of M-PDM. This specification recommends having M-PDM off by
default.
M-PDM MUST NOT be turned on merely if a packet is received with an M-
PDM header. The received packet could be spoofed by another device.
3.5.2 M-PDM Timestamps
The M-PDM timestamps are intended to isolate wire time from server or
host time, but may necessarily attribute some host processing time to
network latency.
RFC2330 [RFC2330] "Framework for IP Performance Metrics" describes
two notions of wire time in section 10.2. These notions are only
defined in terms of an Internet host H observing an Internet link L
at a particular location:
+ For a given IP packet P, the 'wire arrival time' of P at H on L
is the first time T at which any bit of P has appeared at H's
observational position on L.
Elkins Expires April 24, 2019 [Page 10]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
+ For a given IP packet P, the 'wire exit time' of P at H on L is
the first time T at which all the bits of P have appeared at H's
observational position on L.
This specification does not define the exact H's observing position
on L. That is left for the deployment setups to define. However, the
position where PDM timestamps are taken SHOULD be as close to the
physical network interface as possible. Not all implementations will
be able to achieve the ideal level of measurement.
3.6 Dynamic Configuration Options
If the M-PDM destination options extension header is used, then it
MAY 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
address only. These are at the discretion of the implementation.
3.7 Information Access and Storage
Measurement information provided by M-PDM may be made accessible for
higher layers or the user itself. Similar to activating the use of M-
PDM, the implementation may also provide an interface to indicate if
received.
M-PDM information may be stored, if desired. If a packet with M-PDM
information is received and the information should be stored, the
upper layers may be notified. Furthermore, the implementation should
define a configurable maximum lifetime after which the information
can be removed as well as a configurable maximum amount of memory
that should be allocated for PDM information.
Elkins Expires April 24, 2019 [Page 11]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
4 M-PDM HBH Option
The M-PDM Hop-by-Hop option is encoded in type-length-value (TLV)
format. It has an alignment requirement of 4n + 2. (See [IPv6,
Section 4.2] for discussion of option alignment.) The option has the
following format:
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 |Version|LastM |M | MType | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Middlebox Identifier | Timestamp In |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Out | PSN This Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Middlebox Identifier | Timestamp In |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Out | PSN This Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Middlebox Identifier | Timestamp In |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Out | PSN This Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Middlebox Identifier | Timestamp In |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Out | PSN This Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Middlebox Identifier | Timestamp In |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Out | PSN This Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780]
In keeping with RFC 8200 [RFC8200], the two high-order bits of the
Option Type field are encoded to indicate specific processing of the
option; for the M-PDM HBH option, these two bits MUST be set to 00.
The third high-order bit of the Option Type field specifies whether
or not the Option Data of that option can change en route to the
packet's final destination.
In M-PDM, the value of the third high-order bit MUST be 0.
Elkins Expires April 24, 2019 [Page 12]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
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
10.
Version
4-bit unsigned integer.
Last Middlebox
4-bit unsigned integer. Indicates which middlebox number was last
done. For example, 3 would indicate that this is the third
middlebox. This field could be used to quickly find which set of
data to fill. If there have been more than 5 middleboxes, then
wrapping will happen and fields will get overwritten.
Marking
2-bit unsigned integer.
Marking Type (M-Type)
4-bit unsigned integer. This indicates the type of marking method
being used for the timestamp.
If marking is not used, then the timestamp will be when the packet
left the IP interface on this middlebox.
If marking method is used, then this field will contain:
1 - the timestamp of the first packet of a marked batch 2 - the
average timestamp of the packets of a batch 3 - a double-marked
packet
RSVD
2-bit unsigned integer
Middle Box Identifier
16-bit unsigned integer.
Elkins Expires April 24, 2019 [Page 13]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
This field MUST be zero if not used. The zeros are intended to make
it harder to leak data via the HBH header.
This could be some portion of the IPv4 or IPv6 address or the router
ID. [Note to readers: any suggestions for this field are most
welcome!]
Timestamp In
16-bit unsigned integer. This can be the timestamp of the packet
received by the IP interface on this middlebox. If marking method is
used, it can identify the timestamp of the first packet of a marked
batch or the average timestamp of the packets of a batch or a double-
marked packet, depending on which method is used to perform delay
measurements.
This field is initialized to 0.
This timestamp is the delta in nanoseconds from the initial starting
timestamp of January 1, 2019 00:00:00.0000000000.
See the section on HBH Timestamps for more on this measurement.
Timestamp Out
16-bit unsigned integer. This can be the timestamp of the packet
left the IP interface on this middlebox. If marking method is used,
it can identify the timestamp of the first packet of a marked batch
or the average timestamp of the packets of a batch or a double-marked
packet, depending on which method is used to perform delay
measurements.
This field is initialized to 0.
This timestamp is the delta in nanoseconds from the initial starting
timestamp of January 1, 2019 00:00:00.0000000000.
See the section on HBH Timestamps for more on this measurement.
Packet Sequence Number This Packet (PSNTP)
16-bit unsigned integer. This field will wrap. It is intended for
use while analyzing packet traces.
This field is initialized at a random number and incremented
monotonically for each packet of the session flow of the IP stack.
Elkins Expires April 24, 2019 [Page 14]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
The random-number initialization is intended to make it harder to
spoof and insert such packets.
4.1 HBH Timestamps In and Out
The timestamp fields will contain the 16 high-order or most
significant bits of the delta between a fixed starting value of
January 1, 2019 00:00:00.0000000000 and the current time at the
middlebox.
For more on truncation of timestamp values, please see [TCPM].
5 Security Considerations
M-PDM may introduce some new security weaknesses.
5.1 Resource Consumption and Resource Consumption Attacks
M-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 misuse the control blocks to cause excessive
resource consumption. This could be used to compromise the end host.
M-PDM as a Destination is used at the end hosts and memory is used
only at the end host M-PDM as an HBH header is used at routers or
middle boxes.
5.2 Pervasive monitoring
Since M-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, in terms of the
Elkins Expires April 24, 2019 [Page 15]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
application level information such as web page, user name, user
password and so on, it appears to us that PDM is quite unhelpful in
this regard. Having said that, the ability to separate wire-time
from processing time may potentially provide an attacker with
additional information. It is conceivable that an attacker could
attempt to deduce the type of application in use by noting the server
time and payload length. 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.
5.3 M-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.
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
(destination host) detects some number of "nonsensical" sequence
numbers or timing information, it could take action to block,
discard, or alert on this traffic.
5.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 credentials of the device. For example, if an
Elkins Expires April 24, 2019 [Page 16]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
attacker can see that PDM is being used, then the attacker might use
PDM to launch a timing attack 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.
6 IANA Considerations
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]
Diagnostic Metrics
(M-PDM)
7 References
7.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines
For Values In the Internet Protocol and Related Headers", BCP 37, RFC
2780, March 2000.
Elkins Expires April 24, 2019 [Page 17]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
[RFC4303] Kent, S, "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July
2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8250] Elkins, N., Ackermann, M. and Hamilton, R. "IPv6
Performance and Diagnostic Metrics (PDM) Destination Option", RFC
8250, September 2017.
7.2 Informative References
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC8321] Fioccola, G. et al, "Alternate-Marking Method for Passive
and Hybrid Performance Monitoring", RFC 8321, January 2018.
[TCPM] Scheffenegger, R., Kuehlewind, M., and B. Trammell, "Encoding
of Time Intervals for the TCP Timestamp Option", Work in Progress,
draft-trammell-tcpm-timestamp-interval-01, July 2013
Acknowledgments
The authors would like to C.M. Heard for his review.
Elkins Expires April 24, 2019 [Page 18]
INTERNET DRAFT fear-ippm-mpdm-02 June 25, 2018
Authors' Addresses
Nalini Elkins
Inside Products, Inc.
36A Upper Circle
Carmel Valley, CA 93924
United States
Phone: +1 831 659 8360
Email: nalini.elkins@insidethestack.com
http://www.insidethestack.com
Giuseppe Fioccola
Telecom Italia
Via Reiss Romoli, 274
Torino 10148
Italy
Email: giuseppe.fioccola@telecomitalia.it
Michael S. Ackermann
Blue Cross Blue Shield of Michigan
P.O. Box 2888
Detroit, Michigan 48231
United States
Phone: +1 310 460 4080
Email: mackermann@bcbsm.com
Robert M. Hamilton
Chemical Abstracts Service
A Division of the American Chemical Society
2540 Olentangy River Road
Columbus, Ohio 43202
United States of America
Phone: +1 614 447 3600 x2517
Email: rhamilton@cas.org
Elkins Expires April 24, 2019 [Page 19]
