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

From: Robert Moskowitz <[email-masked]>
Date: Wed, 3 Feb 2016 08:09:39 -0500

I offer this draft to DOTS as a solid approach to meet the requirements 
for the underlying transport mechanism for DOTS messaging.

I request a time slot to present and discuss this at the upcoming 
meeting.  And further request that our time slot NOT be Monday morning.  
Famlly activities (youngest son's wedding) result in my not arriving 
until Monday.

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-moskowitz-dots-gre-00.txt
Date: 	Wed, 03 Feb 2016 04:48:44 -0800
From: 	[email-masked]
To: 	Jinwei Xia <[email-masked]>, Robert Moskowitz 
<[email-masked]>

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

Name:		draft-moskowitz-dots-gre
Revision:	00
Title:		DOTS over GRE
Document date:	2016-02-03
Group:		Individual Submission
Pages:		9
URL:https://www.ietf.org/internet-drafts/draft-moskowitz-dots-gre-00.txt
Status:https://datatracker.ietf.org/doc/draft-moskowitz-dots-gre/
Htmlized:https://tools.ietf.org/html/draft-moskowitz-dots-gre-00

Abstract:
    This document describes using a GRE tunnel to deliver DOTS messages
    between DOTS agents and compares it to other methods.

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: Stefan Fouant <[email-masked]>
Date: Thu, 4 Feb 2016 14:56:36 +0000

From:  Dots <[email-masked]> on behalf of Robert Moskowitz
<[email-masked]>
Date:  Wednesday, February 3, 2016 at 8:09 AM
To:  "[email-masked]" <[email-masked]>
Subject:  [Dots] Fwd: New Version Notification
for	draft-moskowitz-dots-gre-00.txt

>Famlly activities (youngest son's wedding) result in my not arriving

Hi Robert,

Thank you for your submission. I had a chance to briefly look through this
and jotted down some of my thoughts below. In order to get the full gist,
I also had to read your work in progress on SSE. My thoughts below are
areas where I would like additional clarification or simply to open it up
to a broader discussion.

For starters, I¹m not sure I buy the whole ³UDP gets blocked inbound²
argument, I¹ve heard that mentioned a few times here on the list, but TBH
that¹s never been my experience in years of working in the DDoS spaceŠ
nonetheless I do like the aspect of using a different encapsulation
protocol, it simply reduces the likelihood of DOTS messaging being
intentionally or unintentionally blocks, so let¹s move forwardŠ

I agree with most of your points in section 4, and I like the
recommendations on reducing fate-sharing.

WRT the details of the DOTS protocol stack, I may need some convincing.
Perhaps I am off base here, but It appears to me that we really just need
authentication. Once we factor in the SSE (Compact Format), we¹ve already
burned through a full 8 bytes. Full encryption of the communications may
be an unnecessary requirement - after all this is telemetry about traffic
that is already in the public domain, it¹s not like there is sensitive
data here. Furthermore, there is some perception that AEAD may be
vulnerable to side-channel attacks, due to lack of MAC (I will admit this
is theoretical). Nonetheless, if we want auth and encryption, it¹s still
better than SSL/TLS in my opinion. It also appears to meet an underlying
goal we had of being able to fit DOTS messages into an MTU of 1476 bytes
or less.

One other thing to add, it seems that the key and sequence number
extension to GRE (RFC2890) might be able to subsume some of what we¹re
trying to accomplish aboveŠ Just a thought.

With regards to the Robust Header Compression and its applicability
towards the ³GRE with compressed stack tunnel² approach as outlined in
section 5.2, how much additional specification work will be required in
your opinion to augment RHC to support this. I only ask because it appears
we may be going down a path of ³in order to build this protocol, we need
to augment and modify a whole bunch of other stuff², which only further
delays our end goal here.

That¹s it for now. Thanks!

Stefan Fouant
JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP
Senior Security Engineer
Corero Network Security
Mobile: +1.703.625.6243

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 4 Feb 2016 11:06:58 -0500

Thank you for reading my draft and thinking about actually transporting 
DOTS messages.

This is the first draft, mostly my own writing, and I already have some 
private messages with editorial changes which will add a co-author.

> intentionally or unintentionally blocks, so let¹s move forwardŠ

I 'was there' when the European network operators were ready to block 
the CuCme UDP port as it was consuming all their network capacity, but 
some smart people figured out RED and a developer pushed the code out to 
all the routers that night.  I doubt we will see that again any time soon.

UDP will always be watched and blocked whenever someone gets an itch 
until someone else figures out 'a better way'.  Best if we stay off that 
bus.

> goal we had of being able to fit DOTS messages into an MTU of 1476 bytes

CMAC as the mode-of-operation is what I would specify once we get to 
that layer.  And SSE is kind of open to other formats.  But I am 
interested in any pointers to concerns about AEAD as the way I read the 
modes, it IS part of the MAC (or MIC as the 802 people insist).

> trying to accomplish aboveŠ Just a thought.

I need to better understand 2890 and would like to be pointed to actual 
uses of it.  I read the RFC putting this together, but I could not see 
how the actual GRE payload was protected with it.

> delays our end goal here.

It could be an interesting piece of work.  Or....

I strongly suspect that there is an ethtype sitting around from the 'old 
days', and maybe still used that would allow for a session level (i.e. 
message) directly on the MAC without all that protocol cruft we know and 
love.  Then there would be a reasonable interface definition connected 
to the GRE interface for direct application messaging.  But there would 
not be any transport fragmentation support and you either rely on IP 
fragmentation, or you design to stay within the smallest MTU for IP (576?).

> JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP
And thank you.

---

From: Stefan Fouant <[email-masked]>
Date: Thu, 4 Feb 2016 21:15:44 +0000

>Thank you for reading my draft and thinking about actually transporting 

You are very welcome!

>until someone else figures out 'a better way'.  Best if we stay off that 

Agreed.

>modes, it IS part of the MAC (or MIC as the 802 people insist).

I guess what I’m really interested in, and open to hear other’s interpretation, is if confidentiality is strictly required for the data channel. Forcing AEAD seems a barrier to high for simple implementations, especially where simple authentication may do. 

In fact, in draft-ietf-dots-requirements-00, the definition of the signal channel states that it is "A bidirectional, mutually authenticated communication layer between DOTS agents”, however confidentiality doesn’t seem to be required or mentioned here.

Let us take a step back to the requirements draft and differentiate between the signal channel and the data channel. Is it your intent to use draft-moskowitz-dots-gre-00.txt to meet one or the other, or both? From the description, it provides the confidentiality that the data channel would require, but not the reliable transport piece that would be required in order for DOTS agents to detect data delivery success/failure.

>how the actual GRE payload was protected with it.

I was simply thinking that 2890 could be reused to an extent, to provide for a simple hash for auth and sequence number to prevent replay. I admit though I haven’t given it diligent though, more thinking out loud.

>fragmentation, or you design to stay within the smallest MTU for IP (576?).

We definitely don’t want to fragment packets - if we’re having difficulty getting even single packets out, let’s not exacerbate the situation. ;)  And 576 Bytes seems too small for all the telemetry needed.

