DOTS R. Moskowitz
Internet-Draft J. Xia
Intended status: Standards Track Huawei
Expires: August 6, 2016 February 3, 2016
DOTS over GRE
draft-moskowitz-dots-gre-00.txt
Abstract
This document describes using a GRE tunnel to deliver DOTS messages
between DOTS agents and compares it to other methods.
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 August 6, 2016.
Copyright Notice
Copyright (c) 2016 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
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.
Moskowitz & Xia Expires August 6, 2016 [Page 1]
Internet-Draft DOTS over GRE February 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 2
3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. The Network issues faced by DOTS and UDP . . . . . . . . 3
3.2. Peer-to-peer not RESTful . . . . . . . . . . . . . . . . 3
3.3. Security Context . . . . . . . . . . . . . . . . . . . . 3
3.3.1. Stateful Security Context . . . . . . . . . . . . . . 3
3.3.2. Security Context and Fate Sharing . . . . . . . . . . 3
4. Protocol Selection Considerations . . . . . . . . . . . . . . 4
5. The DOTS Protocol Stack . . . . . . . . . . . . . . . . . . . 5
5.1. GRE full stack tunnel . . . . . . . . . . . . . . . . . . 5
5.1.1. Design Analysis . . . . . . . . . . . . . . . . . . . 5
5.2. GRE with compressed stack tunnel . . . . . . . . . . . . 5
5.3. ESP transport mode . . . . . . . . . . . . . . . . . . . 6
6. Management Considerations . . . . . . . . . . . . . . . . . . 6
6.1. DOTS agent connectivity management . . . . . . . . . . . 6
6.2. Secure Context management . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
This document describes using a GRE [RFC2784] tunnel to deliver DOTS
messages between DOTS agents. Various alternatives for transporting
DOTS messages are analyzed and the justification of GRE over
alternatives as UDP over IP and UDP over ESP over IP is presented.
The intent of this document is to encourage discussion on the most
effective set of protocols to provide the high reliability
requirement spelled out in the DOTS requirements document
[I-D.ietf-dots-requirements].
2. Terms and Definitions
2.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Moskowitz & Xia Expires August 6, 2016 [Page 2]
Internet-Draft DOTS over GRE February 2016
3. Problem Space
3.1. The Network issues faced by DOTS and UDP
DOTS messaging needs to occur during the worst time to expect
reliable packet delivery. That is during a DDoS attack. Not only is
link to (and potentially from) the DOTS client fully congested with
the attack, but also the ISPs between the attacked DOTS client and
the responsible DOTS server may have instituted UDP blocking
mitigation activities.
It is this UDP blocking mitigation action that presents a double-
edged effect. It lessens the impact of the attack, allowing TCP-
based activity to continue. It stops any attack management, i.e.
DOTS, messaging over UDP to traverse the portion of the network where
the blocking is in affect.
3.2. Peer-to-peer not RESTful
A second problem, or more a challenge, in DOTS messaging is that it
is really a peer communication. That is the DOTS server may be
messaging the DOTS client at any time, including during an attack.
Thus a client-service approach like RESTful would require 2 uni-
directional sessions.
One example of a DOTS server message is an "Attack seems over"
message from the server to the client.
3.3. Security Context
3.3.1. Stateful Security Context
Security Context is the collection of information to manage the
securing of information. In this case DOTS messages. The only
viable method for stateless security is secure data objects as in PEM
[RFC1421]. Stateless security is very resource intensive and
typically avoided unless it is the only effective approach. DOTS
messaging will use a secure data channel which is stateful. This
state needs to be managed and protected.
3.3.2. Security Context and Fate Sharing
Security Context often contains communication protocol information
like IP addresses and transport ports. In these situations the
security context is said to "share fate" with these aspects of the
communications. If something disrupts the communication state, it
disrupts the security context, often requiring some degree of
security re-initialization.
Moskowitz & Xia Expires August 6, 2016 [Page 3]
Internet-Draft DOTS over GRE February 2016
The greater the fate sharing, the more rigid the security context and
more prone to attack. Thus a secure message transport design goal is
to lessen the degree of fate sharing.
4. Protocol Selection Considerations
Based on Section 3, DOTS messaging should take advantage of protocols
that:
o Are bi-directional
One such protocol is often used for bi-directional messaging is
TCP. This is not a viable option as the ACK from sending a
message from the DOTS client to server over the potentially
uncongested uplink may never get back to the client over the
congested down link.
o Are Not Commonly blocked, particularly during a DDoS attack
UDP and ICMP fall into this avoidance category.
o Have minimal overhead
DOTS messages that are sent during an attack should fit into a
single MTU. The lower the protocol byte overhead, the more space
available for the DOTS message itself.
o Are only enabled by need on a system
It would be advantageous that the DOTS communication uses a
protocol that is typically quickly discarded by most targeted
systems. Even though these protocols are used by the DOTS agents,
the DOTS agents will be hard to find to attack and will tend to
have more resources available to deflect direct attacks.
o Support peer communications
At all protocol levels, there must be no complexities in
implementing peer communications. Pairing two uni-directional
protocols to achieve this should be avoided.
The security context that protects the DOTS messaging must support
peer communications. That is a single DOTS agent security
agreement would provide the complete context for DOTS security.
Examples include IKEv2 [RFC5996] and HIPv2 [RFC7401]. It is noted
that these maintain two uni-directional Security Associations
within the security context to properly manage the key usage in
each direction.
Moskowitz & Xia Expires August 6, 2016 [Page 4]
Internet-Draft DOTS over GRE February 2016
o Provide secure communications with minimal fate-sharing
The security context should be resilient to DOTS agent restart and
thus potential loss of protocol state. At best there should be no
fate-sharing with any protocol state. An option for security
state to be stored in a safe manner so that it need not be
renegotiated after agent restart makes forcing an agent restart an
uninteresting attack.
5. The DOTS Protocol Stack
Below are three possible protocol designs. The compressed GRE
design, Section 5.2, best meets the selection considerations
(Section 4).
5.1. GRE full stack tunnel
GRE is basically used to tunnel Ethernet payloads across an IP
network. For example an IPv4 datagram can be tunneled within GRE
with a GRE Protocol Type of 0x800. This is simple to implement on a
system, as GRE appears to IP as an interface. DOTS messaging can
secured with SSE [I-D.moskowitz-sse] on UDP over IPv4 or IPv6 within
this GRE tunnel.
GRE can also work well in a NAT traversal deployment scenario.
5.1.1. Design Analysis
The per-packet byte cost of GRE and an inner IP envelope (IPv4 or
IPv6) is balanced in part by the envelope simplicity of SSE. SSE has
the advantage of being completely free of fate-sharing with the lower
protocol levels. GRE, as indicated, is relatively easy to support as
a psuedo-interface. This is weighed against SSE being new, and any
Key Management Protocol would need negotiation parameters to support
SSE.
Use of SSE also allows secure transport of DOTS messages over non-IP
connections, for example SMS. The low SSE envelope overhead of as
little as 20 bytes can allow for 120 bytes for a single SMS message.
SMS message continuation can allow for longer DOTS messages.
5.2. GRE with compressed stack tunnel
The full GRE stack approach may overly constrain the size of the DOTS
message that can fit within a single MTU. There are approaches to
compress this into a smaller size.
Moskowitz & Xia Expires August 6, 2016 [Page 5]
Internet-Draft DOTS over GRE February 2016
There are two approaches to reduce the header overhead of the GRE
full stack tunnel outlined above. RObust Header Compression
[RFC3095] is the well-known approach. Within this compression, the
datagram will logically be the same as above.
The actual inner IP header could be compressed to zero bytes by using
the same source and destination addresses of the outer IP header.
This is more than specified in ROHC, and would involve additional
specification. NAT traversal design considerations need to be
included in the compression scheme.
5.3. ESP transport mode
ESP [RFC4303] in transport mode (or BEET with HIPv2) Provides a
familiar approach to protect UDP traffic. ESP with IKEv2 fate-shares
with both IP and UDP. ESP with HIPv2 only with UDP. Either way,
loss of UDP state due to a DOTS server crash would require
reestablishment of the security state. This keeps attacks against
the DOTS server as an important attack surface to weigh against the
familiarity of ESP with IKEv2 or HIP.
ESP limits secure DOTS messaging to IP networks. A different method
would be needed for sending DOTS messages over SMS or require IP over
a modem connection.
ESP NAT traversal uses UDP and thus reintroduces the UDP blocking
concern discussed above.
6. Management Considerations
6.1. DOTS agent connectivity management
A DOTS client needs to be configured with knowledge of the DOTS
servers. This may either by an IP address or an FQDN. If FQDN is
used, IP addresses should be cached as DNS lookups may fail during an
attack.
6.2. Secure Context management
Some trustworthy authentication needs to be set up on both sides.
This authentication knowledge will be used by a Key Management
Protocol like IKEv2 or HIPv2 to create the security context. Either
can manage the security context for ESP or SSE. Two strong
authentication methods use digital certificates or raw public keys.
Digital certificate trustworthiness may not be easy to determine.
There are many issues such as which Certificate Authority to trust
and how to manage Certificate Domain trust leakage. These issues
Moskowitz & Xia Expires August 6, 2016 [Page 6]
Internet-Draft DOTS over GRE February 2016
often result in needing to manage an authorization list of trusted
certificates.
Raw public keys for IKEv2 [I-D.kivinen-ipsecme-oob-pubkey] or HIPv2
HITs can be managed in an ACL without the cost associated with
Digital Certificates. Replacing 'old' keys can be associated with
the DOTS business model of contract renewal.
7. IANA Considerations
No IANA considerations exist for this document at this time.
8. Security Considerations
A DDoS attacker would greatly benefit from disabling DOTS. This may
be accomplished by:
o Blocking DOTS traffic.
o Disabling DOTS servers.
o Disabling DOTS clients.
A key component of this proposal is to lessen the likelihood of ISPs
from blocking DOTS traffic by not using UDP. Whatever protocol DOTS
uses, may be used in future DDoS attacks, but will not be as
effective as UDP based attacks. Thus not using UDP is a worthwhile
goal.
DOTS server resiliency to attacks is a critical goal. Loss of a DOTS
server can impact many clients (customers). The less fate-sharing
the higher the attack resiliency, which is why this document
recommends the GRE with compressed stack tunnel, Section 5.2,
approach.
DOTS clients will tend to be invisible to attackers, but over time
they will be discovered for targeted attacks, thus the same
resiliency considerations applied to the servers also apply to the
clients. Additionally, DOTS clients should avoid access to as many
Internet services as possible, as at critical times they may be
blocked. Thus a non-PKI authentication scheme as in raw public keys
has the advantage of needing one less Internet resource that may be
blocked.
Moskowitz & Xia Expires August 6, 2016 [Page 7]
Internet-Draft DOTS over GRE February 2016
9. Contributors
The following contributed actively to the this document: Sue Hares
(Huawei)
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References
[I-D.ietf-dots-requirements]
Mortensen, A., Moskowitz, R., and T. Reddy, "DDoS Open
Threat Signaling Requirements", draft-ietf-dots-
requirements-00 (work in progress), October 2015.
[I-D.kivinen-ipsecme-oob-pubkey]
Kivinen, T., Wouters, P., and H. Tschofenig, "Generic Raw
Public Key Support for IKEv2", draft-kivinen-ipsecme-oob-
pubkey-14 (work in progress), October 2015.
[I-D.moskowitz-sse]
Moskowitz, R., Faynberg, I., <>, H., Hares, S., and P.
Giacomin, "Session Security Envelope", draft-moskowitz-
sse-01 (work in progress), January 2016.
[RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication
Procedures", RFC 1421, DOI 10.17487/RFC1421, February
1993, <http://www.rfc-editor.org/info/rfc1421>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000,
<http://www.rfc-editor.org/info/rfc2784>.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095,
July 2001, <http://www.rfc-editor.org/info/rfc3095>.
Moskowitz & Xia Expires August 6, 2016 [Page 8]
Internet-Draft DOTS over GRE February 2016
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, DOI 10.17487/RFC5996, September 2010,
<http://www.rfc-editor.org/info/rfc5996>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>.
Authors' Addresses
Robert Moskowitz
Huawei
Oak Park, MI 48237
USA
Phone: +1-248-968-9809
Email: rgm@htt-consult.com
Jinwei Xia
Huawei
101 Software Avenue
Nanjing, Yuhua District 210012
China
Phone: +86-025-84565890
Email: xiajinwei@huawei.com
Moskowitz & Xia Expires August 6, 2016 [Page 9]