Internet DRAFT - draft-weis-delay-detection
draft-weis-delay-detection
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[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,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References
[GDOI-REG]
Internet Assigned Numbers Authority, "Group Domain of
Interpretation (GDOI) Payload Type Values", IANA Registry,
November 2011, <http://www.iana.org/assignments/gdoi-
payloads/gdoi-payloads.xml>.
[RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications:
Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170,
September 2001, <https://www.rfc-editor.org/info/rfc3170>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
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,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
<https://www.rfc-editor.org/info/rfc4552>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[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,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
October 2011, <https://www.rfc-editor.org/info/rfc6407>.
[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, <https://www.rfc-editor.org/info/rfc7761>.
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]
