Subject: [Dots] DOTS secure transport discussion - introducing SSLS

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Mar 2016 09:13:02 -0400

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

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 23 Mar 2016 06:57:48 +0700

> services to meet the DOTS requirements.

While I'm not at all averse to transport-independence - quite the 
opposite - supporting both UDP and TCP is a hard requirement.

As noted previously, there are often highly restrictive network access 
policies in place on endpoint networks.  Therefore, *relying* on 
anything other than TCP and UDP is a non-starter.

Relying on ESP, for example, guarantees that DOTS will *never* be widely 
adopted by the very networks which need it the most - endpoint networks.

I like SCTP a great deal, and would like to have the option to use it - 
but it cannot be the sole transport mechanism.  Same for any other 
non-TCP/non-UDP protocol.

Per previous discussion, TCP is non-optimal, but *must* be an option to 
allow signaling functionality in highly restrictive policy environments.

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

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Mar 2016 21:31:44 -0400

And that is one of the drivers for SSLS.  It moves the security and 
other functions above the IETF transport, allowing more easy selection 
of which transport.

TCP, UDP, SCTP, SMS, XNS :), all supportable.

I really listened to you, Roland.  I do understand that I am proposing 
something new here, but I am working within the communications structure 
that you have experienced.  Of course, watch corporate IT people get 
bent that the datagrams within TCP are all encrypted!  But then for 
those clients you COULD use CMAC as defined in SSE draft.

On 03/22/2016 07:57 PM, Roland Dobbins wrote:
> Relying on ESP, for example, guarantees that DOTS will *never* be 
> widely adopted by the very networks which need it the most - endpoint 
> networks.
>
> I like SCTP a great deal, and would like to have the option to use it 
> - but it cannot be the sole transport mechanism.  Same for any other 
> Per previous discussion, TCP is non-optimal, but *must* be an option 
> to allow signaling functionality in highly restrictive policy 
> environments.
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 23 Mar 2016 02:10:01 +0000

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
> Sent: Wednesday, March 23, 2016 5:28 AM
> To: [email-masked]
> Subject: Re: [Dots] DOTS secure transport discussion - introducing SSLS
> 
> While I'm not at all averse to transport-independence - quite the opposite -
> supporting both UDP and TCP is a hard requirement.
> 
> As noted previously, there are often highly restrictive network access policies
> in place on endpoint networks.  Therefore, *relying* on anything other than
> TCP and UDP is a non-starter.

Yup.

> I like SCTP a great deal, and would like to have the option to use it - but it
> cannot be the sole transport mechanism.  Same for any other non-TCP/non-
> UDP protocol.

SCTP has NAT/Firewall traversal problem, to overcome this WebRTC Data channels uses SCTP over DTLS over UDP. No benefit of using SCTP compared to UDP in order to address the NAT/Firewall traversal problems.

-Tiru

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 23 Mar 2016 10:06:57 +0700

On 23 Mar 2016, at 9:10, Tirumaleswar Reddy (tireddy) wrote:

> No benefit of using SCTP compared to UDP in order to address the 
> NAT/Firewall traversal problems.

That's true today, and is likely to be true tomorrow, and next year, 
etc.  This is why TCP and UDP are must-haves.

But having the ability to run over SCTP, or anything else one desires, 
would be nice.  This entails a clear separation of DOTS semantics from 
transport semantics - which is a good design practice, anyways.

---

From: "gclark mti-systems.com" <[email-masked]>
Date: Tue, 22 Mar 2016 23:10:29 -0400 (EDT)

> transport semantics - which is a good design practice, anyways.

+1

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Mar 2016 23:20:32 -0400

>> transport semantics - which is a good design practice, anyways.

I have provided a clear separation.  But I do not have the 
knowledge/experience to define the DOTS semantics.

I am looking at one other needed service in SLS, which is a clear API 
for a message START/MIDDLE/END; I can add this to the CHUNKING service 
or make it separate.  TCP lacks this.  Look at what NETCONF has to do to 
indicate end of their XML message; really messy.  I thought, why don't 
they just define an rpc xml object?  Then I realized (based on my 
experience over the past few days writing xml for internet drafts) that 
you cannot be assured that a programmer will get the xml structure right 
and what is sent may not parse properly at the receiver.  Back to square 
one with TCP's TELNETish approach of handling streams into packets.  
Messy at best.

UDP just means the programmer can get more wrong.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 23 Mar 2016 03:52:39 +0000

> Sent: Wednesday, March 23, 2016 8:37 AM
> To: [email-masked]
> That's true today, and is likely to be true tomorrow, and next year, etc.  This
> is why TCP and UDP are must-haves.
> 
> But having the ability to run over SCTP, or anything else one desires, would
> be nice.  This entails a clear separation of DOTS semantics from transport
> semantics - which is a good design practice, anyways.

