Re: [Dots] FW: I-D Action: draft-teague-dots-protocol-00.txt

["Mortensen, Andrew" <[e-mail]>]

Thanks, Gilbert. I appreciate the comments. See inline below.

On Nov 15, 2016, at 8:51 PM, Gilbert Clark <[e-mail]<mailto:[e-mail]>> wrote:

Just now getting around to a quick read through this.  A few thoughts:

* I found the reference to protobufs in the document to be rather strange.  I'm not sold on the idea of a tight coupling between a document and a specific serialization library, no matter how convenient / awesome the library might be.  I guess protobuf3 might reference a specific implementation of protobuf, so it would *kind of* count as a protocol assuming a specific definition existed someplace which could be referenced, but still ... why use that instead of something more common that might be easier for others to read and understand offhand?

I think it’s entirely reasonable to be uneasy about tying a standard to a specific library. The good news is that protobufs isn’t a library, it’s an IDL. We felt protobufs makes a good choice as the IDL for DOTS due its compact wire representation, its support for backward-compatible schema versioning, its language neutrality, and its extensibility. For what it’s worth, Google’s recent effort to standardize gRPC within the IETF mentions protobuf as the IDL, though so far it hasn’t been made a requirement (see <https://tools.ietf.org/html/draft-talwar-rtgwg-grpc-use-cases-00#section-2.2.5>).

Can you describe what you’re thinking of as “more common” and “easier to read” here? We specifically avoided JSON and the like because of the wasted bytes in the serialization.

* The port is 4646, which is "(the hex value for the ASCII character "." twice)"  Why is this relevant?

It’s a weak joke (made weaker by the fact that its the *decimal* and not hex value).

Python 2.7.10 (default, Oct 23 2015, 19:19:21)
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.pack("BB", 46, 46)
'..’  <---- DOTS

/rimshot

That does remind me the draft needs an IANA Considerations section for port registration.

* 4.3.3 - "The DOTS client may send repeated requests until it receives a suitable response from the DOTS server by which it may interpret successful receipt."  Rate control is needed here.

Yes, this needs clarification. We’ll update it for the -01 draft.

* I'd argue for an explanation of how often the client needs to perform specific actions, but also how frequently the server should expect to receive those notifications from the client.  Since the environment can't be assumed to be terribly stable, I believe that it may be wise to assume that links are unstable and therefore explicitly enumerate how the most common failure modes should be addressed.

* I know the signaling protocol is intended to be relatively low overhead, but an explicit reference to congestion control in the general case might be useful.

Yes, will clarify.

* It's unusual to me to see endpoints in a protocol specification…. snip ...

* Really, the data channel has such an unbelievably tight binding to HTTP (or REST in general) that I think this document could be a lot shorter if the data section was simply a note that "The DOTS data channel uses HTTP (or a derivative thereof)", then add a reference to an external document with a supported list of endpoints that are listed as MUST, SHOULD, MAY, etc …

This seems like a very reasonable suggestion to me, thanks. I’m hoping further discussion about the use of RESTCONF with respect to DOTS will help set the direction this goes.

andrew



On Mon, Oct 31, 2016 at 5:19 PM, Teague, Nik <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

Please see the below referenced protocol draft.

We welcome feedback as always and hope that this draft may lead to some stimulating discussion both on-list and in Seoul.

Thanks,

-Nik

On 31/10/2016, 21:15, "I-D-Announce on behalf of [e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:


    A New Internet-Draft is available from the on-line Internet-Drafts directories.


            Title           : DDoS Open Threat Signaling Protocol
            Authors         : Nik Teague
                              Andrew Mortensen
        Filename        : draft-teague-dots-protocol-00.txt
        Pages           : 39
        Date            : 2016-10-31

    Abstract:
       This document describes Distributed-Denial-of-Service (DDoS) Open
       Threat Signaling (DOTS), a signaling protocol for requesting and
       managing mitigation of DDoS attacks.

       DOTS mitigation requests over the signal channel permit domains to
       signal the need for help fending off DDoS attacks, setting the scope
       and duration of the requested mitigation.  Elements called DOTS
       servers field the signals for help, and enable defensive
       countermeasures to defend against the attack reported by the clients,
       reporting the status of the delegated defense to the requesting
       clients.  DOTS clients additionally may use the data channel to
       manage filters and black- and white-lists to restrict or allow
       traffic to the clients' domains arbitrarily.

       The DOTS signal channel may operate over UDP [RFC0768] and if
       necessary TCP [RFC0793].  This revision discusses a transport-
       agnostic approach to this channel, focusing on the message exchanges
       and delegating transport specifics to other documents.  The DOTS data
       channel operates over HTTPS or a transport with similar reliability,
       interaction and security characteristics.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-teague-dots-protocol/

    There's also a htmlized version available at:
    https://tools.ietf.org/html/draft-teague-dots-protocol-00


    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<http://tools.ietf.org/>.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/

    _______________________________________________
    I-D-Announce mailing list
    [e-mail]<mailto:[e-mail]>
    https://www.ietf.org/mailman/listinfo/i-d-announce
    Internet-Draft directories: http://www.ietf.org/shadow.html
    or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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

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