| 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-00.txt
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.
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 (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.
The DOTS requirements [I-D.ietf-dots-requirements] includes
These requirements are at best challenging to meet with the traditional IETF communication building blocks of TCP+TLS or UDP+DTLS. Recent work [ietf-hares-sls] 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:
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 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.
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].
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.
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.
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.
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.
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.
Six key services are built into [ietf-hares-sls]:
No IANA considerations exist for this document at this time.
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.
TBD
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |