Internet DRAFT - draft-moskowitz-dots-ssls

draft-moskowitz-dots-ssls







DOTS WG                                                     R. Moskowitz
Internet-Draft                                            HTT Consulting
Intended status: Standards Track                                S. Hares
Expires: September 22, 2016                                       Huawei
                                                          March 21, 2016


                   DOTS Secure Session Layer Services
                    draft-moskowitz-dots-ssls-02.txt

Abstract

   This document describes using a session layer service for DOTS
   messaging to provide secure messaging while delivering on a number of
   DOTS requirements including avoiding fate-sharing with the under-
   lying communications.

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 September 22, 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 & Hares      Expires September 22, 2016               [Page 1]

Internet-Draft                  DOTS SSLS                     March 2016


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Terminology  . . . . . . . . . . . . . . . .   3
     2.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Space . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  The crypotgraphic state conundrum . . . . . . . . . . . .   3
       3.1.1.  IPsec not a solution  . . . . . . . . . . . . . . . .   4
   4.  Introducting a Session Layer Service  . . . . . . . . . . . .   4
     4.1.  Services provided at Session Layer  . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The DOTS requirements [I-D.ietf-dots-requirements] includes

   o  Reduced fate-sharing

   o  Perform well during times of high congestion

   These requirements are at best challenging to meet with the
   traditional IETF communication building blocks of TCP+TLS or
   UDP+DTLS.  Recent work [I-D.hares-i2nsf-ssls] present a new/old way
   of isolating the DOTS protocol from the fate of the Internet
   Transport protocols by providing an OSI-styled Session Layer that
   provides:

   o  Data chunking

   o  Data compression

   o  Fully peered data security

   o  Survivablity of security state

   A session layer approach to DOTS would allow a single DOTS client/
   server communication to be selective on transport technology to the
   appropriate one for a given situation.  For example without requiring
   additional security management, a TCP connection can be used for
   large transfers during un-congested times.  Communications can switch
   to UDP during congestion caused by an on-going attack.  Even SMS (if



Moskowitz & Hares      Expires September 22, 2016               [Page 2]

Internet-Draft                  DOTS SSLS                     March 2016


   directly supported by the DOTS agents) can be employed to get the
   message out during an attack.  All this with a single, manageable
   state between the DOTS client and agent.

   The intelligence to make the transport decision and the knowledge as
   to parameters like appropriate chunking size is managed in the
   session layer.

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].

2.2.  Definitions

   DSRC:  (Dedicated Short Range Communications) is a two-way short- to-
      medium-range wireless communications capability that permits very
      high data transmission critical in communications-based automotive
      active safety applications.

3.  Problem Space

   The communication problems faced by DOTS are defined in the DOTS
   requirements [I-D.ietf-dots-requirements].  General requirements 2, 3
   and 4: Resiliance and Robustness, Bidirectionality, and Sub-MTU
   Message size, present challenges to current IETF communication tools.
   Only IPsec approaches a good fit to these requirements.

3.1.  The crypotgraphic state conundrum

   The cost for cryptography can come through frequent asymmetric key
   operations as in DKIM [RFC5585] and DSRC's IEEE 1609.2
   [IEEE.1609.2-2013] or maintaining communications security state as in
   TLS, DTLS, and IPsec.

   DKIM can afford asymmetric key operations as it works on a loose
   timing basis.  DSRC is requiring dedicated asymmetric key hardware in
   each car; the consumer will be absorbing those costs.  DOTS does not
   have the sub-second timing requirements like DSRC, nor does it have
   the minutes leeway of DKIM.  It is unlikely that the many DOTS
   clients will have the processing power for asymmetric key operations
   during a DDoS attack.  Thus DOTS should rely on one of the stateful
   secure communications technologies.





Moskowitz & Hares      Expires September 22, 2016               [Page 3]

