One document matched: draft-moskowitz-dots-ssls-02.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
 <?rfc toc="yes" ?>
 <?rfc symrefs="yes" ?>
 <?rfc sortrefs="yes"?> 
 <?rfc compact="yes" ?>
 <?rfc subcompact="no" ?>  
 <?rfc iprnotified="no" ?>
  <?rfc strict="no" ?>

<rfc category="std" docName="draft-moskowitz-dots-ssls-02.txt" ipr="trust200902">

<front>
<title abbrev="DOTS SSLS">DOTS Secure Session Layer Services</title>
	<author fullname="Robert Moskowitz" initials="R." surname="Moskowitz" >
	<organization>HTT Consulting</organization>
	<address>
	<postal> 
	  <street> </street>
	  <city>Oak Park</city>
	  <region>MI</region>
	  <code>48237</code> 
	  </postal>
	<email>rgm@labs.htt-consult.com</email>
	</address>
	</author>
	<author fullname="Susan Hares" initials="S." surname="Hares">
	<organization>Huawei</organization>
	<address>
	<postal> 
	  <street>7453 Hickory Hill</street>
	  <city>Saline</city>
	  <region>MI</region>
	  <code>48176</code>
	  <country>USA</country>
	</postal>
	<email>shares@ndzh.com</email>
	</address>
	</author>
<date year="2016" />
   <area>Security Area</area>
    <workgroup>DOTS WG</workgroup>
    <keyword>RFC</keyword>
     <keyword>Request for Comments</keyword>
     <keyword>I-D</keyword>
     <keyword>Internet-Draft</keyword>
<abstract>
<t>
	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.      
</t>
</abstract>
</front>
<middle>   
<section title="Introduction">
<t> 
	The DOTS requirements <xref target="I-D.ietf-dots-requirements" />
	includes 
	<list style="symbols">
		<t>Reduced fate-sharing</t>
		<t>Perform well during times of high congestion</t>
	</list>
</t> 
<t> 
	These requirements are at best challenging to meet with the 
	traditional IETF communication building blocks of TCP+TLS or 
	UDP+DTLS.  Recent work <xref target="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:
	<list style="symbols">
		<t>Data chunking</t>
		<t>Data compression</t>
		<t>Fully peered data security</t>
		<t>Survivablity of security state</t>
	</list>
</t> 
<t>
	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.
</t>
<t>
	The intelligence to make the transport decision and the knowledge
	as to parameters like appropriate chunking size is managed in the
	session layer.
</t>
</section>
<section anchor="terms" title="Terms and Definitions">
	<section title="Requirements Terminology">
	<t>
		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 <xref target="RFC2119">RFC 2119</xref>.
	</t>
	</section>
	<section title="Definitions">
	<t>
		<list style="hanging">
		<t hangText="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.
		</t>
		</list>
	</t>
	</section>
</section>
<section anchor="prob-space" title="Problem Space">
<t>
	The communication problems faced by DOTS are defined in the DOTS 
	requirements <xref target="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.
</t>
<section anchor="crypto-conundrum" title="The crypotgraphic state conundrum">
<t>
	The cost for cryptography can come through frequent asymmetric key 
	operations as in DKIM <xref target="RFC5585" /> and DSRC's 
	IEEE 1609.2 <xref target="IEEE.1609.2-2013" /> or maintaining 
	communications security state as in TLS, DTLS, and IPsec.
</t>
<t>
	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.
</t>
<t>
	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.
</t>
<section anchor="no-IPsec" title="IPsec not a solution">
<t>
	IKEv2 <xref target="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 <xref 
	target="RFC4303"></xref> 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.
</t>
<t>
	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.
</t>
<t>
	ESP NAT traversal uses UDP and thus reintroduces the UDP blocking
	concern discussed above.
</t>
</section>
</section>
</section>
<section anchor="sls" title="Introducting a Session Layer Service">
<t>
	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 <xref 
	target="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.
</t>
<section anchor="sls-services" title="Services provided at Session Layer">
<t>
	Six key services are built into <xref target="I-D.hares-i2nsf-ssls" />:
	<list style="symbols">
		<t>KMP negotiation of compression and security</t>
		<t>Data chunking</t>
		<t>Data compression [GPComp]</t>
		<t>Fully peered data security <xref target="I-D.moskowitz-sse" /></t>
		<t>Survivablity of security state <xref target="I-D.moskowitz-sse" /></t>
		<t>Chuck fragmentation/Reassembly</t>
	</list>
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
	No IANA considerations exist for this document at this time.
</t>
</section>
<section title="Security Considerations">
<t>
	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.
</t>
</section>
<section title="Contributors">
<t>
	TBD
</t>
</section>
</middle>
<back>
<references title="Normative References">
	<?rfc include="reference.RFC.2119.xml"?>
</references>
<references title="Informative References">
	<?rfc include="reference.I-D.ietf-dots-requirements.xml"?>
	<?rfc include="reference.I-D.moskowitz-sse.xml"?>
	<?rfc include="reference.RFC.4303.xml"?>
	<?rfc include="reference.RFC.5585.xml"?>
	<?rfc include="reference.RFC.7296.xml"?>
	<?rfc include="reference.RFC.7401.xml"?>
	<reference anchor="IEEE.1609.2-2013">
		<front>
		<title>IEEE Standard for Wireless Access in Vehicular 
		Environments—Security Services for Applications and Management 
		Messages"</title>
		<author fullname="Institute of Electric and Electronic Engineers">
		<organization></organization>
		</author>
		<date month="April" year="2013" />
		</front>
		<seriesInfo name="IEEE" value="Standard 1609.2" />
	</reference>
<reference anchor='I-D.hares-i2nsf-ssls'>
<front>
<title>Session Security Envelope</title>

<author initials='S' surname='Hares' fullname='Susan Hares'>
    <organization />
</author>

<author initials='R' surname='Moskowitz' fullname='Robert Moskowitz'>
    <organization />
</author>

<date month='March' day='21' year='2016' />

</front>

<seriesInfo name='Internet-Draft' value='draft-hares-i2nsf-ssls-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-hares-i2nsf-ssls-00.txt' />
<format type='PDF'
        target='http://www.ietf.org/internet-drafts/draft-hares-i2nsf-ssls-00.pdf' />
</reference>
</references>
</back>
</rfc>