[Dots] DOTS secure transport discussion - introducing SSLS

Robert Moskowitz <rgm-sec@htt-consult.com> Tue, 22 March 2016 13:13 UTC

Return-Path: <rgm-sec@htt-consult.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2194312D5DC for <dots@ietfa.amsl.com>; Tue, 22 Mar 2016 06:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMzb5qpPBsKd for <dots@ietfa.amsl.com>; Tue, 22 Mar 2016 06:13:23 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA7712D793 for <dots@ietf.org>; Tue, 22 Mar 2016 06:13:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 0881062180 for <dots@ietf.org>; Tue, 22 Mar 2016 09:13:12 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0snPotdi2LOD for <dots@ietf.org>; Tue, 22 Mar 2016 09:13:04 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 3F83A6217E for <dots@ietf.org>; Tue, 22 Mar 2016 09:13:04 -0400 (EDT)
To: "dots@ietf.org" <dots@ietf.org>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID: <56F144DE.1040100@htt-consult.com>
Date: Tue, 22 Mar 2016 09:13:02 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dots/MWoNqkQop365zwf182gx_gQ53IM>
Subject: [Dots] DOTS secure transport discussion - introducing SSLS
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2016 13:13:29 -0000

I find the DOTS requirements for message transport interesting and 
somewhat unique:

1)    Secure, of course.
2)    Perform well in the face of high congestion, typically on the 
receive link.
3)    Bi-directional.  Actually tightly linked uni-directional flows.
         That is peered more than client/server (despite clear 
cleint/server roles).
4)    Reduce communication stack fate-sharing to reduce attack surface.
5)    Easily restartable during an attack. (recovery after agent 
failure/reboot)


I can, and will if called on it, go through my logic in saying that TLS 
over TCP is not a good tool and even DTLS over UDP misses the mark.  ESP 
in transport mode comes close, but we can do better.

I have put this in:

https://www.ietf.org/internet-drafts/draft-moskowitz-dots-ssls-02.txt

DOTS Secure Session Layer Services

This introduces a real session layer, something really not present in 
the IETF stack, that provides a set of services.  SSLS and its services 
are laid out in:

https://www.ietf.org/internet-drafts/draft-hares-i2nsf-ssls-00.txt

Sue (and I) put the design for SSLS in i2nsf, as it is broadly 
applicable in a number of areas under i2nsf.  This includes i2rs and 
what I have called firstMILE (more on this shortly oer on MILE list).

Two other drafts that fit into this architecture are:

https://www.ietf.org/internet-drafts/draft-moskowitz-sse-03.txt
and
https://www.ietf.org/internet-drafts/draft-moskowitz-gpcomp-00.txt

SSLS (and SSE and GPComp) can use either IKEv2 or HIPv2 (or HIP-DEX) as 
the KMP to establish paired, tightly coupled uni-directional Security 
Associations.

By operating above the transport (TCP,UDP, SCTP, SMS, etc.) the security 
state is independent of transport setup and teardown.  SLS can even 
choose which transport to use under whatever knowledge it has of the 
condition and needs of the time.  It can support multiple, simultaneous, 
communication channels (fully leveraging SCTP for i2rs).

The work on SLS is not done.  A few of us have been working on it for a 
year, but only recently have the pieces fallen together.  SSE is ESP 
moved up the stack and I know of one non-public use of it. GPComp is 
IPCOMP moved up the stack and knowledge of which compression algorithm 
not advertised in each datagram.  Those are really the easy parts.  The 
KMP part is not a stretch.  Both IKE and HIP are higher layer KMPs and 
can be set up to be called as needed. But some work is needed still.

SLS is the new component.  The i2nsf-ssls draft needs clean up; I expect 
it to be further along by IETF (though not postable).

SO.....

I open the floor to discussion.

I would be interested in how others see using existing communication 
services to meet the DOTS requirements.

I am interested in how others see SLS and particularly SSLS and its use 
for DOTS.  I have a slot in the meeting, but I hope by that friday we 
have shaped some positions on this area.

Robert Moskowitz