Subject: Re: [Dots] FW: New Version Notification for draft-reddy-dots-transport-02.txt

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 19 Feb 2016 07:31:54 +0000

> -----Original Message-----
> From: gclark mti-systems.com [mailto:[email-masked]]
> Sent: Wednesday, February 17, 2016 7:25 PM
> To: Tirumaleswar Reddy (tireddy); [email-masked]
> Subject: Re: [Dots] FW: New Version Notification for draft-reddy-dots-
> transport-02.txt
> 
> Hi!
> 
> Further comments inline:
> 
> > On February 17, 2016 at 3:06 AM "Tirumaleswar Reddy (tireddy)"
> > <[email-masked]> wrote:
> >
> >
> > Hi Gilbert,
> >
> > Thanks for the review, Please see inline
> >
> > > -----Original Message-----
> > > From: Dots [mailto:[email-masked]] On Behalf Of Gilbert Clark
> > > Sent: Wednesday, February 10, 2016 3:53 PM
> > > To: [email-masked]
> > > Subject: Re: [Dots] FW: New Version Notification for
> > > draft-reddy-dots- transport-02.txt
> > >
> > >
> > > On 02/09/2016 11:16 PM, Tirumaleswar Reddy (tireddy) wrote:
> > > > Hi all,
> > > >
> > > > This update to the draft includes the following changes.
> > > >
> > > > * Proposes HappyEyeballs mechanism to convey DOTS signal
> > > > * Addresses comments from the WG.
> > > > * (D)TLS protocol profile to reduce delay to convey DOTS signal
> > > >
> > > > Comments and suggestions are welcome.
> > >
> > > Hi:
> > >
> > > Just a few quick comments while skimming this draft.
> > >
> > > * Is running HTTP over UDP well-defined?  CoAP might be one
> > > candidate, and QUIC [1] might be another ... but those aren't really
> > > HTTP in the strictest sense of the word, are they?
> >
> > It's like COAP (runs over both TCP and UDP) and uses similar features of
> HTTP.
> > We may end up using COAP itself, but the basic idea here was to use a
> > signaling mechanism that would look the same over UDP and TCP to make
> > it easier on the DOTS client and server.
> >
> 
> Okay ... but I think this discussion is actually the core of a *transport*
> specification :)
> 
> > >
> > > * Generally, I'm not sure how I feel about mixing message model with
> > > specifications regarding how the model should be transmitted.  In my
> > > opinion, sections such as:
> > >
> > >    {
> > >       "policy-id": number,
> > >       "target-ip": string,
> > >       "target-port": string,
> > >       "target-protocol": string,
> > >     }
> > >
> > > would be best defined in a separate draft, since there are *all
> > > kinds* of ways to get that data from point A to point B ... not all
> > > of which involve GET, POST, PUT, or DELETE.
> >
> > Agreed. As you know L7 protocol for DOTS signal is not finalized. Once
> > the WG agrees to use this proposed mechanism, we can then discuss
> > whether to define these parameters in this draft or a separate draft.
> 
> Sure ... but I think that defining and agreeing to a transport *first*
> approaches the problem backwards.  We should first define what we want to
> transport (the models and the associated verbs), *then* define how to map
> those actions onto a reasonable protocol.
> 
> With that said, it seems like this draft actually focuses more on the models
> and the associated actions than it does on *how* things are actually sent.  As
> such, it doesn't strike me as a transport draft so much as it is a specification
> of a more general DOTS model.  I think the inclusion of "-transport" in the
> title made me expect to find something in the document that I didn't, which I
> found to be confusing.
> 
> Thus, I think I'd be happier if the draft were renamed to suggest it focuses
> more specifically on defining models / verbs: using a REST vocabulary to
> define such things is fine, I think, and makes a great deal of sense if the
> expectation is that the folks implementing DOTS will be using something
> HTTP-like to transport messages back and forth.
> 
> A set of additional specifications could then focus on how to map those
> models and verbs to different protocols (e.g. HTTP 1.1, HTTP 2, CoAP, QUIC):
> these additional specifications would be "-transport" drafts of the form "-
> transport-http", "-transport-quic", "-transport-coap", etc.