Internet-Draft                  DOTS SSLS                     March 2016


   Stateful secure communications implies some method of maintaining
   this state, especially during an active attack.  Both TLS and DTLS
   share fate with the underlying transport.  This means that if either
   the DOTS client or server is forced to reboot due to an attack (or
   any other reason), the D/TLS state needs to be reset.  For a DOTS
   client under attack, this can be a processor expensive operation and
   may fail out of hand if the downlink is flooded with attack traffic
   and the server response is lost.  The DOTS server has the additional
   conundrum as how to notify the client to reset the lost security
   state in a manner that does not introduce yet another attack.

3.1.1.  IPsec not a solution

   IKEv2 [RFC7296] can be started from either participant.  This means
   that a DOTS server can reset the security state as part of its reboot
   process.  ESP [RFC4303] in transport mode provides a familiar
   approach to protect UDP traffic.  ESP with IKEv2 fate-shares with
   both IP and UDP.  The 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.

   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.

4.  Introducting a Session Layer Service

   The DOTS communication and security requirements can solved by moving
   above the transport and define an OSI-styled session layer.  A
   session-layer service would not fate-share with the underlying
   transport.  A peer-based KMP like IKEv2 or HIPv2 [RFC7401] can be
   initiated by either side, making recovery of security state straight-
   forward.  Further, if the security state is maintained in a secure
   store that can survive a system reboot, no reseting of the security
   state would be necessary after a reboot.  This would make an attack
   that causes a DOTS agent to reboot less interesting.

4.1.  Services provided at Session Layer

   Six key services are built into [I-D.hares-i2nsf-ssls]:

   o  KMP negotiation of compression and security

   o  Data chunking



Moskowitz & Hares      Expires September 22, 2016               [Page 4]

Internet-Draft                  DOTS SSLS                     March 2016


   o  Data compression [GPComp]

   o  Fully peered data security [I-D.moskowitz-sse]

   o  Survivablity of security state [I-D.moskowitz-sse]

   o  Chuck fragmentation/Reassembly

5.  IANA Considerations

   No IANA considerations exist for this document at this time.

6.  Security Considerations

   A session layer security approach leaves the lower layers open to
   attack.  These attacks should not impact the DOTS application or
   session security.  At most they form yet another DoS attack against
   the DOTS agents.  This cost is considered acceptable balanced by the
   gains against other attacks if the security and other related
   services are moved back down the stack.

7.  Contributors

   TBD

8.  References

8.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>.

8.2.  Informative References

   [I-D.hares-i2nsf-ssls]
              Hares, S. and R. Moskowitz, "Session Security Envelope",
              draft-hares-i2nsf-ssls-00 (work in progress), March 2016.

   [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.







Moskowitz & Hares      Expires September 22, 2016               [Page 5]

Internet-Draft                  DOTS SSLS                     March 2016


   [I-D.moskowitz-sse]
              Moskowitz, R., Faynberg, I., Lu, H., Hares, S., and P.
              Giacomin, "Session Security Envelope", draft-moskowitz-
              sse-03 (work in progress), March 2016.

   [IEEE.1609.2-2013]
              "IEEE Standard for Wireless Access in Vehicular
              Environments--Security Services for Applications and
              Management Messages"", IEEE Standard 1609.2, April 2013.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <http://www.rfc-editor.org/info/rfc4303>.

   [RFC5585]  Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
              Identified Mail (DKIM) Service Overview", RFC 5585,
              DOI 10.17487/RFC5585, July 2009,
              <http://www.rfc-editor.org/info/rfc5585>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <http://www.rfc-editor.org/info/rfc7296>.

   [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
   HTT Consulting
   Oak Park, MI  48237

   Email: rgm@labs.htt-consult.com


   Susan Hares
   Huawei
   7453 Hickory Hill
   Saline, MI  48176
   USA

   Email: shares@ndzh.com






Moskowitz & Hares      Expires September 22, 2016               [Page 6]