Yes, that's one of the reasons https://tools.ietf.org/html/draft-reddy-dots-transport-03 for DOTS signaling/data channel proposes to use COAP which can run over UDP/TCP and any other transport like SCTP in future. IMHO, the WG should mandate transports like UDP/TCP for implementations to support and test for interoperability. Any new transport requires enhancements to implementations and interoperable testing. Just like the WG discussed the reasons for picking UDP and TCP, other transports needs more discussion on why it should be mandated by the DOTS protocols.

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 23 Mar 2016 05:12:04 +0000

> UDP just means the programmer can get more wrong.

Programmers have been using UDP for ages, many protocols run over UDP.

-Tiru

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 23 Mar 2016 21:25:53 +0700

On 23 Mar 2016, at 10:52, Tirumaleswar Reddy (tireddy) wrote:

> Just like the WG discussed the reasons for picking UDP and TCP, other 
> transports needs more discussion on why it should be mandated by the 
> DOTS protocols.

Concur 100%.

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 23 Mar 2016 21:26:48 +0700

> Programmers have been using UDP for ages, many protocols run over UDP.

Absolutely - including very demanding applications such as large, 
performance-sensitive multiplayer games.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 23 Mar 2016 10:49:24 -0400

> performance-sensitive multiplayer games.

And why communication components like RTP were developed to aid such 
programmers in dealing with all the things that need to be attended to.

I remember what CuCme did before RED was developed.

---

From: "gclark mti-systems.com" <[email-masked]>
Date: Wed, 23 Mar 2016 13:19:33 -0400 (EDT)

> On March 23, 2016 at 10:49 AM Robert Moskowitz <[email-masked]>
> wrote:
> 
> 
> 
> 

Donning my programmer hat for a moment, I find this conversation pointless.
 Speaking as a representative of my people, I can assure you that we are, in
fact, quite capable of implementing things over UDP directly when we *determine
there is a need to do so*.  Alternatively, we programmers might decide to use
RTP in certain situations *because it seems like the best choice*.  Such things
are not always straightforward decisions, and possible rationales for such
decisions are not a thing I'm going to waste time discussing here.

With that said, let's also not forget that networking is a way to shovel piles
of bits from point A to point B.  Standards (and IETF working groups, for that
matter) don't exist to do anything with the bits: instead, the working groups
primarily exist to make sure everybody agrees on a shovel.  If someone wants to
make a better shovel, fine ... but telling people they're too stupid to actually
be using the shovel they've had and loved for years *might* not be the best way
to go about things.

As an aside, I'm really not sold on this whole session layer idea *as it relates
to DOTS*.  I don't disagree because it's necessarily bad (because I honestly
haven't spent the cycles to evaluate in any kind of meaningful way), I disagree
because I don't see a *shred* of operational experience that might *prove its
necessity*.  Why are we chunking things when we don't have things defined to be
chunked?  Why are we talking about compression when we don't know if anything
actually *needs* to be compressed?

-Gilbert

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 23 Mar 2016 14:01:03 -0400

> actually *needs* to be compressed?

Just to the compression point.  Compression is in the SLS design as some 
uses, like structured xml like in NETCONF is very compressable.  Odds 
are that DOTS will use a compact message structure that will not need 
compressing.  But the compression service, that was designed for use 
within ESP back in the late 90s is very adaptive and figures out what is 
and not compressable. Today, it is not much used but it is a direct way 
to deal with structured xml over constrained communications.  It is 
optional.

Got to run for a while...

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 23 Mar 2016 20:24:27 +0000

Robert, 

 A couple of questions for SSLS & GPcomp:

- What data will GPcomp will compress? The first hop of any end node is Ethernet, which has 64 minimum bytes, with 46 bytes payload. 
The minimum IP packet header has 20 bytes. You can't really compress the header, can you? 
If the signaling is compact, a few bytes, the compression can't really get much value. 

- What is the relationship among SSE, SSLS, GPcomp? 

Thanks, Linda 

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Robert Moskowitz
Sent: Tuesday, March 22, 2016 8:13 AM
To: [email-masked]
Subject: [Dots] DOTS secure transport discussion - introducing SSLS

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

1)    Secure, of course.
         That is peered more than client/server (despite clear cleint/server roles).

I have put this in:

SO.....

Robert Moskowitz

---

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

On 24 Mar 2016, at 0:19, gclark mti-systems.com wrote:

> Why are we chunking things when we don't have things defined to be 
> chunked?  Why are we talking about compression when we don't know if 
> anything actually *needs* to be compressed?

We do seem to be getting a bit ahead of ourselves, concur 100%.  As well 
as continued attempts to do things like reinvent parts of IPFIX, poorly 
and unnecessarily, within DOTS.