Why is there need for different protocols ?
WG I guess has to discuss and pick one L7 protocol. HTTP 1.1 and HTTP 2 only run on TCP, QUIC only runs on UDP (and it's not yet standardized), CoAP can run over both UDP and TCP and running code is available.

> 
> >
> > >
> > > "To overcome these connection setup problems, the DOTS client MUST
> > > try connecting to the DOTS server using both IPv6 and IPv4, and MUST
> > > try both DTLS over UDP and TLS over TCP in a fashion similar to the
> > > "Happy Eyeballs" mechanism [RFC6555]."
> > >
> > > * I'm not sure that DTLS or TLS is "MUST" so much as a "SHOULD" ...
> > > but in the event that TLS or DTLS are not used, DOTS messages MUST
> > > be sent through a channel that guarantees integrity and
> > > confidentiality at one layer or another.
> >
> > We want to make it mandatory to meet the security requirements
> > discussed in
> > https://tools.ietf.org/html/draft-ietf-dots-requirements-00 for both
> > UDP and TCP.
> 
> Okay ... but the phrasing as it exists in the draft implies that *only* TLS or
> DTLS may *ever* be used to fulfill these security requirements.  
> I'm not
> convinced that this is the case, and therefore believe more generic phrasing
> could be appropriate here.  Someone can (and no doubt will :) correct me if
> I'm wrong, however.

DOTS agents must support one security mechanism for interoperability, don't see a need for multiple security mechanism to meet the requirements.

> 
> > > * Happy eyeballs seems like a pretty good idea, but what's the
> > > justification for making it a "MUST"?
> >
> > Transport selection for DOTS signal was presented in TSVWG WG at
> > IETF-94
> > http://www.ietf.org/proceedings/94/slides/slides-94-tsvwg-14.pdf and
> > discussed in the WG. The consensus was to use both UDP and TCP, and
> > Happy eyeballs mechanism will help reduce delay to convey DOTS signal.
> > DOTS requirement draft explains that connectionless transport is
> > strongly recommended and connection-oriented transport may be
> necessary due to network policy or middleware limitations.
> 
> I understand the consensus is to support both TCP and UDP.  That makes
> sense.
> 
> With that said, I'm not sure that a *discovery mechanism* (or the happy
> eyeballs mechanism specifically) should necessarily be mandatory in all
> cases.  In cases where the properties of the link are known (e.g. I'm not
> shooting DOTS notification through the link that's under attack, but instead
> through a different / dedicated link that e.g. uses IPSEC to communicate with
> an upstream provider that can help me defend), I don't think it makes as
> much sense to force auto-discovery in that manner.  Additionally, if happy
> eyeballs is explicitly required by the document, only happy eyeballs may
> *ever* be used by implementations that wish to strictly conform to the DOTS
> specification.
> 
> Further, the selection (or not) of happy eyeballs does not affect how
> implementations inter-operate with each other, and therefore isn't
> necessarily something that needs to be strictly enforced in order to build an
> implementation of DOTS that conforms with this draft.  It *is* generally a
> good idea ... but from a philosophical standpoint, I'm personally opposed to
> the idea of *forcing* any specific decisions upon those implementing the
> protocol without a very good reason to do so.  This is especially true in cases
> where there is a chance that such a mandate may lead to suboptimal
> performance.

Got it, will change to non-normative.

-Tiru

> 
> Cheers,
> Gilbert
> 
> [1] Quoting section 3 of RFC 7540: "An HTTP/2 connection is an application-
> layer protocol running on top of a TCP connection ([TCP]).  The client is the
> TCP connection initiator."

---

From: Barry Raveendran Greene <[email-masked]>
Date: Fri, 19 Feb 2016 15:35:12 +0800

