Network Working Group B. Weis Internet-Draft Cisco Systems Intended status: Standards Track U. Mangla Expires: September 6, 2018 Juniper Networks Inc. T. Karl Deutsche Telekom N. Maheshwari March 5, 2018 IPsec Delivery Delay Detection draft-weis-delay-detection-04 Abstract This memo describes a one-way measurement of an IPsec packet edge-to- edge delay. Delay detection is enabled by a sender of an IPsec packet that includes a timestamp 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). This provides a freshness policy check, which can be valuable irrespective of whether the IPsec policy also includes replay protection. 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 https://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 September 6, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Weis, et al. Expires September 6, 2018 [Page 1] Internet-Draft IP-D3P March 2018 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. IPsec Delivery Delay Detection Protocol (IP-D3P) . . . . . . 3 2.1. Outbound Packet Processing . . . . . . . . . . . . . . . 3 2.2. Inbound Packet Processing . . . . . . . . . . . . . . . . 7 3. Key Management Considerations . . . . . . . . . . . . . . . . 8 3.1. GDOI . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction IP datagrams, including those protected by an IP Encapsulating Security Payload (ESP) [RFC4303] or IP Authentication Header [RFC4302], can be delayed in transit. In some use cases a delayed packet is considered invalid, or "not fresh". A fresh datagram is defined as one "Recently generated; not replayed from some earlier interaction of the protocol." [RFC4949]. An intentional delay of a packet can be considered an attack, for example if the protected datagrams contain time sensitive data. When delay detection is combined with IPsec replay protection, packets are guaranteed to be fully fresh (i.e, both recently generated and not replayed). However, some applications of IPsec cannot enable replay protection. For example, Many-to-Many Applications [RFC3170] often require the use of multi-sender security associations, where receivers cannot enable IPsec replay protection. This is because a single counter cannot record responses from multiple senders, and no provision is made for multiple counters in the security association. Many-to-Many Applications can include Weis, et al. Expires September 6, 2018 [Page 2] Internet-Draft IP-D3P March 2018 routing protocols (e.g., OSPF [RFC4552] and PIM [RFC7761]) deployed between a set of routers. These applications can benefit from the partial freshness property of "recently generated". This is particularly useful when the application traffic provides its own replay protection. This memo describes an IPsec Delivery Delay Detection Protocol (D3P) 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]. An In-band OAM transport header [I-D.weis-ippm-ioam-gre] is used to encode the timestamp. This document defines semantics regarding the use of the timestamp to determine freshness. 1.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. IPsec Delivery Delay Detection Protocol (IP-D3P) A D3P datagram consists of an IP packet to which an "in-situ" Operations, Administration, and Maintenance (OAM) header containing a timestamp is added, and then is protected by an IPsec [RFC4301] security protocol. Receivers of the packet use the timestamp 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. D3P makes no explicit judgement as to whether a receiver has previously received a copy of this particular packet. 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. The value in the timestamp field indicates the sender's current time. When the timestamp type is defined as POSIX-TIME, this is the time since the POSIX Epoch [POSIX.1] (i..e., time beginning January 1, 1970 not counting leap seconds). 2.1. Outbound Packet Processing An "in-situ" OAM header is added to the beginning of the packet. The optional GRE checksum MUST be omitted (and is not required because the IPsec integrity check will ensure that the packet has not been Weis, et al. Expires September 6, 2018 [Page 3] Internet-Draft IP-D3P March 2018 altered). The GRE Protocol Type MUST be the value indicating "In- situ OAM (IOAM)" as defined in [I-D.weis-ippm-ioam-gre]. The IOAM- Type in the IOAM header MUST be the value indicating "IOAM E2E Option Type" (3) as defined in Section 7.2 of [I-D.ietf-ippm-ioam-data]. When the timestamp type is defined as POSIX-TIME, the IOAM-E2E-Type option header MUST indicate the presence of a POSIX timestamp. The sender inserts the current time value from the system clock into the Timestamp field 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 Subseconds field. When IPsec transport mode encapsulation is used with D3P, the GRE and IOAM encapsulations are added immediately following the IP header. An example of a protected TCP segment is shown in Figure 1 and Figure 2. The least significant octet in the IOAM protocol header "Next Protocol" field is set to the IP Protocol value of TCP (0x06), preceded by an octet of 0x00 to indicate it is an IP Protocol type. Several IP header fields need to be adjusted when adding the D3P encapsulations: Total Length is adjusted to the length of the entire encapsulated IP datagram. The Protocol field (IPv4 header) or Next Header field (IPv6) is set to 47 identifying GRE as the next protocol, and the header checksum is adjusted. Finally, the IPsec outbound packet processing is performed. BEFORE APPLYING D3P ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING IOAM ----------------------------------------- IPv4 |orig IP hdr | | | | | |(any options)| GRE | IOAM | TCP | Data | ----------------------------------------- AFTER APPLYING ESP ---------------------------------------------------- IPv4 | orig IP hdr | | | | | | ESP | ESP| |(any options)| ESP |GRE|IOAM|TCP|Data|Trailer| ICV| ---------------------------------------------------- |<--------- encryption -->| |<------------- integrity ----->| Figure 1: IPv4 Transport Mode Encapsulation Weis, et al. Expires September 6, 2018 [Page 4] Internet-Draft IP-D3P March 2018 BEFORE APPLYING D3P --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING D3P ------------------------------------------------- IPv6 | | ext hdrs | | | | | | orig IP hdr | if present|GRE|IOAM| TCP | Data | ------------------------------------------------- AFTER APPLYING ESP ---------------------------------------------------- IPv6 | orig |orig ext| | | | | | ESP | ESP| |IP hdr| hdrs |ESP|GRE|IOAM|TCP|Data|Trailer| ICV| ---------------------------------------------------- |<------ encryption ----->| |<---------integrity -------->| Figure 2: IPv6 Transport Mode Encapsulation When IPsec tunnel mode encapsulation is used with D3P, the GRE and IOAM encapsulations are added immediately after the outer IP header, such that the original IP datagram is fully encapsulated. An example showing tunnel mode encapsulation of a TCP segment is shown in Figure 3 and Figure 4. The IOAM protocol header "Next Protocol" field is set to the Ethertype representing IPv4 (0x0800) or IPv6 (0x86DD). The Protocol field in the outer IPv4 header or Next Header field in the outer IPv6 header is set to 47 identifying GRE as the next protocol. Finally, the IPsec outbound packet processing is performed. Weis, et al. Expires September 6, 2018 [Page 5] Internet-Draft IP-D3P March 2018 BEFORE APPLYING D3P ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING D3P ----------------------------------------- IPv4 | | |orig IP hdr | | | | GRE | IOAM |(any options)| TCP | Data | ----------------------------------------- AFTER APPLYING ESP ----------------------------------------------------------- IPv4 | new IP hdr | | | |orig IP hdr | | |ESP|ESP| |(any options)|ESP|GRE|IOAM|(any options)|TCP|Data|Tr.|ICV| ----------------------------------------------------------- |<--------- encryption ------------>| |<------------integrity --------------->| Figure 3: IPv4 Tunnel Mode Encapsulation BEFORE APPLYING D3P --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING D3P ------------------------------------- IPv6 | | | orig | ext hdrs | | | |GRE|IOAM|IP hdr|if present|TCP|Data| ------------------------------------- AFTER APPLYING ESP -------------------------------------------------------------- IPv6 | new |new ext| | | | orig |orig ext| | |ESP|ESP| |IP hdr| hdrs |ESP|GRE|IOAM|IP hdr| hdrs |TCP|Data|Tr.|ICV| -------------------------------------------------------------- |<--------- encryption -------------->| |<----------- integrity ----------------->| Figure 4: IPv6 Tunnel Mode Encapsulation Weis, et al. Expires September 6, 2018 [Page 6] Internet-Draft IP-D3P March 2018 2.2. Inbound Packet Processing A receiver performs IPsec inbound processing as usual (e.g., Section 3.4 of [RFC4303] or Section 3.4 of [RFC4302]). It then validates that the GRE Protocol Type IOAM fields are present as specified in Section 2.1. It then extracts the timestamp and compares it to a sliding window maintained by the receiver. A timestamp found within the sliding window is accepted, and the packet is treated as a fresh packet. If the timestamp is outside of the receiver's window, the packet is discarded. Figure 5 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 5: 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 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. For IPsec tunnel mode encapsulation the GRE and IOAM headers are removed, resulting in the original IP datagram. For IPsec transport mode encapsulation, the Next Protocol field from the IOAM header is placed into the original IP header field, and the GRE header is removed from the packet. New Total Length and checksum fields of the IP header are also restored by the receiver. Weis, et al. Expires September 6, 2018 [Page 7] Internet-Draft IP-D3P March 2018 When IPsec SA policy specifies IPsec Transport Mode, the following requirements apply. If the IPsec SA policy specifies the use of D3P, but the GRE header with Protocol Type indicating "In-situ OAM (IOAM)" 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 D3P, but the packet includes a GRE header with Protocol Type indicating "In-situ OAM (IOAM)" , then it SHOULD forward the packet in case it is intended for another IOAM consumer. When IPsec SA policy specifies IPsec Tunnel Mode, the following requirements apply. If the IPsec SA policy specifies the use of D3P, but the GRE header with Protocol Type indicating "In-situ OAM (IOAM)" 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 D3P, but the packet includes a GRE header with Protocol Type of IOAM_E2E, the receiver would understand that the IPsec sender must have added it in the last stage of encapsulation (as shown in Figure 3 and Figure 4). Since D3P is not part of the IPsec SA policy, the receiver cannot process the D3P packet and MUST discard it. 3. Key Management Considerations 3.1. GDOI 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 D3P, a GDOI Group Controller/ Key Server (GCKS) distributes this policy in a Group Associated Policy (GAP) payload using the D3P-TYPE attribute. This attribute indicates the use of 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 D3P Type Registry. When the policy delivered by the GCKS includes a D3P-TYPE attribute, it MUST also define the size of the time window (i.e., W described in Section 2.2). The window size MUST be a value greater than zero. The GCKS 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. Weis, et al. Expires September 6, 2018 [Page 8] Internet-Draft IP-D3P March 2018 3.2. IKEv2 When D3P is requested for an IPsec SA negotiated by IKEv2, a notify message of type D3P_SUPPORTED is sent to the IKE2 peer, which specifies the D3P type requested. The choice of WINDOWSIZE is a local matter when a device requests for D3P to be used on its inbound SA. 4. Security Considerations D3P provides an indication of how recently an IP packet was emitted by a sender. When replay protection is possible (e.g., single-sender IPsec SAs) IPsec replay protection SHOULD also be enabled. When D3P is used without replay protection a receiver can detect stale packets but packets replayed within its D3P sliding window are not detected. A delay detection protocol needs to be integrity protected. As defined in this memo, D3P MUST be protected by an IPsec transform. IPsec integrity protection defends against active man in the middle attackers changing the timestamp (e.g., making it appear to be stale or invalid). The D3P 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. The D3P sliding window can wrap, thus timestamps from previous generations of the sliding window will be treated as valid packets. Attackers wishing to replay packets containing a repeated timestamp would need to collect ancient packets containing timestamps valid within the current sliding window of the receiver. When the timestamp is of type POSIX-TIME, these packets would have been created about 138 years prior to the current time. The risk of replayed packets containing a repeated but valid timestamp is considered to be a low risk. 5. IANA Considerations The following additions are made to the GDOI Payloads [GDOI-REG] registry. Weis, et al. Expires September 6, 2018 [Page 9] Internet-Draft IP-D3P March 2018 Two new attributes are added to the GAP Payload Policy Attributes registry. Attribute type D3P-TYPE is a Basic attribute and takes the value of TBD-1. Values for this attribute are shown in the following table. The terms Reserved and Unassigned are to be applied as defined in [RFC8126]. Value Type ------ ---- 0 Reserved 1 POSIX-TIME 2-128 Unassigned 129-255 Private Use Attribute type D3P-WINDOWSIZE is a Variable attribute and takes the value of TBD-2. There are no described set of valid values. A new message type is added to the IKEv2 Notify Message Types - Status Types IKEv2 registry: D3P_SUPPORTED. The Notification Data field contains one octet, which is a value from a new registry "IKEv2 Notification D3P Transform IDs". Value Type ----- ---- 0 Reserved 1 POSIX-TIME 2-240 Unassigned 241-255 Private Use 6. Acknowledgements Adrian Farrell suggested the use of "In-situ" OAM (IOAM). Frank Brockners and Shwetha Bhandari assisted in identifying the IOAM data encapsulation and data objects. Some diagrams were adapted from similar diagrams in [RFC4303]. 7. References 7.1. Normative References [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- data-02 (work in progress), March 2018. Weis, et al. Expires September 6, 2018 [Page 10] Internet-Draft IP-D3P March 2018 [I-D.weis-ippm-ioam-gre] Weis, B., Brockners, F., crhill@cisco.com, c., Bhandari, S., Govindan, V., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, P., and M. Spiegel, "GRE Encapsulation for In-situ OAM Data", draft-weis-ippm-ioam-gre-00 (work in progress), March 2018. [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, DOI 10.17487/RFC2119, March 1997, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [GDOI-REG] Internet Assigned Numbers Authority, "Group Domain of Interpretation (GDOI) Payload Type Values", IANA Registry, November 2011, . [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170, September 2001, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . Weis, et al. Expires September 6, 2018 [Page 11] Internet-Draft IP-D3P March 2018 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, DOI 10.17487/RFC6407, October 2011, . [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, . 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 Weis, et al. Expires September 6, 2018 [Page 12] Internet-Draft IP-D3P March 2018 Thomas Karl Deutsche Telekom Landgrabenweg 151 Bonn 53227 Germany Phone: +49 228 18138122 Email: thomas.karl@telekom.de Nilesh Maheshwari Email: nileshm@gmail.com Weis, et al. Expires September 6, 2018 [Page 13]