Subject: [Dots] Fwd: New Version Notification for draft-moskowitz-dots-ssls-02.txt

From: Robert Moskowitz <[email-masked]>
Date: Mon, 21 Mar 2016 14:43:41 -0400

For my agenda item on

Introducing session layer considerations

Please see the following draft.  There are a number of 'embedded' drafts 
to work through to get the whole story.  I will start a discuss on this 
tomorrow on the list.

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-moskowitz-dots-ssls-02.txt
Date: 	Mon, 21 Mar 2016 11:40:20 -0700
From: 	[email-masked]
To: 	Robert Moskowitz <[email-masked]>, Susan Hares 
<[email-masked]>

A new version of I-D, draft-moskowitz-dots-ssls-02.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name:		draft-moskowitz-dots-ssls
Revision:	02
Title:		DOTS Secure Session Layer Services
Document date:	2016-03-21
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/internet-drafts/draft-moskowitz-dots-ssls-02.txt
Status:         https://datatracker.ietf.org/doc/draft-moskowitz-dots-ssls/
Htmlized:       https://tools.ietf.org/html/draft-moskowitz-dots-ssls-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-moskowitz-dots-ssls-02

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.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: 🔓Dan Wing <[email-masked]>
Date: Wed, 23 Mar 2016 17:59:52 -0700

On 21-Mar-2016 11:43 am, Robert Moskowitz <[email-masked]> wrote: 
> Please see the following draft.  There are a number of 'embedded' drafts to work through to get the whole story.  I will start a discuss on this tomorrow on the list.

If we need fragmentation support, a fragmentation layer on top of DTLS would serve us better than SSLS.  DTLS already handles fragmentation for its own handshakes (similar to IKE's RFC7383), leaving us with solving the fragmentation/reassembly. I see both draft-fossati-dtls-over-gsm-sms (expired) and draft-hartke-dice-practical-issues (expired) explored the problem and some solutions with small-MTU networks with UDP packets.

But back to requirements for a moment:  what is the minimum MTU we need DOTS signaling to be sent over?  I have always imagined we are running over the same network as the Internet-originated DoS traffic itself is originated from the Internet or from a WiFi, LTE, or Ethernet-connected device, which means the MTU is approximately 1280 bytes (considering both IPv6 minimum MTU of 1280, and the typical IPv4 MTU seen on the Internet).  But it seems draft-moskowitz-dots-ssls is anticipating using SMS for signaling.  According to draft-fossati-dtls-over-gsm-sms, SMS can do its own reassembly ("Concatenated short messages") so for SMS it seems we (IETF) don't need to do protocol work SMS fragmentation/reassembly.

-d

> From:	[email-masked] <mailto:[email-masked]>
> To:	Robert Moskowitz <[email-masked]> <mailto:[email-masked]>, Susan Hares <[email-masked]> <mailto:[email-masked]>
> 
> URL:            https://www.ietf.org/internet-drafts/draft-moskowitz-dots-ssls-02.txt <https://www.ietf.org/internet-drafts/draft-moskowitz-dots-ssls-02.txt>
> Status:         https://datatracker.ietf.org/doc/draft-moskowitz-dots-ssls/ <https://datatracker.ietf.org/doc/draft-moskowitz-dots-ssls/>
> Htmlized:       https://tools.ietf.org/html/draft-moskowitz-dots-ssls-02 <https://tools.ietf.org/html/draft-moskowitz-dots-ssls-02>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-moskowitz-dots-ssls-02 <https://www.ietf.org/rfcdiff?url2=draft-moskowitz-dots-ssls-02>
> 
> Abstract:
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 24 Mar 2016 10:47:14 +0700

On 24 Mar 2016, at 7:59, 🔓Dan Wing wrote:

> I have always imagined we are running over the same network as the 
> Internet-originated DoS traffic itself is originated from the Internet 
> or from a WiFi, LTE, or Ethernet-connected device

That's the typical scenario.  SMS, QR codes, et. al. are nice-to-haves, 
but aren't the primary communications path/medium.

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: "gclark mti-systems.com" <[email-masked]>
Date: Fri, 25 Mar 2016 10:58:38 -0400 (EDT)

> On March 23, 2016 at 11:47 PM Roland Dobbins <[email-masked]> wrote:
> 
> 

Right, that is the typical scenario ... but I don't necessarily agree that it is
the *only* scenario.  In the event we *do* have better / alternative channels
available, I feel like DOTS should be able to capitalize on those without
dragging along *too much* of the baggage necessary to support operation across
bad links and / or the internet in general.

Also, I feel like the transport problem, the session problem, etc. are a *lot
less* important than the model problem.  The way I see it, DOTS should primarily
describe a standard data format (with standardized data fields) that gets pushed
across the wire / radio waves / encoded into a QR code / whatever ... because
the optimal transport is *always* going to depend on the environment into which
DOTS is being deployed.

-Gilbert

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 25 Mar 2016 22:21:08 +0700

On 25 Mar 2016, at 21:58, gclark mti-systems.com wrote:

> The way I see it, DOTS should primarily

Concur 100%.