DOTS Secure Session Layer Services

The DOTS requirements includes Reduced fate-sharing 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 [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: Data chunking Data compression Fully peered data security 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 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.

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

The communication problems faced by DOTS are defined in the 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 and DSRC's IEEE 1609.2 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 can be started from either participant. This means that a DOTS server can reset the security state as part of its reboot process. ESP 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 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]: KMP negotiation of compression and security Data chunking Data compression [GPComp] Fully peered data security Survivablity of security state Chuck fragmentation/Reassembly

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