Stefan Fouant

---

From: Gilbert Clark <[email-masked]>
Date: Fri, 5 Feb 2016 11:36:09 -0500

I haven't really had time to completely digest the draft as of yet, but 
two thoughts:

I think it'd make more sense to define transport-udp, transport-tcp, etc 
... and then define a *separate* draft (for which this document might be 
a good start) which explains how / why you might want to take those 
transports and push them through GRE.  I'm concerned, however, by the 
idea of including a *tunneling* mechanism in the specification for 
something intended to act as a *transport* ... I don't think these two 
things are the same.

Further, I believe that (at some point) there was discussion that 
different protocols might make sense in different cases.  As such, 
rather than focusing on why a specific protocol is better than others 
(which tends to be contentious, based on experiences that tend to vary, 
and becomes less relevant as time passes and things change), it might be 
more productive to focus exclusively on use-cases for which the proposed 
solution would be well-suited ("In the case UDP is blocked from point A 
to point B, tunneling UDP traffic through GRE might be a solution ...").

-Gilbert

On 02/03/2016 08:09 AM, Robert Moskowitz wrote:
> I offer this draft to DOTS as a solid approach to meet the 
> requirements for the underlying transport mechanism for DOTS messaging.
>
> meeting.  And further request that our time slot NOT be Monday 
> morning.  Famlly activities (youngest son's wedding) result in my not 
> arriving until Monday.
>
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Stefan Fouant <[email-masked]>
Date: Fri, 5 Feb 2016 16:39:50 +0000

From: Dots <[email-masked]<mailto:[email-masked]>> on behalf of Gilbert Clark <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 5, 2016 at 11:36 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Dots] Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt

I haven't really had time to completely digest the draft as of yet, but two thoughts:

I think it'd make more sense to define transport-udp, transport-tcp, etc ... and then define a *separate* draft (for which this document might be a good start) which explains how / why you might want to take those transports and push them through GRE.  I'm concerned, however, by the idea of including a *tunneling* mechanism in the specification for something intended to act as a *transport* ... I don't think these two things are the same.

Further, I believe that (at some point) there was discussion that different protocols might make sense in different cases.  As such, rather than focusing on why a specific protocol is better than others (which tends to be contentious, based on experiences that tend to vary, and becomes less relevant as time passes and things change), it might be more productive to focus exclusively on use-cases for which the proposed solution would be well-suited ("In the case UDP is blocked from point A to point B, tunneling UDP traffic through GRE might be a solution ...").

-Gilbert

I do agree that at one point we discussed having both TCP and UDP (in fact it’s mentioned in the requirements draft), and potentially using something like the Happy Eyeballs mechanism to flip between one and the other. Perhaps the GRE approach could be a third option (as a last resort).

Stefan Fouant

---

From: Gilbert Clark <[email-masked]>
Date: Fri, 5 Feb 2016 12:50:57 -0500

> I do agree that at one point we discussed having both TCP and UDP (in 
> fact it’s mentioned in the requirements draft), and potentially using 
> something like the Happy Eyeballs mechanism to flip between one and 
> the other. Perhaps the GRE approach could be a third option (as a last 
> resort).
>

My apologies if this seems pedantic, but I do believe the pedantry is 
warranted in this case.

To be clear, my argument is that the conversation about whether to use 
TCP or UDP for DOTS traffic is (theoretically) orthogonal to the 
conversation about whether or not to tunnel said traffic through GRE.  
In other words, I see two independent topics of conversation here:

* when to use TCP and when to use UDP
* when to use GRE and when not to use GRE

Both of these items, I think, warrant separate drafts.

This draft, in my opinion, seems like it might be suited to be a 
candidate for the latter.

Cheers,
Gilbert

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 5 Feb 2016 13:06:49 -0500

I did not put this in my draft, and maybe I should.  I did not select 
GRE as much as down-selected the IETF transport protocols over IP using

http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

My working list was:

ICMP
TCP
UDP
GRE
ESP
AH
L2TP
SCTP
ROHC

Note how short the list is.

I was searching for an IP protocol that:

Is stateless
May offer security services
Commonly supported within current OSs
Not an effective DDoS vector against common servers (i.e. not typically 
used by them)
low byte overhead
(There may have been some other thoughts, but not thinking of them right 
now)

I kept sqeezing out all but GRE and ESP.  L2TP kind of hung around a 
bit, and is still intersting, but GRE and L2TP are a bit of a tossup, so 
I stayed with GRE.

I DO explain why I hold GRE is better than ESP.  Principally to move the 
security context up the stack to reduce fate-sharing.

Now given this, we can define YA transport that fits our needs.  But 
then we would need to get it supported in the OSs.  Thus I stayed with GRE.

I really did not want tunneling so much as not UDP or TCP.  The cost was 
tunneling.

If people feel there is value, I can put this thought process into the 
draft.

And I am still thinking of getting a ethtypefor GRE that directly 
supports ROHC and then squeeze the ____ out of the headers...

On 02/05/2016 11:36 AM, Gilbert Clark wrote:
> I think it'd make more sense to define transport-udp, transport-tcp, 
> etc ... and then define a *separate* draft (for which this document 
> might be a good start) which explains how / why you might want to take 
> those transports and push them through GRE.  I'm concerned, however, 
> by the idea of including a *tunneling* mechanism in the specification 
> for something intended to act as a *transport* ... I don't think these 
> two things are the same.
>
> (which tends to be contentious, based on experiences that tend to 
> vary, and becomes less relevant as time passes and things change), it 
> might be more productive to focus exclusively on use-cases for which 
> the proposed solution would be well-suited ("In the case UDP is 
> blocked from point A to point B, tunneling UDP traffic through GRE 
> might be a solution ...").
>
> -Gilbert
>

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 5 Feb 2016 13:11:50 -0500

On 02/05/2016 12:50 PM, Gilbert Clark wrote:
>> the other. Perhaps the GRE approach could be a third option (as a 
>> last resort).
>>
>

I actually do not see the need for this approach for the control plane 
that uses TCP and TLS.  Though, again, I think thought is needed into 
the control plane to determine if it is truly Client/Server and RESTful, 
or it too is a peer protocol where the DOTS server can be pushing 
configuration information to the DOTS clients.  If so, the TLS is a bit 
of a challenge, but not impossible.

My focus is on the DOTS messages which we pretty much agree need a 
stateless, uni-directional (i.e. no manditory ack) transport.

---

From: Gilbert Clark <[email-masked]>
Date: Sat, 6 Feb 2016 03:48:16 -0500

Hi:

I really don't think this addresses the comments I had.

With that said, more inline:

>
> I DO explain why I hold GRE is better than ESP.  Principally to move 
> the security context up the stack to reduce fate-sharing.
>

Two comments:

* There should be an understanding that, regardless of how awesome GRE 
might be in this context, it still won't preclude someone else's need 
for e.g. IPSEC support down the road.
* Regardless of how great GRE might (or might not) be for getting DOTS 
messages from point A to point B, GRE cannot operate in isolation.  In 
other words ...

> I really did not want tunneling so much as not UDP or TCP.  The cost 
> was tunneling.

... I really don't understand how the definition / existence of a GRE 
tunnel would obviate the need to define a way to send DOTS messages via 
some kind of real transport such as UDP or TCP.

As such, the statement above really makes no sense to me at all ...

-Gilbert

---

From: Barry Raveendran Greene <[email-masked]>
Date: Sat, 6 Feb 2016 16:54:24 +0800

Two key challenges:

1. What is being described is NOT GRE. It is a modification built on GRE

2. I don’t see you code this in hardware. 

Get someone to write some prototype code and see if this would even work.

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 06 Feb 2016 17:26:47 +0700

> requirements for the underlying transport mechanism for DOTS 

1.	Large, hardware-based routers and switches often either don't support 
GRE at all, or don't support it in hardware.  If it isn't supported in 
hardware, then it's a non-starter in terms of deployment.  It is 
important that both the stateful and stateless transports utilized for 
DOTS are potentially supportable by all classes of network 
infrastructure devices for DOTS supplicant, relay, and server roles.

2.	One of the important elements of DOTS is the ability for a supplicant 
to register dynamically during an attack, as long as the correct 
authentication parameters are utilized (likely obtained an out-of-band 
call to ISP or MSSP support desk, or similar process).  The requirement 
to set up a GRE tunnel, which must be provisioned on both ends, 
precludes this important capability.

3.  Contrary to what's asserted in this draft, there are often issues 
with GRE traversal of NATs.  It isn't universally supported.

4.	GRE adds encapsulation overhead.  This isn't desirable.  It cannot be 
assumed that ROHC will be supported on either the relevant endpoints or 
in intervening devices such as firewalls, load-balancers, NATs, etc.  
Developing a bespoke compression mechanism as posited in this draft is 
fraught with such concerns, as well as being unnecessary.

5.	GRE is often blocked at the edges of endpoint networks and/or 
northbound of the location of potential DOTS supplicants.

6.	The use of an encapsulation technology like GRE appears to add 
unnecessary complexity to the DOTS communications model without any 
apparent benefit; this is apart from abovementioned concerns regarding 
encapsulation overhead and various proposed compression schemes.

7.	The statements in this draft which imply that ISPs routinely block 
UDP are incorrect.  There is some UDP policing going on to sink UDP 
reflection/amplification traffic on the network edges of some large 
transit networks, but it is generally for specific UDP port-pair 
combinations, and is not all-encompassing.  Most iatrogenic UDP blocking 
takes place on endpoint networks (mainly enterprises); those same 
networks also often block GRE, and indeed anything other than TCP, some 
UDP, and some ICMP (and they often overblock both UDP and ICMP).  ISPs 
generally do not like being in the business of enforcing network access 
policies, as this is contrary to their business models and almost always 
results in customer dissatisfaction, unsustainable levels of help-desk 
calls and trouble tickets, and customer churn.

8.	The statement in this draft which implies that the use of GRE somehow 
would increase the resiliency of DOTS clients to DDoS attack is 
incorrect.  It also does not take into account well-known operational 
BCPs such as iACL deployments at network edges.

9.	The statement in this draft which implies that DOTS servers (or 
relays) should have foreknowledge of the existence of DOTS clients is 
incorrect (see #2 above).

10.	Given the above concerns, plus the fact that multiple, well-known, 
viable potential DOTS transport mechanisms already exist, I request that 
prior discussion of this draft take place on-list and possibly via a 
conference call before any decision is made about its inclusion in the 
DOTS IETF 95 session.

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

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 6 Feb 2016 20:04:24 -0500

I wonder what happens to a receiver that gets a great packet which is not
some encapsulated innerpacket.

GRE support exists 'everywhere' onlynin the context of 'decap and forward'
(or encap).  I think you are asking for a user space daemon to
capture/parse/etc or create raw packets? This seems prone to badness.

Why is tcp or UDP bad here? (I need to go read your reasoning)

---

From: Stefan Fouant <[email-masked]>
Date: Mon, 8 Feb 2016 13:48:45 +0000

Sorry for the top post (on cell).

I think the reasoning for suggesting UDP was bad was that Robert said UDP is typically blocked on inbound. To be honest, this has not been my experience at all. My observations are that I have rarely seen *all* UDP blocked and typically *if* anything is blocked inbound, it's generally in the form of an ACL which is only blocking a particular source or dest port.

Stefan

Sent from my iPhone

On Feb 8, 2016, at 6:00 AM, Christopher Morrow <[email-masked]<mailto:[email-masked]>> wrote:

I wonder what happens to a receiver that gets a great packet which is not some encapsulated innerpacket.

GRE support exists 'everywhere' onlynin the context of 'decap and forward' (or encap).  I think you are asking for a user space daemon to capture/parse/etc or create raw packets? This seems prone to badness.

On Feb 6, 2016 3:55 AM, "Barry Raveendran Greene" <[email-masked]<mailto:[email-masked]>> wrote:

Two key challenges:

_______________________________________________
Dots mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dots
_______________________________________________
Dots mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dots

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 08 Feb 2016 20:52:41 +0700

On 8 Feb 2016, at 20:48, Stefan Fouant wrote:

> Robert said UDP is typically blocked on inbound.

Mainly on endpoint networks, enough to need a stateful alternative.

The case in the draft is overstated.  And GRE is often blocked on 
endpoint networks, too.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 8 Feb 2016 13:57:28 +0000

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
> Sent: Monday, February 08, 2016 7:23 PM
> To: dots
> Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-
> moskowitz-dots-gre-00.txt
> 

Yup, and the firewall also typically includes configuration to permit UDP traffic to well-known destinations (SIP proxies, B2BUA, Media distribution devices etc.). I have not seen any customer blocking media streams for business calls to run over UDP and force the media streams to run over TCP.

-Tiru

> 
> The case in the draft is overstated.  And GRE is often blocked on endpoint
> networks, too.
>

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 8 Feb 2016 09:35:53 -0500

> Yup, and the firewall also typically includes configuration to permit UDP traffic to well-known destinations (SIP proxies, B2BUA, Media distribution devices etc.). I have not seen any customer bloc…

ok, so ... I've seen messages from Cameron and Jared talking about
(paraphrased, they both say it differently/better then me): "udp is
bad, we are/will/currently block udp"

In some cases the 'we will block udp' is implied: "all" though I
haven't seen that actually be the case, yet. Having a TCP as well as
UDP option seems fine, both would follow normal protocol stack
handling on the src/dest systems for a DOTS communication.

Trying to shoehorn in GRE without actually doing gre tunneling (just
using the header) is going to cause problems with adoption,
deployment, debugging, etc... You'd have to sideline all GRE
processing (at least for your expected DOTS conversations) and handle
it all as user-space work... I think. That is going to end poorly :(

If you're going to go the 'just use gre' as a header ... why not just
use IP bare? or SCTP?

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 08 Feb 2016 21:40:36 +0700

> bad, we are/will/currently block udp"

They don't *block all UDP* - they police down port-pairs and/or 
per-dest-IP.  If they blocked all UDP, they'd lose all their customers.

;>

> use IP bare?

Firewall rules, ACLs, NATs, et. al.

> or SCTP

This makes much more sense than GRE (or pseudo-GRE), but still has 
supportability/prevalence issues.

---

From: Jared Mauch <[email-masked]>
Date: Mon, 8 Feb 2016 09:45:11 -0500

> On Feb 8, 2016, at 9:40 AM, Roland Dobbins <[email-masked]> wrote:
> 
>> ok, so ... I've seen messages from Cameron and Jared talking about (paraphrased, they both say it differently/better then me): "udp is
> They don't *block all UDP* - they police down port-pairs and/or per-dest-IP.  If they blocked all UDP, they'd lose all their customers.
> 
> ;>

Depends on which customers you are talking about ;)

There is something interesting here about the path we have seen of pushing everything to be TCP/{80,443}.  In IPv4 traffic, we see a variety of ports/protocols, etc.. but in IPv6 land my stats are clearly ‘TCP giant’ with some UDP/53 for DNS.

For what are we blocking/policing, we have specific UDP ports that are prone to abuse that are rate-limited to a percentage of the edge link speed today.  I do wish I could set it to sub-1% on some platforms, as a 400G link can let a lot of attack traffic through on ingress, and if you have multiple ingress paths and police on ingress, the egress can be 6x that 1%.

- Jared

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 08 Feb 2016 21:48:00 +0700

> Depends on which customers you are talking about ;)

heh, true.

> For what are we blocking/policing, we have specific UDP ports that are 
> prone to abuse that are rate-limited to a percentage of the edge link 
> speed today.

Thanks for the clarification - much appreciated!

---

From: Gilbert Clark <[email-masked]>
Date: Mon, 8 Feb 2016 10:38:30 -0500

> Firewall rules, ACLs, NATs, et. al.

 From a design perspective, this is also a terrible idea.  UDP exists as 
a transport-level way to run data across things that are as close to raw 
IP datagrams as possible while maintaining the ability to address 
multiple applications independently.

I think it's probably best that we never speak of this idea again :)

> supportability/prevalence issues.

To be clear: I personally do not believe [1] that a draft describing the 
operation of DOTS over TCP should in any way preclude a separate draft 
describing the operation of DOTS over SCTP ... as long as the draft 
describing the operation of DOTS over SCTP happens after any TCP draft 
is created and adopted.

Getting back to the other point here, though: SCTP was designed to be a 
transport, and is therefore an option.  GRE was not, and therefore makes 
*no sense* as an option here.  It's not that GRE shouldn't be used as a 
transport, it's that GRE *can't* be used directly as a transport and 
still maintain its identity as a tunneling protocol.

In other words, a transport-capable GRE would be pseudo-GRE in the same 
way that an apple is a pseudo-orange.

If the point of this draft is indeed to add transport capability to GRE, 
then I'd suggest renaming both the draft and the protocol in a way that 
better describes its intended purpose ... with the caveat that I do not 
believe there is a need to define such a thing.

-Gilbert

[1] my opinions are only my own, and therefore represent neither the 
will of the chairs nor the consensus or intent of the working group as a 
whole.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 8 Feb 2016 16:20:56 +0000

Unfortunately SCTP has NAT/Firewall traversal problem, to overcome this WebRTC Data channels use SCTP over DTLS over UDP https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13.

-Tiru

> From: Dots [mailto:[email-masked]] On Behalf Of Gilbert Clark
> Sent: Monday, February 08, 2016 9:09 PM
> To: [email-masked]
>  From a design perspective, this is also a terrible idea.  UDP exists as a
> transport-level way to run data across things that are as close to raw IP
> datagrams as possible while maintaining the ability to address multiple
> applications independently.
> 
> describing the operation of DOTS over SCTP ... as long as the draft describing
> the operation of DOTS over SCTP happens after any TCP draft is created and
> adopted.
> 
> transport, it's that GRE *can't* be used directly as a transport and still
> maintain its identity as a tunneling protocol.
> 
> If the point of this draft is indeed to add transport capability to GRE, then I'd
> suggest renaming both the draft and the protocol in a way that better
> describes its intended purpose ... with the caveat that I do not believe there
> is a need to define such a thing.
> 
> -Gilbert
> 
> [1] my opinions are only my own, and therefore represent neither the will of
> the chairs nor the consensus or intent of the working group as a whole.
>

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 8 Feb 2016 17:08:08 -0800

Can we back up to protocol requirements?  I expect lots of protocols can already meet most requirements, but without agreement on the protocol requirements, we will keep talking past each other with solutions.

-d

On 05-Feb-2016 10:06 am, Robert Moskowitz <[email-masked]> wrote: 
> I did not put this in my draft, and maybe I should.  I did not select GRE as much as down-selected the IETF transport protocols over IP using
> 
> http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml <http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml>
> 
> My working list was:
> 
> ICMP
> TCP
> UDP
> GRE
> ESP
> AH
> L2TP
> SCTP
> ROHC
> 
> Not an effective DDoS vector against common servers (i.e. not typically used by them)
> low byte overhead
> (There may have been some other thoughts, but not thinking of them right now)
> 
> I kept sqeezing out all but GRE and ESP.  L2TP kind of hung around a bit, and is still intersting, but GRE and L2TP are a bit of a tossup, so I stayed with GRE.
> 
> I DO explain why I hold GRE is better than ESP.  Principally to move the security context up the stack to reduce fate-sharing.
> 
> Now given this, we can define YA transport that fits our needs.  But then we would need to get it supported in the OSs.  Thus I stayed with GRE.
> 
> I really did not want tunneling so much as not UDP or TCP.  The cost was tunneling.
> 
> If people feel there is value, I can put this thought process into the draft.
> 
> And I am still thinking of getting a ethtypefor GRE that directly supports ROHC and then squeeze the ____ out of the headers...
> 
>>> I offer this draft to DOTS as a solid approach to meet the requirements for the underlying transport mechanism for DOTS messaging.
>>> 
>>> I request a time slot to present and discuss this at the upcoming meeting.  And further request that our time slot NOT be Monday morning.  Famlly activities (youngest son's wedding) result in my not arriving until Monday.
>>> 
>>> 
>>> From:	[email-masked] <mailto:[email-masked]>
>>> To:	Jinwei Xia <[email-masked]> <mailto:[email-masked]>, Robert Moskowitz <[email-masked]> <mailto:[email-masked]>
>>> 
>>> URL:            https://www.ietf.org/internet-drafts/draft-moskowitz-dots-gre-00.txt <https://www.ietf.org/internet-drafts/draft-moskowitz-dots-gre-00.txt>
>>> Status:         https://datatracker.ietf.org/doc/draft-moskowitz-dots-gre/ <https://datatracker.ietf.org/doc/draft-moskowitz-dots-gre/>
>>> Htmlized:       https://tools.ietf.org/html/draft-moskowitz-dots-gre-00 <https://tools.ietf.org/html/draft-moskowitz-dots-gre-00>
>>> 
>>> 
>>> Abstract:
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/dots <https://www.ietf.org/mailman/listinfo/dots>
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dots <https://www.ietf.org/mailman/listinfo/dots>
>

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 10 Feb 2016 05:12:11 +0700

On 9 Feb 2016, at 8:08, 🔓Dan Wing wrote:

> Can we back up to protocol requirements?

Concur 100%.  Cart-before-horse, here - and kind of an odd-looking cart, 
at that.

;>

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 10 Feb 2016 05:16:03 +0700

On 8 Feb 2016, at 22:38, Gilbert Clark wrote:

> If the point of this draft is indeed to add transport capability to 
> GRE, then I'd suggest renaming both the draft and the protocol in a 
> way that better describes its intended purpose ... with the caveat 
> that I do not believe there is a need to define such a thing.

Concur 100% with all your comments.

And it should also be done in the least-inappropriate WG - which is not 
DOTS, heh.

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 10 Feb 2016 05:17:23 +0700

On 8 Feb 2016, at 23:20, Tirumaleswar Reddy (tireddy) wrote:

> Unfortunately SCTP has NAT/Firewall traversal problem

Yes, we're on the same page, here.  The point is that even with its 
support-prevalence issues, SCTP makes more sense than GRE (or 
pseudo-GRE).

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 10 Feb 2016 05:18:46 +0700

> supports ROHC and then squeeze the ____ out of the headers...

This sort of thing is way beyond the scope of the DOTS WG, IMHO.