Are we over thinking the problem?

The worry is getting message upstream in a DoS. That is NOT a protocol problem. That is a queuing problem.

---

From: "gclark mti-systems.com" <[email-masked]>
Date: Fri, 19 Feb 2016 10:13:36 -0500 (EST)

Hi!

> Why is there need for different protocols ?

See below ...

> 
> DOTS agents must support one security mechanism for interoperability, don't
> see a need for multiple security mechanism to meet the requirements.

Generally, I believe it is important for the standard to allow users to select a
sane protocol and security mechanism based on the environment in which DOTS is
being implemented and / or deployed.  I also believe it is important to allow
users to standardize new protocols and security mechanisms without having to
rewrite core sections of the DOTS specifications.  

DOTS lacks the ability to see into the future, so I believe anything we can
*reasonably* do to make these standards more flexible would be appreciated in
the years to come.  Thus, I think the appropriate question here is not "why
should we support multiple security mechanisms?", but instead "why should only
*these specific* security mechanisms ever be used?"

Cheers,
Gilbert

---

From: "gclark mti-systems.com" <[email-masked]>
Date: Sat, 20 Feb 2016 14:33:19 -0500 (EST)

> problem. That is a queuing problem. 

This is a really general comment that I don't feel like I entirely comprehend,
but I'll try to address it anyway (albeit in a rambling way) ...

It's both, I think.  The way I see it, the queuing problem is going to inform
the properties of the logical link (read: delay and loss) between the victim and
its upstream provider, but the protocol problem is going to inform how
efficiently you use the capacity of whatever type of logical link you have
available to you *after* the queuing problem has finished with it (read: in the
case of DoS, queuing has mauled the link and left it for dead by the side of the
road).

In our case, I think the queuing problem is here to stay *unless* we find a
reliable way to route DOTS traffic through the internet in a way that avoids the
links that are affected by an attack.  Given that, per the DOTS requirements, we
are forced to assume that *nothing* has been provisioned before we attempt to
signal we need help with a DoS currently in progress, I can not think of a way
to actually solve the queuing problem in a meaningful way *until* we've
established communication with the upstream provider.

Thus, in order to most efficiently respond during the initial phase of an
attack, we need to identify and select a protocol that is capable of operation
in conditions where there might be large burst loss, huge queuing delays, etc
... which means that, to maximize the chance of eventual delivery, we would want
to keep packets small and keep packets simple (no fancy headers and the like).

Beyond those two goals, I'm not convinced there is (or necessarily ever really
should be) one specific DOTS protocol to rule them all.  HTTP (and protocols
like it) can be popular because things are easy to understand and to implement,
but that doesn't mean something else couldn't work as well.  For example, IPFIX,
SNMP, possibly DNS ... just about anything expressive enough to encode and
transmit a DOTS alert model from point A to point B could be used.

In other words: we're not designing DOTS to solve DDoS, we're designing DOTS to
help people coordinate a response to an attack.  Leaving as much up to the
responders and the developers as is practical would be a win, I think.  The
point is to use DOTS to improve and support automation capabilities *where it
makes sense*, which might be different in each environment ... which means that
rather than try to build one incredible protocol that does all kinds of clever
(and complex) tricks to work around or through DoS, it might simply be better to
define a very simple model upon which everyone agrees, then give developers the
freedom to rapidly implement DOTS-compatible models in formats that make sense
for the specific environment into which DOTS is being deployed.

As long as the developers' implementations are documented, they can be codified
as standards that, when implemented, will allow DOTS-compliant systems across
different domains to inter-operate, assuming both are able to agree on a message
format they can understand.  

The only thing DOTS should be responsible for, in my opinion, is a set of
DOTS-compatible reference transports (that a provider *must* support) which can
be used to transport a DOTS model from point A to point B.  One of these
references should be based on TCP, and the other should be based on UDP.

Cheers,
Gilbert