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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 10 Feb 2016 04:16:59 +0000

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.

-Tiru

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, February 10, 2016 9:28 AM
To: Prashanth Patil (praspati); Dan Wing (dwing); Mike Geller (mgeller); Robert Moskowitz; Mohamed Boucadair; Tirumaleswar Reddy (tireddy)
Subject: New Version Notification for draft-reddy-dots-transport-02.txt

A new version of I-D, draft-reddy-dots-transport-02.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository.

Name:		draft-reddy-dots-transport
Revision:	02
Title:		Co-operative DDoS Mitigation
Document date:	2016-02-09
Group:		Individual Submission
Pages:		17
URL:            https://www.ietf.org/internet-drafts/draft-reddy-dots-transport-02.txt
Status:         https://datatracker.ietf.org/doc/draft-reddy-dots-transport/
Htmlized:       https://tools.ietf.org/html/draft-reddy-dots-transport-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-reddy-dots-transport-02

Abstract:
   This document discusses mechanisms that a DOTS client can use, when
   it detects a potential Distributed Denial-of-Service (DDoS) attack,
   to signal that the DOTS client is under an attack or request an
   upstream DOTS server to perform inbound filtering in its ingress
   routers for traffic that the DOTS client wishes to drop.  The DOTS
   server can then undertake appropriate actions (including, blackhole,
   drop, rate-limit, or add to watch list) on the suspect traffic to the
   DOTS client, thus reducing the effectiveness of the attack.

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: Gilbert Clark <[email-masked]>
Date: Wed, 10 Feb 2016 09:53:29 -0500

> 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?

* 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.

"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.
* Ways to minimize RTT and keep (D)TLS channels alive could be moved to 
a different section, I think.  It's nice to have a reference, but I 
don't know that it needs to be inline.
* Happy eyeballs seems like a pretty good idea, but what's the 
justification for making it a "MUST"?

-Gilbert

[1] https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 17 Feb 2016 08:06:20 +0000

Hi Gilbert,

Thanks for the review, Please see inline

> 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
> 
> 

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.

> 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.

> through a channel that guarantees integrity and confidentiality at one

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.

> don't know that it needs to be inline.

Sure, will move to a different section.

> 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.

-Tiru

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

---

From: "gclark mti-systems.com" <[email-masked]>
Date: Wed, 17 Feb 2016 13:24:53 -0500 (EST)

Hi!

Further comments inline:

> On February 17, 2016 at 3:06 AM "Tirumaleswar Reddy (tireddy)"
> <[email-masked]> wrote:
> 
> 
> Hi Gilbert,
> 
> 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 :)

> 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.

> 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.

> 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.

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."