Network Working Group B. Weis Internet-Draft Cisco Systems Intended status: Standards Track U. Mangla Expires: April 28, 2015 N. Maheshwari Juniper Networks Inc. T. Karl Deutsche Telekom October 25, 2014 IP Delivery Delay Detection Protocol draft-weis-delay-detection-01 Abstract This memo describes a one-way measurement of IP packet end to end delay. Delay detection is enabled by a sender of an IP Internet Protocol datagram placing a timestamp in the packet declaring the time at which it was sent. The receiver of the datagram can then judge how recently it was sent and choose a policy action, which could include discarding packets deemed to be 'too old' (having a timestamp too far into the past) or 'too new' (having a timestamp that is too far into the future). 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 April 28, 2015. Copyright Notice Copyright (c) 2014 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 Weis, et al. Expires April 28, 2015 [Page 1] Internet-Draft IP-D3P October 2014 (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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. IP Delivery Delay Detection Protocol (IP-D3P) . . . . . . . . 4 2.1. IP-D3P Header . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Outbound Packet Processing . . . . . . . . . . . . . . . . 6 2.3. Inbound Packet Processing . . . . . . . . . . . . . . . . 6 3. IP-D3P and IPsec . . . . . . . . . . . . . . . . . . . . . . . 8 4. Policy Distribution using Group Domain of Interpretation . . . 12 4.1. Detecting Experimental Support of IP-D3P . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Weis, et al. Expires April 28, 2015 [Page 2] Internet-Draft IP-D3P October 2014 1. Introduction IP datagrams can be subject to a delivery delay attack, where a host or gateway receives datagrams that are not fresh. A fresh datagram is defined as one "Recently generated; not replayed from some earlier interaction of the protocol." [RFC4949]. Even when IP datagrams are validated legitimate using an integrity transform and are protected from replay, delivered datagrams may have been delayed for an unbounded period of time. Delivery delay detection is useful when the value of data included in the IP datagram is time sensitive. Delivery delay protection is even more valuable when replay protection is not available. For example, while the IPsec [RFC4301] transforms IP Encapsulating Security Payload (ESP) [RFC4303] and IP Authentication Header [RFC4302] include replay protection, it must be disabled when multi-sender IPsec security associations are used to protect multicast and group communications. Such Many-to-Many Applications [RFC3170] often require the use of multi-sender security associations, where receivers cannot use the sequence number replay protection method. In such cases, a single counter cannot record responses from multiple senders, and no provision is made for multiple counters in the security association. This memo describes an IP Delivery Delay Detection Protocol using timestamps to declare the age of an IP datagram, enabling receivers to make a judgement whether to accept an IP datagram as "fresh" [RFC4949]. 1.1. Requirements notation 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 [RFC2119]. Weis, et al. Expires April 28, 2015 [Page 3] Internet-Draft IP-D3P October 2014 2. IP Delivery Delay Detection Protocol (IP-D3P) An IP-D3P datagram consists of a header and an IP payload. The IP- D3P header includes a timestamp, which receivers of the packet use to determine whether or not the packet has been recently generated. Receivers compare the timestamp delivered in the IP packet to their local time and make a determination as to whether it should be accepted. Freshness does not provide replay protection, as it makes no explicit judgement as to whether a receiver has received a particular packet before. Rather, it allows the receiver to determine whether the packet has been delayed in delivery beyond an acceptable point in time. A typical policy would be to choose a time larger than a reasonable delivery time, which delay indicates a possible packet delay attack. When combined with replay protection, IP-D3P provides the receiver assurance that the packet is not only unique, but also fresh. This memo declares one type payload type, which defines a commonly used timestamp format. Future types may be defined that include timestamps of a different format, or that include additional state related to the timestamp. It is important that both sender and receiver not only specify the time in the same format as enforced by the type, but also interpret the time in the same degree of precision. For example, if the sender added a timestamp with a precision of seconds (e.g, not including a value for parts of seconds) but the receiver compares the timestamp to a local value including parts of seconds, the receiver determination of freshness may be in error. 2.1. IP-D3P Header The IP-D3P header consists of a type, length, and a timestamp field. The header is followed by a datagram, which may be either a full or partial IP datagram depending on the use case. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Header ! Type ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Timestamp ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 1: IP-D3P Header The header fields are defined as follows: Weis, et al. Expires April 28, 2015 [Page 4] Internet-Draft IP-D3P October 2014 o Next Header (1 octet) -- Identifies the type of data in the Datagram following the IP-D3P header. Valid types are described in [PROT-REG]. o Type (1 octet) -- Type of timestamp contained in the header. Valid values are defined in Section 2.1.1. o Length (2 octets) -- Total length of the IP-D3P Header in octets, beginning with the Next Header field and ending with the final octet of the Timestamp field. o Timestamp (variable) -- Timestamp declaring when the packet was originated. 2.1.1. Type This memo defines the following types. A conforming implementation MUST implement POSIX-TIME. Each type indicates a fixed sized timestamp, which is valuable for packet evaluation efficiency. The length of the header can then also be trivially determined based on its Type. o POSIX-TIME. Specifies an 8 octet timestamp. The value in the timestamp field indicates the sender's current time since the POSIX Epoch [POSIX.1] (i..e., time beginning January 1, 1970 not counting leap seconds). The timestamp field is shown in Figure 2 and is constructed as follows. The 32 least significant bits of the Seconds field from the POSIX.1 timeval structure is placed in the Seconds field; the Microseconds field from the POSIX.1 timeval structure is placed into the Fraction field. Although this format is similar to the NTP Timestamp field as defined by NTP [RFC5905], this construction differs from the NTP usage of this field and there is no claimed interoperability between the IP-D3P and NTP timestamps. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Microseconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: POSIX-TIME Timestamp Format Weis, et al. Expires April 28, 2015 [Page 5] Internet-Draft IP-D3P October 2014 2.2. Outbound Packet Processing An IP-D3P header is added to the packet as described in Figure 1. The sender inserts the type defined by policy into the Type field and places the current time value in the Timestamp field as specified by the Type. When the Type is POSIX-TIME, the current value from the system clock is translated into POSIX time and placed into the header as defined in Section 2.1.1. When IP-D3P is added to an IP packet, the IP-D3P Next Header field identifies the Protocol Id representing the next header (e.g., TCP). When IP-D3P is used with a IP-IP encapsulation (e.g., IPsec Tunnel Mode), the IP-D3P Next Header field represents the type of datagram following (e.g., 4 for IPv4, 41 for IPv6). 2.3. Inbound Packet Processing A receiver first validates that the Type value in the IP-D3P header matches the expected type, as according to policy. It then extracts the timestamp and compares it to a sliding window maintained by the receiver that is based on the Type. A timestamp found within the sliding window is accepted, and the packet is treated as a fresh packet (e.g., is processed further). If the timestamp is outside of the receiver's window, the packet is discarded. Figure 3 shows the sliding window used by D3P. A receiver chooses a window size of W, which lies between Ws and We centered around the current time of the receiver (Tr). When a packet is received with a Timestamp Ts that lies below Ws, it is rejected as being too old. If Ts lies in between Ws and We it is accepted as a fresh packet. If Ts is in advance of We it is rejected as an invalid time. However, the reason for rejection (being too old or invalid) MUST NOT be discernible to any entity other than the receiver who rejected the packet. Reject | Accept | Reject (Replay) | | (Invalid) --------------------------------> t Ws | We | Tr Figure 3: D3P Sliding Window Special care must be taken when values of Ts are expected to approach the point where they wrap (e.g., for POSIX-TIME the first time will be in the year 2038). Implementations may wish to represent Tr as the same size value represented within Ts. When the maximum value of Weis, et al. Expires April 28, 2015 [Page 6] Internet-Draft IP-D3P October 2014 Tr fits within W, the next value is considered zero, and the window increments in the usual way. For example, if the size of W is 5 seconds and Tr is exactly 2^32-1, then Ws would be 2^32-3 and We would be 1. Decapsulation happens as follows. When IP-D3P follows an IP header (e.g., IPsec Transport Mode) the Next Header value in the IP-D3P header is placed in the IP header in place of TBD-1. The IP-D3P header is then removed from the packet. New Total Length and checksum fields of the IP header are also restored by the receiver. In the case of an IP-IP encapsulated packet, the IP-D3P header is simply discarded and processing continues on the encapsulated IP packet. If an IP-D3P header is expected in an IP packet but is missing, then the IP packet MUST be discarded, as the delay protection policy cannot be checked. If an IP-D3P header is received when it was not expected, then the receiver may choose to further process or discard the packet. Section 3 describes specific requirements when IP-D3P is used with IPsec. Weis, et al. Expires April 28, 2015 [Page 7] Internet-Draft IP-D3P October 2014 3. IP-D3P and IPsec When IP-D3P is defined as part of the policy, it is applied before ESP or AH processing. Another instance of this approach is IPcomp [RFC3173]. Using IP-D3P with IPsec is particularly useful to protect group communications when the use of single-sender Security Associations (SAs) is not possible, and thus IPsec replay protection is not available (Section 2.2 of [RFC4303]). This has been a particular problem when applying IPsec to routing protocols using multicast communications (e.g., OSPF [RFC4552] and PIM [RFC4601] ), where maintaining an IPsec SA for each sender in not always feasible. Additionally, for operational reasons IPsec SAs and keying material are often manually configured for these routing protocols, in which case the use of IPsec replay protection in not possible. The use of IP-D3P does not replace this missing replay protection, but can effectively bound the lifetime of a replayed packet. When IP-D3P is applied as part of IPsec transport mode encapsulation, the IP-D3P encapsulation is added as the first Protocol following the IP header as shown in Figure 4 and Figure 5. Several IP header fields need to be adjusted when adding the IP-D3P header: Total Length is adjusted to the original length of the payload, the Protocol field (IPv4 header) or Next Header field (IPv6) is set to TBD-1 identifying IP-D3P as the next protocol, and the header checksum is adjusted. BEFORE APPLYING IP-D3P ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING IP-D3P ------------------------------------- IPv4 |orig IP hdr | | | | |(any options)| IP-D3P | TCP | Data | ------------------------------------- AFTER APPLYING ESP ---------------------------------------------------- IPv4 | orig IP hdr | | | | | ESP | ESP| |(any options)| ESP | IP-D3P |TCP|Data|Trailer| ICV| ---------------------------------------------------- |<--------- encryption -->| |<------------- integrity ----->| Weis, et al. Expires April 28, 2015 [Page 8] Internet-Draft IP-D3P October 2014 Figure 4: IPv4 Transport Mode Encapsulation BEFORE APPLYING D3P --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING D3P ----------------------------------------------- IPv6 | | ext hdrs | | | | | orig IP hdr | if present|IP-D3P| TCP | Data | ----------------------------------------------- AFTER APPLYING ESP -------------------------------------------------- IPv6 | orig |orig ext| | | | | ESP | ESP| |IP hdr| hdrs |ESP|IP-D3P|TCP|Data|Trailer| ICV| -------------------------------------------------- |<------ encryption --->| |<---------integrity ------>| Figure 5: IPv6 Transport Mode Encapsulation When IP-D3P is applied as part of IPsec tunnel mode encapsulation, the IP-D3P encapsulation is added immediately after the outer IP header, such that the inner IP header is fully encapsulated. This is shown in Figure 6 and Figure 7. The Protocol field in the outer IPv4 header or Next Header field in the outer IPv6 header is set to TBD-1, indicating that an IP-D3P datagram follows. Weis, et al. Expires April 28, 2015 [Page 9] Internet-Draft IP-D3P October 2014 BEFORE APPLYING D3P ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING D3P ------------------------------------- IPv4 | |orig IP hdr | | | | IP-D3P |(any options)| TCP | Data | ------------------------------------- AFTER APPLYING ESP -------------------------------------------------------------- IPv4 | new IP hdr | | |orig IP hdr | | | ESP | ESP| |(any options)|ESP|IP-D3P|(any options)|TCP|Data|Trailer| ICV| -------------------------------------------------------------- |<--------- encryption -------------->| |<------------integrity ----------------->| Figure 6: IPv4 Tunnel Mode Encapsulation BEFORE APPLYING D3P --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING D3P ----------------------------------------------- IPv6 | | | ext hdrs | | | |IP-D3P| orig IP hdr | if present| TCP | Data | ----------------------------------------------- AFTER APPLYING ESP ----------------------------------------------------------------- IPv6 | new |new ext| | | orig |orig ext| | | ESP | ESP| |IP hdr| hdrs |ESP|IP-D3P|IP hdr| hdrs |TCP|Data|Trailer| ICV| ----------------------------------------------------------------- |<--------- encryption ---------------->| |<----------- integrity ------------------->| Figure 7: IPv6 Tunnel Mode Encapsulation When IPsec SA policy specifies IPsec Transport Mode, the following requirements apply. If the IPsec SA policy specifies the use of IP- Weis, et al. Expires April 28, 2015 [Page 10] Internet-Draft IP-D3P October 2014 D3P, but the IP-D3P header is missing, then the IP packet MUST be discarded as the delay protection policy cannot be checked. If the IPsec SA policy does not specify the use of IP-D3P, but the packet includes the IP-D3P header, then it SHOULD forward the packet in case an entity following IPsec decapsulation is using IP-D3P. When IPsec SA policy specifies IPsec Tunnel Mode, the following requirements apply. If the IPsec SA policy specifies the use of IP- D3P, but the IP-D3P header is missing, then the IP packet MUST be discarded as the delay protection policy cannot be checked. If the IPsec SA policy does not specify the use of IP-D3P, but the packet includes the IP-D3P header, the receiver would understand that the IPsec sender must have added it in the last stage of encapsulation (as shown in Figure 6 and Figure 7). Since IP-D3P is not part of the IPsec SA policy, the receiver cannot process the IP-D3P packet and MUST discard it. Weis, et al. Expires April 28, 2015 [Page 11] Internet-Draft IP-D3P October 2014 4. Policy Distribution using Group Domain of Interpretation The Group Domain of Interpretation (GDOI) [RFC6407] is a group key management protocol used to distribute group policy and keying material to a set of Group Members (GMs). When groups using GDOI key management services require the use of IP-D3P, GDOI distributes this policy in a Group Associated Policy (GAP) payload using the D3P-TYPE attribute. This attribute indicates the use of IP-D3P for all SA TEKs distributed within the SA payload, and defines the Type of timestamp that is to be placed into datagrams matching those SA TEKs. Value for the D3P-TYPE attribute are taken from the IP-D3P Type Registry. When the GDOI KS policy sends a D3P-TYPE attribute, it MUST also define the size of the time window (i.e., W described in Section 2.3). The window size MUST be a value greater than zero. The GDOI KS distributes the value of W using the GAP payload D3P- WINDOWSIZE attribute. The value of the attribute is in the units defined by the Type. For the POSIX-TIME attribute the value is in milliseconds. 4.1. Detecting Experimental Support of IP-D3P For testing purposes, implementations of this draft memo will need to use an experimental protocol number to represent IP-D3P. IANA has reserved two values for testing purposes such as this [PROT-REG]. Implementations of this draft memo will use IP protocol number 253. To denote the use of the experimental protocol number, in the IKE Phase 1 protocol preceding a GDOI registration, the GDOI KS will include a vendor ID payload containing the hash of the name of the Internet-Draft assigning the use of this value for testing purposes: draft-weis-delay-detection-01. The exact content in hex for the payload is 110088397f51fe9669b9630476358bec Weis, et al. Expires April 28, 2015 [Page 12] Internet-Draft IP-D3P October 2014 5. Security Considerations IP-D3P provides an indication of freshness an IP packet rather than an absolute detection of all replays. In networks where active attackers are anticipated, packets including an IP-D3P header SHOULD be protected by an IPsec transform. IPsec integrity protection defends against active man in the middle attackers changing the timestamp, and making it appear to be stale or invalid. The Type defined in this memo uses the system clock. In many cases, the system clock is set from an external protocol (e.g., NTP [RFC5905]), and indeed this will maximize the likelihood that the system clocks of both sender and receiver are synchronized. However, care should be taken that external protocol is resistant to a man in the middle attack. For example, NTP packets could be distributed within an independent well-protected network believed not available to active man in the middle attackers, or the NTP Message Digest could be used to provide integrity protection. Attackers wishing to replay integrity protected packets containing a timestamp would need to collect ancient packets (e.g., for POSIX-TIME those created about 138 years prior to the current time). This is considered to be a low risk. Weis, et al. Expires April 28, 2015 [Page 13] Internet-Draft IP-D3P October 2014 6. IANA Considerations A new IP Protocol is defined for IP-D3P (value TBD-1). A new IP-D3P Type registry is created. Values for this attribute are shown in the following table. The terms Reserved and Unassigned are to be applied as defined in [RFC5226]. Value Type ------ ---- 0 Reserved 1 POSIX-TIME 2-128 Unassigned 129-255 Private Use The following additions are made to the GDOI Payloads [GDOI-REG] registry. Two new attributes are added to the GAP Payload Policy Attributes registry. o Attribute type D3P-TYPE is a Basic attribute and takes the value of TBD-2. Valid values come from the IP-D3P Type registry. o Attribute type D3P-WINDOWSIZE is a Variable attribute and takes the value of TBD-3. There are no described set of valid values. Weis, et al. Expires April 28, 2015 [Page 14] Internet-Draft IP-D3P October 2014 7. Acknowledgements Some diagrams were adapted from similar diagrams in [RFC4303]. Weis, et al. Expires April 28, 2015 [Page 15] Internet-Draft IP-D3P October 2014 8. References 8.1. Normative References [POSIX.1] IEEE Std 1003.1, "Standard for Information Technology-- Portable Operating System Interface (POSIX) Base Specifications, Issue 7", 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 8.2. Informative References [GDOI-REG] Internet Assigned Numbers Authority, "Group Domain of Interpretation (GDOI) Payload Type Values", IANA Registry, . [PROT-REG] Internet Assigned Numbers Authority, "Protocol Numbers", IANA Registry, . [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: Challenges and Solutions", RFC 3170, September 2001. [RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, Weis, et al. Expires April 28, 2015 [Page 16] Internet-Draft IP-D3P October 2014 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, October 2011. Weis, et al. Expires April 28, 2015 [Page 17] Internet-Draft IP-D3P October 2014 Authors' Addresses Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA Phone: +1-408-526-4796 Email: bew@cisco.com Umesh Mangla Juniper Networks Inc. 1133 Innovation Way Sunnyvale, California 94089 USA Phone: +1-408-936-1022 Email: umangla@juniper.net Nilesh Maheshwari Juniper Networks Inc. 1133 Innovation Way Sunnyvale, California 94089 USA Phone: +1-408-936-7570 Email: nileshm@juniper.net Thomas Karl Deutsche Telekom Landgrabenweg 151 Bonn, 53227 Germany Phone: +49 228 18138122 Email: thomas.karl@telekom.de Weis, et al. Expires April 28, 2015 [Page 18]