Internet DRAFT - draft-moskowitz-dots-gre

draft-moskowitz-dots-gre







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]