IPv6 Performance and Diagnostic Metrics (PDM) Destination Option
draft-ietf-ippm-6man-pdm-option-10
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8250.
|
|
---|---|---|---|
Authors | Nalini Elkins , Rob Hamilton , michael ackermann | ||
Last updated | 2017-05-09 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Last Call review
(of
-05)
by Jouni Korhonen
Ready w/issues
SECDIR Last Call review
(of
-05)
by Tero Kivinen
Serious Issues
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Al Morton | ||
Shepherd write-up | Show Last changed 2016-07-09 | ||
IESG | IESG state | Became RFC 8250 (Proposed Standard) | |
Consensus boilerplate | Yes | ||
Telechat date |
(None)
Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass. |
||
Responsible AD | Spencer Dawkins | ||
Send notices to | "Bill Cerveny" <ietf@wjcerveny.com>, "Al Morton" <acmorton@att.com> | ||
IANA | IANA review state | Version Changed - Review Needed |
draft-ietf-ippm-6man-pdm-option-10
Network Working Group M. Westerlund Internet-Draft Ericsson Intended status: Informational C. Perkins Expires: May 16, 2014 University of Glasgow November 12, 2013 Options for Securing RTP Sessions draft-ietf-avtcore-rtp-security-options-09 Abstract The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity and source authentication of RTP/RTCP packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP, and gives guidance for developers on how to choose the appropriate security mechanism. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on May 16, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Westerlund & Perkins Expires May 16, 2014 [Page 1] Internet-Draft Options for Securing RTP Sessions November 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Point-to-Point Sessions . . . . . . . . . . . . . . . . . 4 2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 4 2.3. Sessions Using an RTP Translator . . . . . . . . . . . . 5 2.3.1. Transport Translator (Relay) . . . . . . . . . . . . 5 2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 7 2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 7 2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 7 3. Security Options . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . 11 3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 12 3.1.3. Key Management for SRTP: Security Descriptions . . . 14 3.1.4. Key Management for SRTP: Encrypted Key Transport . . 15 3.1.5. Key Management for SRTP: Other systems . . . . . . . 15 3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 16 3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.4. RTP over TLS over TCP . . . . . . . . . . . . . . . . . . 16 3.5. RTP over Datagram TLS (DTLS) . . . . . . . . . . . . . . 17 3.6. Media Content Security/Digital Rights Management . . . . 17 3.6.1. ISMA Encryption and Authentication . . . . . . . . . 18 4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 18 4.1. Application Requirements . . . . . . . . . . . . . . . . 18 4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 19 4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 20 4.1.3. Source Authentication . . . . . . . . . . . . . . . . 20 4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 22 4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 22 4.2. Application Structure . . . . . . . . . . . . . . . . . . 23 4.3. Automatic Key Management . . . . . . . . . . . . . . . . 23 4.4. End-to-End Security vs Tunnels . . . . . . . . . . . . . 24 4.5. Plain Text Keys . . . . . . . . . . . . . . . . . . . . . 24 4.6. Interoperability . . . . . . . . . . . . . . . . . . . . 25 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.1. Media Security for SIP-established Sessions using DTLS- SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 26 Westerlund & Perkins Expires May 16, 2014 [Page 2] Internet-Draft Options for Securing RTP Sessions November 2013 5.3. IP Multimedia Subsystem (IMS) Media Security . . . . . . 27 5.4. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 28 5.5. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 29 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 9. Informative References . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction Real-time Transport Protocol (RTP) [RFC3550] is widely used in a large variety of multimedia applications, including Voice over IP (VoIP), centralized multimedia conferencing, sensor data transport, and Internet television (IPTV) services. These applications can range from point-to-point phone calls, through centralised group teleconferences, to large-scale television distribution services. The types of media can vary significantly, as can the signalling methods used to establish the RTP sessions. This multi-dimensional heterogeneity has so far prevented development of a single security solution that meets the needs of the different applications. Instead significant number of different solutions have been developed to meet different sets of security goals. This makes it difficult for application developers to know what solutions exist, and whether their properties are appropriate. This memo gives an overview of the available RTP solutions, and provides guidance on their applicability for different application domains. It also attempts to provide indication of actual and intended usage at time of writing as additional input to help with considerations such as interoperability, availability of implementations etc. The guidance provided is not exhaustive, and this memo does not provide normative recommendations. It is important that application developers consider the security goals and requirements for their application. The IETF considers it important that protocols implement, and makes available to the user, secure modes of operation [RFC3365]. Because of the heterogeneity of RTP applications and use cases, however, a single security solution cannot be mandated [I-D.ietf-avt-srtp-not-mandatory]. Instead, application developers need to select mechanisms that provide appropriate security for their environment. It is strongly encouraged that common mechanisms are used by related applications in common environments. The IETF publishes guidelines for specific classes of applications, so it is worth searching for such guidelines. Westerlund & Perkins Expires May 16, 2014 [Page 3] Internet-Draft Options for Securing RTP Sessions November 2013 The remainder of this document is structured as follows. Section 2 provides additional background. Section 3 outlines the available security mechanisms at the time of this writing, and lists their key security properties and constraints. That is followed by guidelines and important aspects to consider when securing an RTP application in Section 4. Finally, we give some examples of application domains where guidelines for security exist in Section 5. 2. Background RTP can be used in a wide variety of topologies due to its support for point-to-point sessions, multicast groups, and other topologies built around different types of RTP middleboxes. In the following we review the different topologies supported by RTP to understand their implications for the security properties and trust relations that can exist in RTP sessions. 2.1. Point-to-Point Sessions The most basic use case is two directly connected end-points, shown in Figure 1, where A has established an RTP session with B. In this case the RTP security is primarily about ensuring that any third party can"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2 Rationale for defined solution The current IPv6 specification does not provide timing nor a similar field in the IPv6 main header or in any extension header. The IPv6 Performance and Diagnostic Metrics destination option (PDM) provides such fields. Advantages include: 1. Real measure of actual transactions. 2. Independence from transport layer protocols. 3. Ability to span organizational boundaries with consistent instrumentation. 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 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. Elkins Expires November 10, 2017 [Page 5] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 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. 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 Other fields for storing time scaling factors are also in the PDM and will be described in section 3. This information, combined with the 5-tuple, allows the measurement of the following metrics: 1. Round-trip delay 2. Server delay 2.1 Round-Trip Delay Round-trip *Network* delay is the delay for packet transfer from a source host to a destination host and then back to the source host. This measurement has been defined, and the advantages and disadvantages discussed in "A Round-trip Delay Metric for IPPM" [RFC2681]. Elkins Expires November 10, 2017 [Page 6] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 2.2 Server Delay Server delay is the interval between when a packet is received by a device and the first corresponding packet is sent back in response. This may be "Server Processing Time". It may also be a delay caused by acknowledgements. Server processing time includes the time taken by the combination of the stack and application to return the response. The stack delay may be related to network performance. If this aggregate time is seen as a problem, and there is a need to make a clear distinction between application processing time and stack delay, including that caused by the network, then more client based measurements are needed. 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. 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 Elkins Expires November 10, 2017 [Page 7] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 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 | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta Time Last Received | Delta Time Last Sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780] In keeping with RFC2460[RFC2460], 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 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. 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) 8-bit signed integer. This is the scaling value for the Delta Time Last Sent (DELTATLS) field. The possible values are from 0 to 255. Elkins Expires November 10, 2017 [Page 8] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 Packet Sequence Number This Packet (PSNTP) 16-bit unsigned integer. This field will wrap. It is intended for use while analyzing packet traces. Initialized at a random number and incremented monotonically for each packet of the session flow of the 5-tuple. The random number initialization is intended to make it harder to spoof and insert such packets. Operating systems MUST implement a separate packet sequence number counter per 5-tuple. Packet Sequence Number Last Received (PSNLR) 16-bit unsigned integer. This is the PSNTP of the packet last received on the 5-tuple. This field is initialized to 0. Delta Time Last Received (DELTATLR) A 16-bit unsigned integer field. The value is set according to the scale in SCALEDTLR. Delta Time Last Received = (Send time packet n - Receive time packet n-1) Delta Time Last Sent (DELTATLS) A 16-bit unsigned integer field. The value is set according to the scale in SCALEDTLS. Delta Time Last Sent = (Receive time packet n - Send time packet n-1) 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 Elkins Expires November 10, 2017 [Page 9] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 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. 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 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 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 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 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 Elkins Expires November 10, 2017 [Page 10] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 #x27;t compromise the confidentiality and integrity of the media communication. This requires confidentiality protection of the RTP session, integrity protection of the RTP/RTCP packets, and source authentication of all the packets to ensure no man-in-the-middle attack is taking place. The source authentication can also be tied to a user or an end- point's verifiable identity to ensure that the peer knows who they are communicating with. Here the combination of the security protocol protecting the RTP session and its RTP and RTCP traffic and the key-management protocol becomes important in which security statements one can do. +---+ +---+ | A |<------->| B | +---+ +---+ Figure 1: Point-to-point topology 2.2. Sessions Using an RTP Mixer An RTP mixer is an RTP session-level middlebox that one can build a multi-party RTP based conference around. The RTP mixer might actually perform media mixing, like mixing audio or compositing video images into a new media stream being sent from the mixer to a given participant; or it might provide a conceptual stream, for example the Westerlund & Perkins Expires May 16, 2014 [Page 4] Internet-Draft Options for Securing RTP Sessions November 2013 video of the current active speaker. From a security point of view, the important features of an RTP mixer is that it generates a new media stream, and has its own source identifier, and does not simply forward the original media. An RTP session using a mixer might have a topology like that in Figure 2. In this example, participants A through D each send unicast RTP traffic to the RTP mixer, and receive an RTP stream from the mixer, comprising a mixture of the streams from the other participants. +---+ +------------+ +---+ | A |<---->| |<---->| B | +---+ | | +---+ | Mixer | +---+ | | +---+ | C |<---->| |<---->| D | +---+ +------------+ +---+ Figure 2: Example RTP mixer Topology A consequence of an RTP mixer having its own source identifier, and acting as an active participant towards the other end-points is that the RTP mixer needs to be a trusted device that has access to the security context(s) established. The RTP mixer can also become a security enforcing entity. For example, a common approach to secure the topology in Figure 2 is to establish a security context between the mixer and each participant independently, and have the mixer source authenticate each peer. The mixer then ensures that one participant cannot impersonate another. 2.3. Sessions Using an RTP Translator RTP translators are middleboxes that provide various levels of in- network media translation and transcoding. Their security properties vary widely, depending on which type of operations they attempt to perform. We identify three different categories of RTP translator: transport translators, gateways, and media transcoders. We discuss each in turn. 2.3.1. Transport Translator (Relay) A transport translator [RFC5117] operates on a level below RTP and RTCP. It relays the RTP/RTCP traffic from one end-point to one or more other addresses. This can be done based only on IP addresses and transport protocol ports, with each receive port on the translator can have a very basic list of where to forward traffic. Transport translators also need to implement ingress filtering to Westerlund & Perkins Expires May 16, 2014 [Page 5] Internet-Draft Options for Securing RTP Sessions November 2013 prevent random traffic from being forwarded that isn't coming from a participant in the conference. Figure 3 shows an example transport translator, where traffic from any one of the four participants will be forwarded to the other three participants unchanged. The resulting topology is very similar to Any Source Multicast (ASM) session (as discussed in Section 2.4), but implemented at the application layer. +---+ +------------+ +---+ | A |<---->| |<---->| B | +---+ | Relay | +---+ | Translator | +---+ | | +---+ | C |<---->| |<---->| D | +---+ +------------+ +---+ Figure 3: RTP relay translator topology A transport translator can often operate without needing access to the security context, as long as the security mechanism does not provide protection over the transport-layer information. A transport translator does, however, make the group communication visible, and so can complicate keying and source authentication mechanisms. This is further discussed in Section 2.4. 2.3.2. Gateway Gateways are deployed when the endpoints are not fully compatible. Figure 4 shows an example topology. The functions a gateway provides can be diverse, and range from transport layer relaying between two domains not allowing direct communication, via transport or media protocol function initiation or termination, to protocol or media encoding translation. The supported security protocol might even be one of the reasons a gateway is needed. +---+ +-----------+ +---+ | A |<---->| Gateway |<---->| B | +---+ +-----------+ +---+ Figure 4: RTP gateway topology The choice of security protocol, and the details of the gateway function, will determine if the gateway needs to be trusted with access to the application security context. Many gateways need to be trusted by all peers to perform the translation; in other cases some or all peers might not be aware of the presence of the gateway. The security protocols have different properties depending on the degree Westerlund & Perkins Expires May 16, 2014 [Page 6] Internet-Draft Options for Securing RTP Sessions November 2013 of trust and visibility needed. Ensuring communication is possible without trusting the gateway can be strong incentive for accepting different security properties. Some security solutions will be able to detect the gateways as manipulating the media stream, unless the gateway is a trusted device. 2.3.3. Media Transcoder A Media transcoder is a special type of gateway device that changes the encoding of the media being transported by RTP. The discussion in Section 2.3.2 applies. A media transcoder alters the media data, and thus needs to be trusted with access to the security context. 2.4. Any Source Multicast Any Source Multicast [RFC1112] is the original multicast model where any multicast group participant can send to the multicast group, and get their packets delivered to all group members (see Figure 5). This form of communication has interesting security properties, due to the many-to-many nature of the group. Source authentication is important, but all participants with access to group security context will have the necessary secrets to decrypt and verify integrity of the traffic. Thus use of any group security context fails if the goal is to separate individual sources; alternate solutions are needed. +-----+ +---+ / \ +---+ | A |----/ \---| B | +---+ / Multi- \ +---+ + Cast + +---+ \ Network / +---+ | C |----\ /---| D | +---+ \ / +---+ +-----+ Figure 5: Any source multicast (ASM) group In addition the potential large size of multicast groups creates some considerations for the scalability of the solution and how the key- management is handled. 2.5. Source-Specific Multicast Source-Specific Multicast [RFC4607] allows only a specific end-point to send traffic to the multicast group, irrespective of the number of RTP media sources. The end-point is known as the media Distribution Source. For RTP session to function correctly with RTCP over an SSM Westerlund & Perkins Expires May 16, 2014 [Page 7] Internet-Draft Options for Securing RTP Sessions November 2013 session extensions have been defined in [RFC5760]. Figure 6 shows a sample SSM-based RTP session where several media sources, MS1...MSm, all send media to a Distribution Source, which then forwards the media data to the SSM group for delivery to the receivers, R1...Rn, and the Feedback Targets, FT1...FTn. RTCP reception quality feedback is sent unicast from each receiver to one of the Feedback Targets. The feedback targets aggregate reception quality feedback and forward it upstream towards the distribution source. The distribution source forwards (possibly aggregated and summarised) reception feedback to the SSM group, and back to the original media sources. The feedback targets are also members of the SSM group and receive the media data, so they can send unicast repair data to the receivers in response to feedback if appropriate. +-----+ +-----+ +-----+ | MS1 | | MS2 | .... | MSm | +-----+ +-----+ +-----+ ^ ^ ^ | | | V V V +---------------------------------+ | Distribution Source | +--------+ | | FT Agg | | +--------+------------------------+ ^ ^ | : . | : +...................+ : | . : / \ . +------+ / \ +-----+ | FT1 |<----+ +----->| FT2 | +------+ / \ +-----+ ^ ^ / \ ^ ^ : : / \ : : : : / \ : : : : / \ : : : ./\ /\. : : /. \ / .\ : : V . V V . V : +----+ +----+ +----+ +----+ | R1 | | R2 | ... |Rn-1| | Rn | +----+ +----+ +----+ +----+ Figure 6: Example SSM-based RTP session with two feedback targets The use of SSM makes it more difficult to inject traffic into the multicast group, but not impossible. Source authentication Westerlund & Perkins Expires May 16, 2014 [Page 8] Internet-Draft Options for Securing RTP Sessions November 2013 requirements apply for SSM sessions too, and an individual verification of who sent the RTP and RTCP packets is needed. An RTP session using SSM will have a group security context that includes the media sources, distribution source, feedback targets, and the receivers. Each has a different role and will be trusted to perform different actions. For example, the distribution source will need to authenticate the media sources to prevent unwanted traffic being distributed via the SSM group. Similarly, the receivers need to authenticate both the distribution source and their feedback target, to prevent injection attacks from malicious devices claiming to be feedback targets. An understanding of the trust relationships and group security context is needed between all components of the system. 3. Security Options This section provides an overview of security requirements, and the current RTP security mechanisms that implement those requirements. This cannot be a complete survey, since new security mechanisms are defined regularly. The goal is to help applications designer by reviewing the types of solution that are available. This section will use a number of different security related terms, described in the Internet Security Glossary, Version 2 [RFC4949]. 3.1. Secure RTP The Secure RTP (SRTP) protocol [RFC3711] is one of the most commonly used mechanisms to provide confidentiality, integrity protection, source authentication and replay protection for RTP. SRTP was developed with RTP header compression and third party monitors in mind. Thus the RTP header is not encrypted in RTP data packets, and the first 8 bytes of the first RTCP packet header in each compound RTCP packet are not encrypted. The entirety of RTP packets and compound RTCP packets are integrity protected. This allows RTP header compression to work, and lets third party monitors determine what RTP traffic flows exist based on the SSRC fields, but protects the sensitive content. SRTP works with transforms where different combinations of encryption algorithm, authentication algorithm, and pseudo-random function can be used, and the authentication tag length can be set to any value. SRTP can also be easily extended with additional cryptographic transforms. This gives flexibility, but requires more security knowledge by the application developer. To simplify things, SDP Security Descriptions (see Section 3.1.3) and DTLS-SRTP (see Section 3.1.1) use pre-defined combinations of transforms, known as SRTP crypto suites and SRTP protection profiles, that bundle together transforms and other parameters, making them easier to use but Westerlund & Perkins Expires May 16, 2014 [Page 9] Internet-Draft Options for Securing RTP Sessions November 2013 3.5 Implementation Considerations 3.5.1 PDM Activation An implementation should provide an interface to enable or disable the use of PDM. This specification recommends having PDM off by default. PDM MUST NOT be turned on merely if a packet is received with a PDM header. The received packet could be spoofed by another device. 3.5.2 PDM Timestamps The 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. + 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 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 PDM may be made accessible for higher layers or the user itself. Similar to activating the use of Elkins Expires November 10, 2017 [Page 11] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 PDM, the implementation may also provide an interface to indicate if received PDM information may be stored, if desired. If a packet with 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. 4 Security Considerations PDM may introduce some new security weaknesses. 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 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. Elkins Expires November 10, 2017 [Page 12] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 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 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 detects some number of "nonsensical" sequence numbers it could take action to block (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. 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. Elkins Expires November 10, 2017 [Page 13] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 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 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 (PDM) 6 References 6.1 Normative References [RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC 1122, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [RFC4303] Kent, S, "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. Elkins Expires November 10, 2017 [Page 14] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 6.2 Informative References [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [TRAM-TCPM] Trammel, B., "Encoding of Time Intervals for the TCP Timestamp Option-01", Internet Draft, July 2013. [Work in Progress] Appendix A: Context for PDM A.1 End User Quality of Service (QoS) The timing values in the PDM embedded in the packet will be used to estimate QoS as experienced by an end user device. For many applications, the key user performance indicator is response time. When the end user is an individual, he is generally indifferent to what is happening along the network; what he really cares about is how long it takes to get a response back. But this is not just a matter of individuals' personal convenience. In many cases, rapid response is critical to the business being conducted. Low, reliable and acceptable response times are not just "nice to have". On many networks, the impact can be financial hardship or can endanger human life. In some cities, the emergency police contact system operates over IP; law enforcement, at all levels, use IP networks; transactions on our stock exchanges are settled using IP networks. The critical nature of such activities to our daily lives and financial well-being demand a simple solution to support response time measurements. A.2 Need for a Packet Sequence Number (PSN) While performing network diagnostics of an end-to-end connection, it often becomes necessary to isolate the factors along the network path responsible for problems. Diagnostic data may be collected at multiple places along the path (if possible), or at the source and destination. Then, in post-collection processing, the diagnostic data corresponding to each packet at different observation points must be matched for proper measurements. A sequence number in each packet provides sufficient basis for the matching process. If need be, the timing fields may be used along with the sequence number to ensure uniqueness. This method of data collection along the path is of special use to determine where packet loss or packet corruption is happening. Elkins Expires November 10, 2017 [Page 15] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 The packet sequence number needs to be unique in the context of the session (5-tuple). A.3 Rationale for Defined Solution One of the important functions of PDM is to allow you to do quickly dispatch the right set of diagnosticians. Within network or server latency, there may be many components. The job of the diagnostician is to rule each one out until the culprit is found. How PDM fits into this diagnostic picture is that PDM will quickly tell you how to escalate. PDM will point to either the network area or the server area. Within the server latency, PDM does not tell you if the bottleneck is in the IP stack or the application or buffer allocation. Within the network latency, PDM does not tell you which of the network segments or middle boxes is at fault. What PDM does tell you is whether the problem is in the network or the server. A.4 Use PDM with Other Headers For diagnostics, one my want to use PDM with other headers (L2, L3, etc). For example, if PDM is used is by a technician (or tool) looking at a packet capture, within the packet capture, they would have available to them the layer 2 header, IP header (v6 or v4), TCP, UCP, ICMP, SCTP or other headers. All information would be looked at together to make sense of the packet flow. The technician or processing tool could analyze, report or ignore the data from PDM, as necessary. For an example of how PDM can help with TCP retransmit problems, please look at Appendix C. Elkins Expires November 10, 2017 [Page 16] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 Appendix B : Timing Considerations B.1 Timing Differential Calculations The time counter in a CPU is a binary whole number, representing a number of milliseconds (msec), microseconds (usec) or even picoseconds (psec). Representing one of these values as attoseconds (asec) means multiplying by 10 raised to some exponent. Refer to this table of equalities: Base value = # of sec = # of asec 1000s of asec --------------- ------------- ------------- ------------- 1 second 1 sec 10**18 asec 1000**6 asec 1 millisecond 10**-3 sec 10**15 asec 1000**5 asec 1 microsecond 10**-6 sec 10**12 asec 1000**4 asec 1 nanosecond 10**-9 sec 10**9 asec 1000**3 asec 1 picosecond 10**-12 sec 10**6 asec 1000**2 asec 1 femtosecond 10**-15 sec 10**3 asec 1000**1 asec For example, if you have a time differential expressed in microseconds, since each microsecond is 10**12 asec, you would multiply your time value by 10**12 to obtain the number of attoseconds. If you time differential is expressed in nanoseconds, you would multiply by 10**9 to get the number of attoseconds. The result is a binary value that will need to be shortened by a number of bits so it will fit into the 16-bit PDM DELTA field. The next step is to divide by 2 until the value is contained in just 16 significant bits. The exponent of the value in the last column of of the table is useful here; the initial scaling factor is that exponent multiplied by 10. This is the minimum number of low-order bits to be shifted-out or discarded. It represents dividing the time value by 1024 raised to that exponent. The resulting value may still be too large to fit into 16 bits, but can be normalized by shifting out more bits (dividing by 2) until the value fits into the 16-bit DELTA field. The number of extra bits shifted out is then added to the scaling factor. The scaling factor, the total number of low-order bits dropped, is the SCALEDTL value. For example: say an application has these start and finish timer values (hexadecimal values, in microseconds): Finish: 27C849234 usec (02:57:58.997556) -Start: 27C83F696 usec (02:57:58.957718) ========== ========= =============== Difference 9B9E usec 00.039838 sec or 39838 usec Elkins Expires November 10, 2017 [Page 17] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 To convert this differential value to binary attoseconds, multiply the number of microseconds by 10**12. Divide by 1024**4, or simply discard 40 bits from the right. The result is 36232, or 8D88 in hex, with a scaling factor or SCALEDTL value of 40. For another example, presume the time differential is larger, say 32.311072 seconds, which is 32311072 usec. Each microsecond is 10**12 asec, so multiply by 10**12, giving the hexadecimal value 1C067FCCAE8120000. Using the initial scaling factor of 40, drop the last 10 characters (40 bits) from that string, giving 1C067FC. This will not fit into a DELTA field, as it is 25 bits long. Shifting the value to the right another 9 bits results in a DELTA value of E033, with a resulting scaling factor of 49. When the time differential value is a small number, regardless of the time unit, the exponent trick given above is not useful in determining the proper scaling value. For example, if the time differential is 3 seconds and you want to convert that directly, you would follow this path: 3 seconds = 3*10**18 asec (decimal) = 29A2241AF62C0000 asec (hexadecimal) If you just truncate the last 60 bits, you end up with a delta value of 2 and a scaling factor of 60, when what you really wanted was a delta value with more significant digits. The most precision with which you can store this value in 16 bits is A688, with a scaling factor of 46. B.2 Considerations of this time-differential representation There are a few considerations to be taken into account with this representation of a time differential. The first is whether there are any limitations on the maximum or minimum time differential that can be expressed using method of a delta value and a scaling factor. The second is the amount of imprecision introduced by this method. B.2.1 Limitations with this encoding method The DELTATLS and DELTATLR fields store only the 16 most-significant bits of the time differential value. Thus the range, excluding the scaling factor, is from 0 to 65535, or a maximum of 2**16-1. This method is further described in [TRAM-TCPM]. The actual magnitude of the time differential is determined by the scaling factor. SCALEDTLR and SCALEDTLS are 8-bit unsigned integers, so the scaling factor ranges from 0 to 255. The smallest number that can be represented would have a value of 1 in the delta field and a Elkins Expires November 10, 2017 [Page 18]reducing flexibility. The MIKEY protocol (see Section 3.1.2) provides flexibility to negotiate the full selection of transforms. At the time of this writing, the following transforms, SRTP crypto suites, and SRTP protection profiles are defined or under definition: AES-CM and HMAC-SHA-1: AES Counter Mode encryption with 128-bit keys combined with 160-bit keyed HMAC-SHA-1 with 80-bit authentication tag. This is the default cryptographic transform that needs to be supported. The transforms are defined in SRTP [RFC3711], with the corresponding SRTP crypto suite in [RFC4568] and SRTP protection profile in [RFC5764]. AES-f8 and HMAC-SHA-1: AES f8 mode encryption using 128-bit keys combined with keyed HMAC-SHA-1 using 80-bit authentication. The transforms are defined in [RFC3711], with the corresponding SRTP crypto suite in [RFC4568]. The corresponding SRTP protection profile is not defined. SEED: A Korean national standard cryptographic transform that is defined to be used with SRTP in [RFC5669]. Three options are defined, one using SHA-1 authentication, one using Counter mode with CBC-MAC, and finally one using Galois Counter mode. ARIA: A Korean block cipher [I-D.ietf-avtcore-aria-srtp], that supports 128-, 192- and 256- bit keys. It also defines three options, Counter mode where combined with HMAC-SHA-1 with 80 or 32 bits authentication tags, Counter mode with CBC-MAC and Galois Counter mode. It also defines a different key derivation function than the AES based systems. AES-192-CM and AES-256-CM: Cryptographic transforms for SRTP based on AES-192 and AES-256 counter mode encryption and 160-bit keyed HMAC-SHA-1 with 80- and 32-bit authentication tags. These provide 192- and 256-bit encryption keys, but otherwise match the default 128-bit AES-CM transform. The transforms are defined in [RFC3711] and [RFC6188], with the SRTP crypto suites in [RFC6188]. AES-GCM and AES-CCM: AES Galois Counter Mode and AES Counter with CBC MAC for AES-128 and AES-256. This authentication is included in the cipher text which becomes expanded with the length of the authentication tag instead of using the SRTP authentication tag. This is defined in [I-D.ietf-avtcore-srtp-aes-gcm]. NULL: SRTP [RFC3711] also provides a NULL cipher that can be used when no confidentiality for RTP/RTCP is requested. The corresponding SRTP protection profile is defined in [RFC5764]. Westerlund & Perkins Expires May 16, 2014 [Page 10] Internet-Draft Options for Securing RTP Sessions November 2013 The source authentication guarantees provided by SRTP depend on the cryptographic transform and key-management used. Some transforms give strong source authentication even in multiparty sessions; others give weaker guarantees and can authenticate group membership but not sources. TESLA [RFC4383] offers a complement to the regular symmetric keyed authentication transforms, like HMAC-SHA-1, and can provide per-source authentication in some group communication scenarios. The downside is need for buffering the packets for a while before authenticity can be verified. [RFC4771] defines a variant of the authentication tag that enables a receiver to obtain the Roll over Counter for the RTP sequence number that is part of the Initialization vector (IV) for many cryptographic transforms. This enables quicker and easier options for joining a long lived secure RTP group, for example a broadcast session. RTP header extensions are normally carried in the clear and only integrity protected in SRTP. This can be problematic in some cases, so [RFC6904] defines an extension to also encrypt selected header extensions. SRTP is specified and deployed in a number of RTP usage contexts; Significant support in SIP-established VoIP clients including IMS; RTSP [I-D.ietf-mmusic-rfc2326bis] and RTP based media streaming. Thus SRTP in general is widely deployed. When it comes to cryptographic transforms the default (AES-CM and HMAC-SHA-1) is the most commonly used, but it might be expected that AES-GCM, AES-192-CM, and AES-256-CM will gain usage in future, especially due to the AES- and GCM-specific instructions in new CPUs. SRTP does not contain an integrated key-management solution, and instead relies on an external key management protocol. There are several protocols that can be used. The following sections outline some popular schemes. 3.1.1. Key Management for SRTP: DTLS-SRTP A Datagram Transport Layer Security extension exists for establishing SRTP keys [RFC5763][RFC5764]. This extension provides secure key- exchange between two peers, enabling perfect forward secrecy and binding strong identity verification to an end-point. The default key generation will generate a key that contains material contributed by both peers. The key-exchange happens in the media plane directly between the peers. The common key-exchange procedures will take two round trips assuming no losses. TLS resumption can be used when establishing additional media streams with the same peer, and reduces the set-up time to one RTT for these streams (see [RFC5764] for a discussion of TLS resumption in this context). Westerlund & Perkins Expires May 16, 2014 [Page 11] Internet-Draft Options for Securing RTP Sessions November 2013 The actual security properties of an established SRTP session using DTLS will depend on the cipher suites offered and used, as well as the mechanism for identifying the end-points of the hand-shake. For example some cipher suits provide perfect forward secrecy (PFS), while other do not. When using DTLS, the application designer needs to select which cipher suites DTLS-SRTP can offer and accept so that the desired security properties are achieved. The next choice is how to verify the identity of the peer end-point. One choice can be to rely on the certificates and use a PKI to verify them to make an identity assertion. However, this is not the most common way, instead self-signed certificate are common to use, and instead establish trust through signalling or other third party solutions. DTLS-SRTP key management can use the signalling protocol in four ways. First, to agree on using DTLS-SRTP for media security. Secondly, to determine the network location (address and port) where each side is running a DTLS listener to let the parts perform the key-management handshakes that generate the keys used by SRTP. Thirdly, to exchange hashes of each side's certificates to bind these to the signalling, and ensure there is no man-in-the-middle attack. This assumes that one can trust the signalling solution to be resistant to modification, and not be in collaboration with an attacker. Finally to provide an assertable identity, e.g. [RFC4474] that can be used to prevent modification of the signalling and the exchange of certificate hashes. That way enabling binding between the key-exchange and the signalling. This usage is well defined for SIP/SDP in [RFC5763], and in most cases can be adopted for use with other bi-directional signalling solutions. It is to be noted that there is work underway to revisit the SIP Identity mechanism [RFC4474] in the IETF STIR working group. The main question regarding DTLS-SRTP's security properties is how one verifies any peer identity or at least prevents man-in-the-middle attacks. This do requires trust in some DTLS-SRTP external party, either a PKI, a signalling system or some identity provider. DTLS-SRTP usage is clearly on the rise. It is mandatory to support in WebRTC. It has growing support among SIP end-points. DTLS-SRTP was developed in IETF primarily to meet security requirements for SIP. 3.1.2. Key Management for SRTP: MIKEY Westerlund & Perkins Expires May 16, 2014 [Page 12] Internet-Draft Options for Securing RTP Sessions November 2013 Multimedia Internet Keying (MIKEY) [RFC3830] is a keying protocol that has several modes with different properties. MIKEY can be used in point-to-point applications using SIP and RTSP (e.g., VoIP calls), but is also suitable for use in broadcast and multicast applications, and centralized group communications. MIKEY can establish multiple security contexts or cryptographic sessions with a single message. It is useable in scenarios where one entity generates the key and needs to distribute the key to a number of participants. The different modes and the resulting properties are highly dependent on the cryptographic method used to establish the session keys actually used by the security protocol, like SRTP. MIKEY has the following modes of operation: Pre-Shared Key: Uses a pre-shared secret for symmetric key crypto used to secure a keying message carrying the already generated session key. This system is the most efficient from the perspective of having small messages and processing demands. The downside is scalability, where usually the effort for the provisioning of pre-shared keys is only manageable if the number of endpoints is small. Public Key encryption: Uses a public key crypto to secure a keying message carrying the already-generated session key. This is more resource intensive but enables scalable systems. It does require a public key infrastructure to enable verification. Diffie-Hellman: Uses Diffie-Hellman key-agreement to generate the session key, thus providing perfect forward secrecy. The downside is high resource consumption in bandwidth and processing during the MIKEY exchange. This method can't be used to establish group keys as each pair of peers performing the MIKEY exchange will establish different keys. HMAC-Authenticated Diffie-Hellman: [RFC4650] defines a variant of the Diffie-Hellman exchange that uses a pre-shared key in a keyed HMAC to verify authenticity of the keying material instead of a digital signature as in the previous method. This method is still restricted to point-to-point usage. RSA-R: MIKEY-RSA in Reverse mode [RFC4738] is a variant of the public key method which doesn't rely on the initiator of the key- exchange knowing the responder's certificate. This method lets both the initiator and the responder to specify the session keying material depending on use case. Usage of this mode requires one round-trip time. Westerlund & Perkins Expires May 16, 2014 [Page 13] Internet-Draft Options for Securing RTP Sessions November 2013 TICKET: [RFC6043] is a MIKEY extension using a trusted centralized key management service (KMS). The Initiator and Responder do not share any credentials; instead, they trust a third party, the KMS, with which they both have or can establish shared credentials. IBAKE: [RFC6267] uses a key management services (KMS) infrastructure but with lower demand on the KMS. Claims to provides both perfect forward and backwards secrecy, the exact meaning is unclear (See Perfect Forward Secrecy in [RFC4949]). SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption in MIKEY. Based on Identity based Public Key Cryptography and a KMS infrastructure to establish a shared secret value and certificate less signatures to provide source authentication. Its features include simplex transmission, scalability, low-latency call set- up, and support for secure deferred delivery. MIKEY messages have several different transports. [RFC4567] defines how MIKEY messages can be embedded in general SDP for usage with the signalling protocols SIP, SAP and RTSP. There also exist a 3GPP defined usage of MIKEY that sends MIKEY messages directly over UDP [T3GPP.33.246] to key the receivers of Multimedia Broadcast and Multicast Service (MBMS) [T3GPP.26.346]. [RFC3830] defines the application/mikey media type allowing MIKEY to be used in, e.g., email and HTTP. Based on the many choices it is important to consider the properties needed in ones solution and based on that evaluate which modes that are candidates for ones usage. More information on the applicability of the different MIKEY modes can be found in [RFC5197]. MIKEY with pre-shared keys are used by 3GPP MBMS [T3GPP.33.246] and IMS media security [T3GPP.33.328] specifies the use of the TICKET mode transported over SIP and HTTP. RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] specifies use of the RSA-R mode. There are some SIP end-points that support MIKEY. The modes they use are unknown to the authors. 3.1.3. Key Management for SRTP: Security Descriptions [RFC4568] provides a keying solution based on sending plain text keys in SDP [RFC4566]. It is primarily used with SIP and the SDP Offer/ Answer model, and is well-defined in point-to-point sessions where each side declares its own unique key. Using Security Descriptions to establish group keys is less well defined, and can have security issues since it's difficult to guarantee unique SSRCs (as needed to avoid a "two-time pad" attack - see Section 9 of [RFC3711]). Westerlund & Perkins Expires May 16, 2014 [Page 14] Internet-Draft Options for Securing RTP Sessions November 2013 Since keys are transported in plain text in SDP, they can easily be intercepted unless the SDP carrying protocol provides strong end-to- end confidentiality and authentication guarantees. This is not normally the case, where instead hop-by-hop security is provided between signalling nodes using TLS. This leaves the keying material sensitive to capture by the traversed signalling nodes. Thus, in most cases, the security properties of security descriptions are weak. The usage of security descriptions usually requires additional security measures, e.g. the signalling nodes be trusted and protected by strict access control. Usage of security descriptions requires careful design in order to ensure that the security goals can be met. Security Descriptions is the most commonly deployed keying solution for SIP-based end-points, where almost all end-points that support SRTP also support Security Descriptions. It is also used for access protection in IMS Media Security [T3GPP.33.328]. 3.1.4. Key Management for SRTP: Encrypted Key Transport Encrypted Key Transport (EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP extension that enables group keying despite using a keying mechanism like DTLS-SRTP that doesn& INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 value of 0 in the associated scale field. This is the representation for 1 attosecond. Clearly this allows PDM to measure extremely small time differentials. On the other end of the scale, the maximum delta value is 65535, or FFFF in hexadecimal. If the maximum scale value of 255 is used, the time differential represented is 65535*2**255, which is over 3*10**55 years, essentially, forever. So there appears to be no real limitation to the time differential that can be represented. B.2.2 Loss of precision induced by timer value truncation As PDM specifies the DELTATLR and DELTATLS values as 16-bit unsigned integers, any time the precision is greater than those 16 bits, there will be truncation of the trailing bits, with an accompanying loss of precision in the value. Any time differential value smaller than 65536 asec can be stored exactly in DELTATLR or DELTATLS, because the representation of this value requires at most 16 bits. Since the time differential values in PDM are measured in attoseconds, the range of values that would be truncated to the same encoded value is 2**(Scale)-1 asec. For example, the smallest time differential that would be truncated to fit into a delta field is 1 0000 0000 0000 0000 = 65536 asec This value would be encoded as a delta value of 8000 (hexadecimal) with a scaling factor of 1. The value 1 0000 0000 0000 0001 = 65537 asec would also be encoded as a delta value of 8000 with a scaling factor of 1. This actually is the largest value that would be truncated to that same encoded value. When the scale value is 1, the value range is calculated as 2**1 - 1, or 1 asec, which you can see is the difference between these minimum and maximum values. The scaling factor is defined as the number of low-order bits truncated to reduce the size of the resulting value so it fits into a 16-bit delta field. If, for example, you had to truncate 12 bits, the loss of precision would depend on the bits you truncated. The range of these values would be 0000 0000 0000 = 0 asec Elkins Expires November 10, 2017 [Page 19] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 to 1111 1111 1111 = 4095 asec So the minimum loss of precision would be 0 asec, where the delta value exactly represents the time differential, and the maximum loss of precision would be 4095 asec. As stated above, the scaling factor of 12 means the maximum loss of precision is 2**12-1 asec, or 4095 asec. Compare this loss of precision to the actual time differential. The range of actual time differential values that would incur this loss of precision is from 1000 0000 0000 0000 0000 0000 0000 = 2**27 asec or 134217728 asec to 1111 1111 1111 1111 1111 1111 1111 = 2**28-1 asec or 268435455 asec Granted, these are small values, but the point is, any value between these two values will have a maximum loss of precision of 4095 asec, or about 0.00305% for the first value, as encoded, and at most 0.001526% for the second. These maximum-loss percentages are consistent for all scaling values. Appendix C: Sample Packet Flows C.1 PDM Flow - Simple Client Server Following is a sample simple flow for the PDM with one packet sent from Host A and one packet received by Host B. The PDM does not require time synchronization between Host A and Host B. The calculations to derive meaningful metrics for network diagnostics are shown below each packet sent or received. Elkins Expires November 10, 2017 [Page 20] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 C.1.1 Step 1 Packet 1 is sent from Host A to Host B. The time for Host A is set initially to 10:00AM. The time and packet sequence number are saved by the sender internally. The packet sequence number and delta times are sent in the packet. Packet 1 +----------+ +----------+ | | | | | Host | ----------> | Host | | A | | B | | | | | +----------+ +----------+ PDM Contents: PSNTP : Packet Sequence Number This Packet: 25 PSNLR : Packet Sequence Number Last Received: - DELTATLR : Delta Time Last Received: - SCALEDTLR: Scale of Delta Time Last Received: 0 DELTATLS : Delta Time Last Sent: - SCALEDTLS: Scale of Delta Time Last Sent: 0 Internally, within the sender, Host A, it must keep: Packet Sequence Number of the last packet sent: 25 Time the last packet was sent: 10:00:00 Note, the initial PSNTP from Host A starts at a random number. In this case, 25. The time in these examples is shown in seconds for the sake of simplicity. C.1.2 Step 2 Packet 1 is received at Host B. Its time is set to one hour later than Host A. In this case, 11:00AM Internally, within the receiver, Host B, it must note: Packet Sequence Number of the last packet received: 25 Time the last packet was received : 11:00:03 Note, this timestamp is in Host B time. It has nothing whatsoever to do with Host A time. The Packet Sequence Number of the last packet Elkins Expires November 10, 2017 [Page 21] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 received will become PSNLR which will be sent out in the packet sent by Host B in the next step. The time last received will be used to calculate the DELTALR value to be sent out in the packet sent by Host B in the next step. C.1.3 Step 3 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 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 knows when it received the previous packet, it can do the following calculation: Sending time : packet 2 - receive time : packet 1 The result of this calculation is called: Delta Time Last Received (DELTATLR) 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 packet. Assume that within Host B is the following: Packet Sequence Number of the last packet received: 25 Time the last packet was received: 11:00:03 Packet Sequence Number of this packet: 12 Time this packet is being sent: 11:00:07 Now a delta value to be sent out in the packet can be calculated. DELTATLR becomes: 4 seconds = 11:00:07 - 11:00:03 = 3782DACE9D900000 asec This is the derived metric: Server Delay. The time and scaling factor must be converted; in this case, the time differential is DE0B, and the scaling factor is 2E, or 46 in decimal. Then, these values, along with the packet sequence numbers will be sent to Host A as follows: Elkins Expires November 10, 2017 [Page 22] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 Packet 2 +----------+ +----------+ | | | | | Host | <---------- | Host | | A | | B | | | | | +----------+ +----------+ PDM Contents: PSNTP : Packet Sequence Number This Packet: 12 PSNLR : Packet Sequence Number Last Received: 25 DELTATLR : Delta Time Last Received: DE0B (4 seconds) SCALEDTLR: Scale of Delta Time Last Received: 2E (46 decimal) DELTATLS : Delta Time Last Sent: - SCALEDTLS: Scale of Delta Time Last Sent: 0 The metric left to be calculated is the Round-Trip Delay. This will be calculated by Host A when it receives Packet 2. C.1.4 Step 4 Packet 2 is received at Host A. Remember, its time is set to one hour earlier than Host B. Internally, it must note: Packet Sequence Number of the last packet received: 12 Time the last packet was received : 10:00:12 Note, this timestamp is in Host A time. It has nothing whatsoever to do with Host B time. So, now, Host A can calculate total end-to-end time. That is: 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 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 delay combined). This time may also be called total Overall Round- Trip Time (RTT) which includes Network RTT and Host Response Time. This derived metric we will call Delta Time Last Sent (DELTATLS) Round trip delay can now be calculated. The formula is: Round trip delay = (Delta Time Last Sent - Delta Time Last Received) Elkins Expires November 10, 2017 [Page 23] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 Or: Round trip delay = 12 - 4 or 8 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. Note: this simple example assumes one send and one receive. That is done only for purposes of explaining the function of the PDM. In cases where there are multiple packets returned, one would take the time in the last packet in the sequence. The calculations of such timings and intelligent processing is the function of post-processing of the data. C.1.5 Step 5 Packet 3 is sent from Host A to Host B. +----------+ +----------+ | | | | | Host | ----------> | Host | | A | | B | | | | | +----------+ +----------+ PDM Contents: PSNTP : Packet Sequence Number This Packet: 26 PSNLR : Packet Sequence Number Last Received: 12 DELTATLR : Delta Time Last Received: 0 SCALEDTLS: Scale of Delta Time Last Received 0 DELTATLS : Delta Time Last Sent: A688 (scaled value) SCALEDTLR: Scale of Delta Time Last Received: 30 (48 decimal) To calculate Two-Way Delay, any packet capture device may look at these packets and do what is necessary. C.2 Other Flows What has been discussed so far is a simple flow with one packet sent and one returned. Let's look at how PDM may be useful in other types of flows. C.2.1 PDM Flow - One Way Traffic The flow on a particular session may not be a send-receive paradigm. Let us consider some other situations. In the case of a one-way flow, one might see the following: Elkins Expires November 10, 2017 [Page 24] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 Note: The time is expressed in generic units for simplicity. That is, these values do not represent a number of attoseconds, microseconds or any other real units of time. Packet Sender PSN PSN Delta Time Delta Time This Packet Last Recvd Last Recvd Last Sent ===================================================================== 1 Server 1 0 0 0 2 Server 2 0 0 5 3 Server 3 0 0 12 4 Server 4 0 0 20 What does this mean and how is it useful? In a one-way flow, only the Delta Time Last Sent will be seen as used. Recall, Delta Time Last Sent is the difference between the send of one packet from a device and the next. This is a measure of throughput for the sender - according to the sender's point of view. That is, it is a measure of how fast is the application itself (with stack time included) able to send packets. How might this be useful? If one is having a performance issue at the client and sees that packet 2, for example, is sent after 5 time units from the server but takes 10 times that long to arrive at the destination, then one may safely conclude that there are delays in the path other than at the server which may be causing the delivery issue of that packet. Such delays may include the network links, middle-boxes, etc. 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 packets (for example, a TCP window size worth) is sent, then the sender waits for acknowledgment. This type of flow would actually fall into the "multiple-send" traffic model. Elkins Expires November 10, 2017 [Page 25] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 C.2.2 PDM Flow - Multiple Send Traffic 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 This Packet Last Recvd Last Recvd Last Sent ===================================================================== 1 Server 1 0 0 0 2 Server 2 0 0 5 3 Client 1 2 20 0 4 Server 3 1 10 15 How might this be used? Notice that in packet 3, the client has a value of Delta Time Last received of 20. Recall that Delta Time Last Received is the Send time of packet 3 - receive time of packet 2. So, what does one know now? In this case, Delta Time Last Received is the processing time for the Client to send the next packet. How to interpret this depends on what is actually being sent. Remember, PDM is not being used in isolation, but to supplement the fields found in other headers. Let's take some examples: 1. Client is sending a standalone TCP ACK. One would find this by looking at the payload length in the IPv6 header and the TCP Acknowledgement field in the TCP header. So, in this case, the client is taking 20 units to send back the ACK. This may or may not be interesting. 2. Client is sending data with the packet. Again, one would find this by looking at the payload length in the IPv6 header and the TCP Acknowledgement field in the TCP header. So, in this case, the client is taking 20 units to send back data. This may represent "User Think Time". Again, this may or may not be interesting, in isolation. But, if there is a performance problem receiving data at the server, then taken in conjunction with RTT or other packet timing information, this information may be quite interesting. Of course, one also needs to look at the PSN Last Received field to make sure of the interpretation of this data. That is, to make sure that the Delta Last Received corresponds to the packet of interest. The benefits of PDM are that such information is now available in a uniform manner for all applications and all protocols without Elkins Expires November 10, 2017 [Page 26] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 extensive changes required to applications. C.2.3 PDM Flow - Multiple Send with Errors Let us now look at a case of how PDM may be able to help in a case of TCP retransmission and add to the information that is sent in the TCP header. Assume that three packets are sent with each send from the server. From the server, this is what is seen. Pkt Sender PSN PSN Delta Time Delta Time TCP Data This Pkt LastRecvd LastRecvd LastSent SEQ Bytes ===================================================================== 1 Server 1 0 0 0 123 100 2 Server 2 0 0 5 223 100 3 Server 3 0 0 5 333 100 The client, however, does not receive all the packets. From the client, this is what is seen for the packets sent from the server. Pkt Sender PSN PSN Delta Time Delta Time TCP Data This Pkt LastRecvd LastRecvd LastSent SEQ Bytes ===================================================================== 1 Server 1 0 0 0 123 100 2 Server 3 0 0 5 333 100 Let's assume that the server now retransmits the packet. (Obviously, a duplicate acknowledgment sequence for fast retransmit or a retransmit timeout would occur. To illustrate the point, these packets are being left out.) So, then if a TCP retransmission is done, then from the client, this is what is seen for the packets sent from the server. Pkt Sender PSN PSN Delta Time Delta Time TCP Data This Pkt LastRecvd LastRecvd LastSent SEQ Bytes ===================================================================== 1 Server 4 0 0 30 223 100 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. The Delta Last Sent is 30 - the time between sending the packet with PSN of 3 and this current packet. Elkins Expires November 10, 2017 [Page 27] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 Let's say that packet 4 is lost again. Then, after some amount of time (RTO) then the packet with TCP sequence number of 223 is resent. From the client, this is what is seen for the packets sent from the server. Pkt Sender PSN PSN Delta Time Delta Time TCP Data This Pkt LastRecvd LastRecvd LastSent SEQ Bytes ===================================================================== 1 Server 5 0 0 60 223 100 If now, this packet arrives at the destination, one has a very good idea that packets exist which are being sent from the server as retransmissions and not arriving at the client. This is because the PSN of the resent packet from the server is 5 rather than 4. If we had used TCP sequence number alone, we would never have seen this situation. The TCP sequence number in all situations is 223. This situation would be experienced by the user of the application (the human being actually sitting somewhere) as a "hangs" or long delay between packets. On large networks, to diagnose problems such as these where packets are lost somewhere on the network, one has to take multiple traces to find out exactly where. 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 the client received it. If the client did not receive it, then we start tracking back to trace points at the router right after the server and the router right before the client. Did they get these packets which the server has sent? This is a time consuming activity. With PDM, we can speed up the diagnostic time because we may be able to use only the trace taken at the client to see what the server is sending. Appendix D: Potential Overhead Considerations One might wonder as to the potential overhead of PDM. First, PDM is entirely optional. That is, a site may choose to implement PDM or not as they wish. If they are happy with the costs of PDM vs. the benefits, then the choice should be theirs. Below is a table outlining the potential overhead in terms of additional time to deliver the response to the end user for various assumed RTTs. Elkins Expires November 10, 2017 [Page 28] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 Bytes RTT Bytes Bytes New Overhead in Packet Per Millisec in PDM RTT ===================================================================== 1000 1000 milli 1 16 1016.000 16.000 milli 1000 100 milli 10 16 101.600 1.600 milli 1000 10 milli 100 16 10.160 .160 milli 1000 1 milli 1000 16 1.016 .016 milli Below are some examples of actual RTTs for packets traversing large enterprise networks. The first example is for packets going to multiple business partners. Bytes RTT Bytes Bytes New Overhead in Packet Per Millisec in PDM RTT ===================================================================== 1000 17 milli 58 16 17.360 .360 milli The second example is for packets at a large enterprise customer within a data center. Notice that the scale is now in microseconds rather than milliseconds. Bytes RTT Bytes Bytes New Overhead in Packet Per Microsec in PDM RTT ===================================================================== 1000 20 micro 50 16 20.320 .320 micro As with other diagnostic tools, such as packet traces, a certain amount of processing time will be required to create and process PDM. Since PDM is lightweight (has only a few variables), we expect the processing time to be minimal. Acknowledgments The authors would like to thank Keven Haining, Al Morton, Brian Trammel, David Boyes, Bill Jouris, Richard Scheffenegger, and Rick Troth for their comments and assistance. We would also like to thank Tero Kivinen and Jouni Korhonen for their detailed and perceptive reviews. Elkins Expires November 10, 2017 [Page 29] INTERNET DRAFT ietf-ippm-6man-pdm-option-10 May 9, 2017 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 Robert M. Hamilton Chemical Abstracts Service A Division of the American Chemical Society 2540 Olentangy River Road Columbus, Ohio 43202 United States Phone: +1 614 447 3600 x2517 Email: rhamilton@cas.org http://www.cas.org 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 http://www.bcbsm.com Elkins Expires November 10, 2017 [Page 30]