From nobody Wed Feb 3 05:10:12 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826891A8A6E for ; Wed, 3 Feb 2016 05:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPt8tGowJ_wD for ; Wed, 3 Feb 2016 05:10:10 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6D3A1A8A67 for ; Wed, 3 Feb 2016 05:10:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id EEA5462156 for ; Wed, 3 Feb 2016 08:10:08 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7E0zjPgKH9Jj for ; Wed, 3 Feb 2016 08:09:53 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 14FBF62153 for ; Wed, 3 Feb 2016 08:09:53 -0500 (EST) To: dots@ietf.org From: Robert Moskowitz Message-ID: <56B1FC13.8060305@htt-consult.com> Date: Wed, 3 Feb 2016 08:09:39 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020301050700080406020403" Archived-At: Subject: [Dots] Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 13:10:11 -0000 This is a multi-part message in MIME format. --------------020301050700080406020403 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: internet-drafts@ietf.org To: Jinwei Xia , Robert Moskowitz 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 --------------020301050700080406020403 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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: internet-drafts@ietf.org
To: Jinwei Xia <xiajinwei@huawei.com>, Robert Moskowitz <rgm@htt-consult.com> 


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


--------------020301050700080406020403-- From nobody Wed Feb 3 05:10:23 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E901A8A10 for ; Wed, 3 Feb 2016 04:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6P3gmcGf7S01 for ; Wed, 3 Feb 2016 04:55:41 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4FC1A8A0F for ; Wed, 3 Feb 2016 04:55:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 005CF6214F for ; Wed, 3 Feb 2016 07:55:39 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Xl-XYSyb6v4D for ; Wed, 3 Feb 2016 07:55:33 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 801046214B for ; Wed, 3 Feb 2016 07:55:33 -0500 (EST) References: <20160203124844.9757.98048.idtracker@ietfa.amsl.com> To: dots@ietf.org From: Robert Moskowitz X-Forwarded-Message-Id: <20160203124844.9757.98048.idtracker@ietfa.amsl.com> Message-ID: <56B1F8C2.8090702@htt-consult.com> Date: Wed, 3 Feb 2016 07:55:30 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160203124844.9757.98048.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------050108000606030204070007" Archived-At: X-Mailman-Approved-At: Wed, 03 Feb 2016 05:10:17 -0800 Subject: [Dots] Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 12:55:43 -0000 This is a multi-part message in MIME format. --------------050108000606030204070007 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: internet-drafts@ietf.org To: Jinwei Xia , Robert Moskowitz 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 --------------050108000606030204070007 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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: internet-drafts@ietf.org
To: Jinwei Xia <xiajinwei@huawei.com>, Robert Moskowitz <rgm@htt-consult.com> 


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


--------------050108000606030204070007-- From nobody Thu Feb 4 06:56:42 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2541B30C7 for ; Thu, 4 Feb 2016 06:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QymPjArj7FJ1 for ; Thu, 4 Feb 2016 06:56:39 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1FC31B30C3 for ; Thu, 4 Feb 2016 06:56:39 -0800 (PST) Received: from [216.82.251.33] by server-11.bemta-12.messagelabs.com id 9B/E7-13240-6A663B65; Thu, 04 Feb 2016 14:56:38 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-6.tower-130.messagelabs.com!1454597797!15688737!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11467 invoked from network); 4 Feb 2016 14:56:38 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-6.tower-130.messagelabs.com with AES256-SHA encrypted SMTP; 4 Feb 2016 14:56:38 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0266.001; Thu, 4 Feb 2016 09:56:37 -0500 From: Stefan Fouant To: Robert Moskowitz , "dots@ietf.org" Thread-Topic: [Dots] Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt Thread-Index: AQHRX1w+0YOz+wZuhkSSxU3i+d9fWg== Date: Thu, 4 Feb 2016 14:56:36 +0000 Message-ID: References: <56B1FC13.8060305@htt-consult.com> In-Reply-To: <56B1FC13.8060305@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.67.200.208] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 14:56:42 -0000 From: Dots on behalf of Robert Moskowitz Date: Wednesday, February 3, 2016 at 8:09 AM To: "dots@ietf.org" Subject: [Dots] Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt >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. > > 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=B9m not sure I buy the whole =B3UDP gets blocked inbound=B2 argument, I=B9ve heard that mentioned a few times here on the list, but TBH that=B9s never been my experience in years of working in the DDoS space=8A 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=B9s move forward=8A 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=B9ve 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=B9s 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=B9s 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=B9re trying to accomplish above=8A Just a thought. With regards to the Robust Header Compression and its applicability towards the =B3GRE with compressed stack tunnel=B2 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 =B3in order to build this protocol, we need to augment and modify a whole bunch of other stuff=B2, which only further delays our end goal here. That=B9s 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 nobody Thu Feb 4 08:07:17 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB09C1B321F for ; Thu, 4 Feb 2016 08:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VA3n7_UgM62H for ; Thu, 4 Feb 2016 08:07:13 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD451B3225 for ; Thu, 4 Feb 2016 08:07:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 850A762183; Thu, 4 Feb 2016 11:07:10 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yfS9sFy5G1eU; Thu, 4 Feb 2016 11:07:01 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [161.253.2.240]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2FAF862182; Thu, 4 Feb 2016 11:07:01 -0500 (EST) To: Stefan Fouant , "dots@ietf.org" References: <56B1FC13.8060305@htt-consult.com> From: Robert Moskowitz Message-ID: <56B37722.4050906@htt-consult.com> Date: Thu, 4 Feb 2016 11:06:58 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dots] Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 16:07:16 -0000 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. On 02/04/2016 09:56 AM, Stefan Fouant wrote: > From: Dots on behalf of Robert Moskowitz > > Date: Wednesday, February 3, 2016 at 8:09 AM > To: "dots@ietf.org" > Subject: [Dots] Fwd: New Version Notification > for draft-moskowitz-dots-gre-00.txt > >> 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. >> >> > 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 '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. > 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. 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). > 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. 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. > 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. 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?). > 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 > > And thank you. From nobody Thu Feb 4 13:15:50 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CE61B29B8 for ; Thu, 4 Feb 2016 13:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpqMaVFvYody for ; Thu, 4 Feb 2016 13:15:47 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C893B1B29B7 for ; Thu, 4 Feb 2016 13:15:46 -0800 (PST) Received: from [216.82.242.179] by server-5.bemta-8.messagelabs.com id 19/11-09301-18FB3B65; Thu, 04 Feb 2016 21:15:45 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-13.tower-86.messagelabs.com!1454620545!15905801!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24197 invoked from network); 4 Feb 2016 21:15:45 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-13.tower-86.messagelabs.com with AES256-SHA encrypted SMTP; 4 Feb 2016 21:15:45 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0266.001; Thu, 4 Feb 2016 16:15:45 -0500 From: Stefan Fouant To: Robert Moskowitz , "dots@ietf.org" Thread-Topic: [Dots] Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt Thread-Index: AQHRX1w+0YOz+wZuhkSSxU3i+d9fWp8cYT8AgAACcwA= Date: Thu, 4 Feb 2016 21:15:44 +0000 Message-ID: References: <56B1FC13.8060305@htt-consult.com> <56B37722.4050906@htt-consult.com> In-Reply-To: <56B37722.4050906@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.67.200.208] Content-Type: text/plain; charset="utf-8" Content-ID: <93AB46F8DC76AA4AB2992E14DDF3AFC0@corero.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 21:15:48 -0000 T24gMi80LzE2LCAxMTowNiBBTSwgIlJvYmVydCBNb3Nrb3dpdHoiIDxyZ20tc2VjQGh0dC1jb25z dWx0LmNvbT4gd3JvdGU6DQoNCg0KDQo+VGhhbmsgeW91IGZvciByZWFkaW5nIG15IGRyYWZ0IGFu ZCB0aGlua2luZyBhYm91dCBhY3R1YWxseSB0cmFuc3BvcnRpbmcgDQo+RE9UUyBtZXNzYWdlcy4N Cg0KWW91IGFyZSB2ZXJ5IHdlbGNvbWUhDQoNCj5VRFAgd2lsbCBhbHdheXMgYmUgd2F0Y2hlZCBh bmQgYmxvY2tlZCB3aGVuZXZlciBzb21lb25lIGdldHMgYW4gaXRjaCANCj51bnRpbCBzb21lb25l IGVsc2UgZmlndXJlcyBvdXQgJ2EgYmV0dGVyIHdheScuICBCZXN0IGlmIHdlIHN0YXkgb2ZmIHRo YXQgDQo+YnVzLg0KDQpBZ3JlZWQuDQoNCj5DTUFDIGFzIHRoZSBtb2RlLW9mLW9wZXJhdGlvbiBp cyB3aGF0IEkgd291bGQgc3BlY2lmeSBvbmNlIHdlIGdldCB0byANCj50aGF0IGxheWVyLiAgQW5k IFNTRSBpcyBraW5kIG9mIG9wZW4gdG8gb3RoZXIgZm9ybWF0cy4gIEJ1dCBJIGFtIA0KPmludGVy ZXN0ZWQgaW4gYW55IHBvaW50ZXJzIHRvIGNvbmNlcm5zIGFib3V0IEFFQUQgYXMgdGhlIHdheSBJ IHJlYWQgdGhlIA0KPm1vZGVzLCBpdCBJUyBwYXJ0IG9mIHRoZSBNQUMgKG9yIE1JQyBhcyB0aGUg ODAyIHBlb3BsZSBpbnNpc3QpLg0KDQpJIGd1ZXNzIHdoYXQgSeKAmW0gcmVhbGx5IGludGVyZXN0 ZWQgaW4sIGFuZCBvcGVuIHRvIGhlYXIgb3RoZXLigJlzIGludGVycHJldGF0aW9uLCBpcyBpZiBj b25maWRlbnRpYWxpdHkgaXMgc3RyaWN0bHkgcmVxdWlyZWQgZm9yIHRoZSBkYXRhIGNoYW5uZWwu IEZvcmNpbmcgQUVBRCBzZWVtcyBhIGJhcnJpZXIgdG8gaGlnaCBmb3Igc2ltcGxlIGltcGxlbWVu dGF0aW9ucywgZXNwZWNpYWxseSB3aGVyZSBzaW1wbGUgYXV0aGVudGljYXRpb24gbWF5IGRvLiAN Cg0KSW4gZmFjdCwgaW4gZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0wMCwgdGhlIGRlZmlu aXRpb24gb2YgdGhlIHNpZ25hbCBjaGFubmVsIHN0YXRlcyB0aGF0IGl0IGlzICJBIGJpZGlyZWN0 aW9uYWwsIG11dHVhbGx5IGF1dGhlbnRpY2F0ZWQgY29tbXVuaWNhdGlvbiBsYXllciBiZXR3ZWVu IERPVFMgYWdlbnRz4oCdLCBob3dldmVyIGNvbmZpZGVudGlhbGl0eSBkb2VzbuKAmXQgc2VlbSB0 byBiZSByZXF1aXJlZCBvciBtZW50aW9uZWQgaGVyZS4NCg0KTGV0IHVzIHRha2UgYSBzdGVwIGJh Y2sgdG8gdGhlIHJlcXVpcmVtZW50cyBkcmFmdCBhbmQgZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIHRo ZSBzaWduYWwgY2hhbm5lbCBhbmQgdGhlIGRhdGEgY2hhbm5lbC4gSXMgaXQgeW91ciBpbnRlbnQg dG8gdXNlIGRyYWZ0LW1vc2tvd2l0ei1kb3RzLWdyZS0wMC50eHQgdG8gbWVldCBvbmUgb3IgdGhl IG90aGVyLCBvciBib3RoPyBGcm9tIHRoZSBkZXNjcmlwdGlvbiwgaXQgcHJvdmlkZXMgdGhlIGNv bmZpZGVudGlhbGl0eSB0aGF0IHRoZSBkYXRhIGNoYW5uZWwgd291bGQgcmVxdWlyZSwgYnV0IG5v dCB0aGUgcmVsaWFibGUgdHJhbnNwb3J0IHBpZWNlIHRoYXQgd291bGQgYmUgcmVxdWlyZWQgaW4g b3JkZXIgZm9yIERPVFMgYWdlbnRzIHRvIGRldGVjdCBkYXRhIGRlbGl2ZXJ5IHN1Y2Nlc3MvZmFp bHVyZS4NCg0KPkkgbmVlZCB0byBiZXR0ZXIgdW5kZXJzdGFuZCAyODkwIGFuZCB3b3VsZCBsaWtl IHRvIGJlIHBvaW50ZWQgdG8gYWN0dWFsDQo+dXNlcyBvZiBpdC4gIEkgcmVhZCB0aGUgUkZDIHB1 dHRpbmcgdGhpcyB0b2dldGhlciwgYnV0IEkgY291bGQgbm90IHNlZSANCj5ob3cgdGhlIGFjdHVh bCBHUkUgcGF5bG9hZCB3YXMgcHJvdGVjdGVkIHdpdGggaXQuDQoNCkkgd2FzIHNpbXBseSB0aGlu a2luZyB0aGF0IDI4OTAgY291bGQgYmUgcmV1c2VkIHRvIGFuIGV4dGVudCwgdG8gcHJvdmlkZSBm b3IgYSBzaW1wbGUgaGFzaCBmb3IgYXV0aCBhbmQgc2VxdWVuY2UgbnVtYmVyIHRvIHByZXZlbnQg cmVwbGF5LiBJIGFkbWl0IHRob3VnaCBJIGhhdmVu4oCZdCBnaXZlbiBpdCBkaWxpZ2VudCB0aG91 Z2gsIG1vcmUgdGhpbmtpbmcgb3V0IGxvdWQuDQoNCj5JIHN0cm9uZ2x5IHN1c3BlY3QgdGhhdCB0 aGVyZSBpcyBhbiBldGh0eXBlIHNpdHRpbmcgYXJvdW5kIGZyb20gdGhlICdvbGQgDQo+ZGF5cycs IGFuZCBtYXliZSBzdGlsbCB1c2VkIHRoYXQgd291bGQgYWxsb3cgZm9yIGEgc2Vzc2lvbiBsZXZl bCAoaS5lLiANCj5tZXNzYWdlKSBkaXJlY3RseSBvbiB0aGUgTUFDIHdpdGhvdXQgYWxsIHRoYXQg cHJvdG9jb2wgY3J1ZnQgd2Uga25vdyBhbmQgDQo+bG92ZS4gIFRoZW4gdGhlcmUgd291bGQgYmUg YSByZWFzb25hYmxlIGludGVyZmFjZSBkZWZpbml0aW9uIGNvbm5lY3RlZCANCj50byB0aGUgR1JF IGludGVyZmFjZSBmb3IgZGlyZWN0IGFwcGxpY2F0aW9uIG1lc3NhZ2luZy4gIEJ1dCB0aGVyZSB3 b3VsZCANCj5ub3QgYmUgYW55IHRyYW5zcG9ydCBmcmFnbWVudGF0aW9uIHN1cHBvcnQgYW5kIHlv dSBlaXRoZXIgcmVseSBvbiBJUCANCj5mcmFnbWVudGF0aW9uLCBvciB5b3UgZGVzaWduIHRvIHN0 YXkgd2l0aGluIHRoZSBzbWFsbGVzdCBNVFUgZm9yIElQICg1NzY/KS4NCg0KV2UgZGVmaW5pdGVs eSBkb27igJl0IHdhbnQgdG8gZnJhZ21lbnQgcGFja2V0cyAtIGlmIHdl4oCZcmUgaGF2aW5nIGRp ZmZpY3VsdHkgZ2V0dGluZyBldmVuIHNpbmdsZSBwYWNrZXRzIG91dCwgbGV04oCZcyBub3QgZXhh Y2VyYmF0ZSB0aGUgc2l0dWF0aW9uLiA7KSAgQW5kIDU3NiBCeXRlcyBzZWVtcyB0b28gc21hbGwg Zm9yIGFsbCB0aGUgdGVsZW1ldHJ5IG5lZWRlZC4NCg0KU3RlZmFuIEZvdWFudA0KSk5DSUUtU0VD LCBKTkNJRS1TUCwgSk5DSUUtRU5ULCBKTkNJLCBDSVNTUA0KU2VuaW9yIFNlY3VyaXR5IEVuZ2lu ZWVyDQpDb3Jlcm8gTmV0d29yayBTZWN1cml0eQ0KTW9iaWxlOiArMS43MDMuNjI1LjYyNDMNCg0K DQo= From nobody Fri Feb 5 08:36:14 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845C11B3B44 for ; Fri, 5 Feb 2016 08:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRcQft_zxbHP for ; Fri, 5 Feb 2016 08:36:11 -0800 (PST) Received: from atl4mhob07.myregisteredsite.com (atl4mhob07.myregisteredsite.com [209.17.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id 378031B320E for ; Fri, 5 Feb 2016 08:36:11 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u15Ga9Hj011050 for ; Fri, 5 Feb 2016 11:36:09 -0500 Received: (qmail 16715 invoked by uid 0); 5 Feb 2016 16:36:09 -0000 X-TCPREMOTEIP: 65.189.201.79 X-Authenticated-UID: gclark@mti-systems.com Received: from unknown (HELO localhost.localdomain) (gclark@mti-systems.com@65.189.201.79) by 0 with ESMTPA; 5 Feb 2016 16:36:09 -0000 To: dots@ietf.org References: <56B1FC13.8060305@htt-consult.com> From: Gilbert Clark Message-ID: <56B4CF79.8010505@mti-systems.com> Date: Fri, 5 Feb 2016 11:36:09 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56B1FC13.8060305@htt-consult.com> Content-Type: multipart/alternative; boundary="------------010101010804040002070001" Archived-At: Subject: Re: [Dots] Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 16:36:13 -0000 This is a multi-part message in MIME format. --------------010101010804040002070001 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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. > > 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: internet-drafts@ietf.org > To: Jinwei Xia , Robert Moskowitz > > > > > 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 > > > > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------010101010804040002070001 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit 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.

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: internet-drafts@ietf.org
To: Jinwei Xia <xiajinwei@huawei.com>, Robert Moskowitz <rgm@htt-consult.com> 


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







_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--------------010101010804040002070001-- From nobody Fri Feb 5 08:40:09 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7644D1B3B2C for ; Fri, 5 Feb 2016 08:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDg5CvA4pyA3 for ; Fri, 5 Feb 2016 08:39:53 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314CF1B3B44 for ; Fri, 5 Feb 2016 08:39:53 -0800 (PST) Received: from [216.82.241.211] by server-17.bemta-8.messagelabs.com id 08/D0-07885-750D4B65; Fri, 05 Feb 2016 16:39:51 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-13.tower-85.messagelabs.com!1454690391!23382063!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5439 invoked from network); 5 Feb 2016 16:39:51 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-13.tower-85.messagelabs.com with AES256-SHA encrypted SMTP; 5 Feb 2016 16:39:51 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0266.001; Fri, 5 Feb 2016 11:39:51 -0500 From: Stefan Fouant To: Gilbert Clark , "dots@ietf.org" Thread-Topic: [Dots] Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt Thread-Index: AQHRYDNW3mwGCxuz1ECPBTlLaQpeup8dp0IA Date: Fri, 5 Feb 2016 16:39:50 +0000 Message-ID: <8E3635E3-427A-4275-839B-3849CE3596F8@corero.com> References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> In-Reply-To: <56B4CF79.8010505@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.67.200.208] Content-Type: multipart/alternative; boundary="_000_8E3635E3427A4275839B3849CE3596F8corerocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 16:40:00 -0000 --_000_8E3635E3427A4275839B3849CE3596F8corerocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiBEb3RzIDxkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNlc0Bp ZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBHaWxiZXJ0IENsYXJrIDxnY2xhcmtAbXRpLXN5c3RlbXMu Y29tPG1haWx0bzpnY2xhcmtAbXRpLXN5c3RlbXMuY29tPj4NCkRhdGU6IEZyaWRheSwgRmVicnVh cnkgNSwgMjAxNiBhdCAxMTozNiBBTQ0KVG86ICJkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGll dGYub3JnPiIgPGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDog UmU6IFtEb3RzXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbW9za293 aXR6LWRvdHMtZ3JlLTAwLnR4dA0KDQpJIGhhdmVuJ3QgcmVhbGx5IGhhZCB0aW1lIHRvIGNvbXBs ZXRlbHkgZGlnZXN0IHRoZSBkcmFmdCBhcyBvZiB5ZXQsIGJ1dCB0d28gdGhvdWdodHM6DQoNCkkg dGhpbmsgaXQnZCBtYWtlIG1vcmUgc2Vuc2UgdG8gZGVmaW5lIHRyYW5zcG9ydC11ZHAsIHRyYW5z cG9ydC10Y3AsIGV0YyAuLi4gYW5kIHRoZW4gZGVmaW5lIGEgKnNlcGFyYXRlKiBkcmFmdCAoZm9y IHdoaWNoIHRoaXMgZG9jdW1lbnQgbWlnaHQgYmUgYSBnb29kIHN0YXJ0KSB3aGljaCBleHBsYWlu cyBob3cgLyB3aHkgeW91IG1pZ2h0IHdhbnQgdG8gdGFrZSB0aG9zZSB0cmFuc3BvcnRzIGFuZCBw dXNoIHRoZW0gdGhyb3VnaCBHUkUuICBJJ20gY29uY2VybmVkLCBob3dldmVyLCBieSB0aGUgaWRl YSBvZiBpbmNsdWRpbmcgYSAqdHVubmVsaW5nKiBtZWNoYW5pc20gaW4gdGhlIHNwZWNpZmljYXRp b24gZm9yIHNvbWV0aGluZyBpbnRlbmRlZCB0byBhY3QgYXMgYSAqdHJhbnNwb3J0KiAuLi4gSSBk b24ndCB0aGluayB0aGVzZSB0d28gdGhpbmdzIGFyZSB0aGUgc2FtZS4NCg0KRnVydGhlciwgSSBi ZWxpZXZlIHRoYXQgKGF0IHNvbWUgcG9pbnQpIHRoZXJlIHdhcyBkaXNjdXNzaW9uIHRoYXQgZGlm ZmVyZW50IHByb3RvY29scyBtaWdodCBtYWtlIHNlbnNlIGluIGRpZmZlcmVudCBjYXNlcy4gIEFz IHN1Y2gsIHJhdGhlciB0aGFuIGZvY3VzaW5nIG9uIHdoeSBhIHNwZWNpZmljIHByb3RvY29sIGlz IGJldHRlciB0aGFuIG90aGVycyAod2hpY2ggdGVuZHMgdG8gYmUgY29udGVudGlvdXMsIGJhc2Vk IG9uIGV4cGVyaWVuY2VzIHRoYXQgdGVuZCB0byB2YXJ5LCBhbmQgYmVjb21lcyBsZXNzIHJlbGV2 YW50IGFzIHRpbWUgcGFzc2VzIGFuZCB0aGluZ3MgY2hhbmdlKSwgaXQgbWlnaHQgYmUgbW9yZSBw cm9kdWN0aXZlIHRvIGZvY3VzIGV4Y2x1c2l2ZWx5IG9uIHVzZS1jYXNlcyBmb3Igd2hpY2ggdGhl IHByb3Bvc2VkIHNvbHV0aW9uIHdvdWxkIGJlIHdlbGwtc3VpdGVkICgiSW4gdGhlIGNhc2UgVURQ IGlzIGJsb2NrZWQgZnJvbSBwb2ludCBBIHRvIHBvaW50IEIsIHR1bm5lbGluZyBVRFAgdHJhZmZp YyB0aHJvdWdoIEdSRSBtaWdodCBiZSBhIHNvbHV0aW9uIC4uLiIpLg0KDQotR2lsYmVydA0KDQpJ IGRvIGFncmVlIHRoYXQgYXQgb25lIHBvaW50IHdlIGRpc2N1c3NlZCBoYXZpbmcgYm90aCBUQ1Ag YW5kIFVEUCAoaW4gZmFjdCBpdOKAmXMgbWVudGlvbmVkIGluIHRoZSByZXF1aXJlbWVudHMgZHJh ZnQpLCBhbmQgcG90ZW50aWFsbHkgdXNpbmcgc29tZXRoaW5nIGxpa2UgdGhlIEhhcHB5IEV5ZWJh bGxzIG1lY2hhbmlzbSB0byBmbGlwIGJldHdlZW4gb25lIGFuZCB0aGUgb3RoZXIuIFBlcmhhcHMg dGhlIEdSRSBhcHByb2FjaCBjb3VsZCBiZSBhIHRoaXJkIG9wdGlvbiAoYXMgYSBsYXN0IHJlc29y dCkuDQoNClN0ZWZhbiBGb3VhbnQNCkpOQ0lFLVNFQywgSk5DSUUtU1AsIEpOQ0lFLUVOVCwgSk5D SSwgQ0lTU1ANClNlbmlvciBTZWN1cml0eSBFbmdpbmVlcg0KQ29yZXJvIE5ldHdvcmsgU2VjdXJp dHkNCk1vYmlsZTogKzEuNzAzLjYyNS42MjQzDQo= --_000_8E3635E3427A4275839B3849CE3596F8corerocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjps ZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZU OiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBB RERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1S SUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5Eb3RzICZsdDs8YSBocmVmPSJtYWlsdG86ZG90cy1i b3VuY2VzQGlldGYub3JnIj5kb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYg b2YgR2lsYmVydCBDbGFyayAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdjbGFya0BtdGktc3lzdGVtcy5j b20iPmdjbGFya0BtdGktc3lzdGVtcy5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+RnJpZGF5LCBGZWJydWFyeSA1LCAyMDE2IGF0IDEx OjM2IEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+ZG90c0BpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTog W0RvdHNdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tb3Nrb3dpdHot ZG90cy1ncmUtMDAudHh0PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVIt TEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+ DQo8ZGl2Pg0KPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj5JIGhhdmVuJ3Qg cmVhbGx5IGhhZCB0aW1lIHRvIGNvbXBsZXRlbHkgZGlnZXN0IHRoZSBkcmFmdCBhcyBvZiB5ZXQs IGJ1dCB0d28gdGhvdWdodHM6Jm5ic3A7DQo8YnI+DQo8YnI+DQpJIHRoaW5rIGl0J2QgbWFrZSBt b3JlIHNlbnNlIHRvIGRlZmluZSB0cmFuc3BvcnQtdWRwLCB0cmFuc3BvcnQtdGNwLCBldGMgLi4u IGFuZCB0aGVuIGRlZmluZSBhICpzZXBhcmF0ZSogZHJhZnQgKGZvciB3aGljaCB0aGlzIGRvY3Vt ZW50IG1pZ2h0IGJlIGEgZ29vZCBzdGFydCkgd2hpY2ggZXhwbGFpbnMgaG93IC8gd2h5IHlvdSBt aWdodCB3YW50IHRvIHRha2UgdGhvc2UgdHJhbnNwb3J0cyBhbmQgcHVzaCB0aGVtIHRocm91Z2gg R1JFLiZuYnNwOyBJJ20NCiBjb25jZXJuZWQsIGhvd2V2ZXIsIGJ5IHRoZSBpZGVhIG9mIGluY2x1 ZGluZyBhICp0dW5uZWxpbmcqIG1lY2hhbmlzbSBpbiB0aGUgc3BlY2lmaWNhdGlvbiBmb3Igc29t ZXRoaW5nIGludGVuZGVkIHRvIGFjdCBhcyBhICp0cmFuc3BvcnQqIC4uLiBJIGRvbid0IHRoaW5r IHRoZXNlIHR3byB0aGluZ3MgYXJlIHRoZSBzYW1lLjxicj4NCjxicj4NCkZ1cnRoZXIsIEkgYmVs aWV2ZSB0aGF0IChhdCBzb21lIHBvaW50KSB0aGVyZSB3YXMgZGlzY3Vzc2lvbiB0aGF0IGRpZmZl cmVudCBwcm90b2NvbHMgbWlnaHQgbWFrZSBzZW5zZSBpbiBkaWZmZXJlbnQgY2FzZXMuJm5ic3A7 IEFzIHN1Y2gsIHJhdGhlciB0aGFuIGZvY3VzaW5nIG9uIHdoeSBhIHNwZWNpZmljIHByb3RvY29s IGlzIGJldHRlciB0aGFuIG90aGVycyAod2hpY2ggdGVuZHMgdG8gYmUgY29udGVudGlvdXMsIGJh c2VkIG9uIGV4cGVyaWVuY2VzIHRoYXQNCiB0ZW5kIHRvIHZhcnksIGFuZCBiZWNvbWVzIGxlc3Mg cmVsZXZhbnQgYXMgdGltZSBwYXNzZXMgYW5kIHRoaW5ncyBjaGFuZ2UpLCBpdCBtaWdodCBiZSBt b3JlIHByb2R1Y3RpdmUgdG8gZm9jdXMgZXhjbHVzaXZlbHkgb24gdXNlLWNhc2VzIGZvciB3aGlj aCB0aGUgcHJvcG9zZWQgc29sdXRpb24gd291bGQgYmUgd2VsbC1zdWl0ZWQgKCZxdW90O0luIHRo ZSBjYXNlIFVEUCBpcyBibG9ja2VkIGZyb20gcG9pbnQgQSB0byBwb2ludCBCLCB0dW5uZWxpbmcg VURQDQogdHJhZmZpYyB0aHJvdWdoIEdSRSBtaWdodCBiZSBhIHNvbHV0aW9uIC4uLiZxdW90Oyku PGJyPg0KPGJyPg0KLUdpbGJlcnQ8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFu Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBkbyBhZ3JlZSB0aGF0IGF0IG9uZSBwb2ludCB3 ZSBkaXNjdXNzZWQgaGF2aW5nIGJvdGggVENQIGFuZCBVRFAgKGluIGZhY3QgaXTigJlzIG1lbnRp b25lZCBpbiB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0KSwgYW5kIHBvdGVudGlhbGx5IHVzaW5nIHNv bWV0aGluZyBsaWtlIHRoZSBIYXBweSBFeWViYWxscyBtZWNoYW5pc20gdG8gZmxpcCBiZXR3ZWVu IG9uZSBhbmQgdGhlIG90aGVyLiBQZXJoYXBzIHRoZSBHUkUgYXBwcm9hY2ggY291bGQgYmUNCiBh IHRoaXJkIG9wdGlvbiAoYXMgYSBsYXN0IHJlc29ydCkuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFuZGFsZU1vbm87IGZvbnQtc2l6ZTog MTJweDsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDY0LCA2NCwgNjQpOyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+U3RlZmFuIEZvdWFudDwvc3Bh bj48L3NwYW4+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2Io NjQsIDY0LCA2NCk7Ij5KTkNJRS1TRUMsIEpOQ0lFLVNQLCBKTkNJRS1FTlQsIEpOQ0ksIENJU1NQ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDY0LCA2 NCwgNjQpOyBmb250LXNpemU6IDExcHQ7Ij5TZW5pb3IgU2VjdXJpdHkgRW5naW5lZXI8L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMXB0OyI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTQsIDk1LCAx NDUpOyI+Q29yZXJvIE5ldHdvcmsgU2VjdXJpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNjQsIDY0LCA2NCk7Ij5Nb2Jp bGU6ICYjNDM7MS43MDMuNjI1LjYyNDM8L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_8E3635E3427A4275839B3849CE3596F8corerocom_-- From nobody Fri Feb 5 09:51:12 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6181A0267 for ; Fri, 5 Feb 2016 09:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLIHa-UEn9fb for ; Fri, 5 Feb 2016 09:51:09 -0800 (PST) Received: from atl4mhob22.registeredsite.com (atl4mhob22.registeredsite.com [209.17.115.116]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF581A026F for ; Fri, 5 Feb 2016 09:51:09 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob22.registeredsite.com (8.14.4/8.14.4) with ESMTP id u15Howgu087553 for ; Fri, 5 Feb 2016 12:50:58 -0500 Received: (qmail 30050 invoked by uid 0); 5 Feb 2016 17:50:58 -0000 X-TCPREMOTEIP: 75.118.191.143 X-Authenticated-UID: gclark@mti-systems.com Received: from unknown (HELO localhost.localdomain) (gclark@mti-systems.com@75.118.191.143) by 0 with ESMTPA; 5 Feb 2016 17:50:58 -0000 To: dots@ietf.org References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <8E3635E3-427A-4275-839B-3849CE3596F8@corero.com> From: Gilbert Clark Message-ID: <56B4E101.8020504@mti-systems.com> Date: Fri, 5 Feb 2016 12:50:57 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8E3635E3-427A-4275-839B-3849CE3596F8@corero.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dots] Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 17:51:11 -0000 > 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 nobody Fri Feb 5 10:07:17 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD921A6FB1 for ; Fri, 5 Feb 2016 10:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPT2uTI1TJ_O for ; Fri, 5 Feb 2016 10:07:06 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FFB1A6FB4 for ; Fri, 5 Feb 2016 10:07:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 06C5C621BA; Fri, 5 Feb 2016 13:07:05 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IYePKyf5UJfA; Fri, 5 Feb 2016 13:06:54 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 45D09621B9; Fri, 5 Feb 2016 13:06:53 -0500 (EST) To: Gilbert Clark , dots@ietf.org References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> From: Robert Moskowitz Message-ID: <56B4E4B9.8030307@htt-consult.com> Date: Fri, 5 Feb 2016 13:06:49 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56B4CF79.8010505@mti-systems.com> Content-Type: multipart/alternative; boundary="------------050001030303050102050009" Archived-At: Subject: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 18:07:09 -0000 This is a multi-part message in MIME format. --------------050001030303050102050009 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 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. >> >> 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: internet-drafts@ietf.org >> To: Jinwei Xia , Robert Moskowitz >> >> >> >> >> 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 >> >> >> >> >> >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------050001030303050102050009 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit 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 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.

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: internet-drafts@ietf.org
To: Jinwei Xia <xiajinwei@huawei.com>, Robert Moskowitz <rgm@htt-consult.com> 


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







_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots




_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--------------050001030303050102050009-- From nobody Fri Feb 5 10:12:04 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240DD1A6FD9 for ; Fri, 5 Feb 2016 10:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAvWfKqadBCh for ; Fri, 5 Feb 2016 10:12:00 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A245C1A6FCC for ; Fri, 5 Feb 2016 10:12:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 2A277621B9; Fri, 5 Feb 2016 13:11:59 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SBhSpgLOc3nI; Fri, 5 Feb 2016 13:11:53 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2A8216217A; Fri, 5 Feb 2016 13:11:53 -0500 (EST) To: Gilbert Clark , dots@ietf.org References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <8E3635E3-427A-4275-839B-3849CE3596F8@corero.com> <56B4E101.8020504@mti-systems.com> From: Robert Moskowitz Message-ID: <56B4E5E6.3030806@htt-consult.com> Date: Fri, 5 Feb 2016 13:11:50 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56B4E101.8020504@mti-systems.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dots] Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 18:12:02 -0000 On 02/05/2016 12:50 PM, Gilbert Clark wrote: > >> 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. 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. > > Cheers, > Gilbert > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > From nobody Sat Feb 6 00:48:21 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBFB1A00D8 for ; Sat, 6 Feb 2016 00:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbxmQGuPjcGH for ; Sat, 6 Feb 2016 00:48:18 -0800 (PST) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id 896F71A9063 for ; Sat, 6 Feb 2016 00:48:18 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u168mGQF027757 for ; Sat, 6 Feb 2016 03:48:16 -0500 Received: (qmail 3083 invoked by uid 0); 6 Feb 2016 08:48:16 -0000 X-TCPREMOTEIP: 75.118.191.143 X-Authenticated-UID: gclark@mti-systems.com Received: from unknown (HELO localhost.localdomain) (gclark@mti-systems.com@75.118.191.143) by 0 with ESMTPA; 6 Feb 2016 08:48:16 -0000 To: Robert Moskowitz , dots@ietf.org References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <56B4E4B9.8030307@htt-consult.com> From: Gilbert Clark Message-ID: <56B5B350.3060703@mti-systems.com> Date: Sat, 6 Feb 2016 03:48:16 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56B4E4B9.8030307@htt-consult.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 08:48:20 -0000 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 nobody Sat Feb 6 00:55:26 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426381AD210 for ; Sat, 6 Feb 2016 00:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzJ7ynKIuyeR for ; Sat, 6 Feb 2016 00:55:24 -0800 (PST) Received: from smtp126.ord1c.emailsrvr.com (smtp126.ord1c.emailsrvr.com [108.166.43.126]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F771AD1F5 for ; Sat, 6 Feb 2016 00:55:24 -0800 (PST) Received: from smtp24.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp24.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 85279801B9; Sat, 6 Feb 2016 03:55:23 -0500 (EST) X-Auth-ID: bgreene@senki.org Received: by smtp24.relay.ord1c.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id 4F6B58018E; Sat, 6 Feb 2016 03:55:19 -0500 (EST) X-Sender-Id: bgreene@senki.org Received: from [192.168.3.28] ([UNAVAILABLE]. [175.111.117.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Sat, 06 Feb 2016 03:55:23 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Barry Raveendran Greene In-Reply-To: <56B5B350.3060703@mti-systems.com> Date: Sat, 6 Feb 2016 16:54:24 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <56B4E4B9.8030307@htt-consult.com> <56B5B350.3060703@mti-systems.com> To: Robert Moskowitz Moskowitz X-Mailer: Apple Mail (2.3112) Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 08:55:25 -0000 Two key challenges: 1. What is being described is NOT GRE. It is a modification built on GRE 2. I don=E2=80=99t see you code this in hardware.=20 Get someone to write some prototype code and see if this would even = work.=20 From nobody Sat Feb 6 02:26:54 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570D01B2A8D for ; Sat, 6 Feb 2016 02:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkAr4cGfRCQY for ; Sat, 6 Feb 2016 02:26:52 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA22A1B2A8C for ; Sat, 6 Feb 2016 02:26:51 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id o185so82689538pfb.1 for ; Sat, 06 Feb 2016 02:26:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=2Pu6ZVAkciREPXswtpvRmYUNtCxZt50PYuwDgmnPUQ4=; b=hAvxVJXRNB7rua7S/Oh+uy2NUbG7lrnKCVsn34sT6Glr0/fBxBFIWkyC8eSFHPcg0p +WPrznfmKX3yg3XeNCQS9ntttOwX0GqNeKxdoGppfdvF2Nq/KOujsNcVoUcNzBcn9yJ9 b8Id5YaiFHJEzVW8OHo7o2Of30mL8WJuEcUfk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=2Pu6ZVAkciREPXswtpvRmYUNtCxZt50PYuwDgmnPUQ4=; b=AtSGu9qv1ByLuiUYuwVHNC5lo0Op/Edb6TfZId/FHJNWnkllassa8dQpnj2FCWhMPy xY0diwVw7Fk3Sniq3W1CRDR1pB+R1vN/cogcgjcsdD0POcbnAD+r2bNRoCiLt8iYnKHZ ZUAkwsRqBhdzQp9WdmQfO+r2zMocSzoovxBYDBMziMEn2tcoGwNWUrZX7GPBf/Zc/pCY p/J8o/MYFd9eKnQ2vrCSTZaGhE+ZStIjUXDi/j/qf/pvfcAN4ukWfxx7afUx+dCCDLMO CiKsdcBhmZRXiACDnn/UCXYO9f/KLY+pTT5rnu432fRF35/HgxQ8dsjdkyGX9Ht+HOTf /Mhw== X-Gm-Message-State: AG10YOTd7A3E+mLBD6tpy72lTlDeiw9WbcvWh5dbJVANsgp47h9Bs9BtwPW/sdtSQwfibkl3 X-Received: by 10.98.89.78 with SMTP id n75mr26374527pfb.120.1454754411494; Sat, 06 Feb 2016 02:26:51 -0800 (PST) Received: from [172.19.254.138] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id h89sm25900397pfj.52.2016.02.06.02.26.49 for (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 06 Feb 2016 02:26:50 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Sat, 06 Feb 2016 17:26:47 +0700 Message-ID: <784F45F5-E116-4A9C-9A68-4CE33D6CA954@arbor.net> In-Reply-To: <56B1FC13.8060305@htt-consult.com> References: <56B1FC13.8060305@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5213) Archived-At: Subject: Re: [Dots] New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 10:26:53 -0000 On 3 Feb 2016, at 20:09, 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. 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 From nobody Mon Feb 8 03:00:56 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6761A8974 for ; Sat, 6 Feb 2016 17:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyMGzdt0Phnp for ; Sat, 6 Feb 2016 17:04:25 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A0D1A88B1 for ; Sat, 6 Feb 2016 17:04:25 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id h129so79997001ywb.1 for ; Sat, 06 Feb 2016 17:04:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=69gDsQrH2gVCzyyaWzYckrZ3JRg9HOcv8VmmRakCVzo=; b=0uictN5wmVXaIRRzg6gEP4FQ94Hn7oZyNvHFn4kfbwUEvJghP8nwy09jHl3lreP7ho bnTfW5g6sYkFPFRlyGk2UmcdS7pS3etI71lUA+Alq+xmd1trya1zs3HQAoE8vJk6kKde KO0oo9ceTALQ5EyVXOzmyuerAvFLh5mUz0QsT7izrwNScKmLUJTXCnIIJ0JTc2uHDwoC h4je/SELdgKRuFY17UEpTkKvBZJ4rzcmjqWZhP49C+sIf0IzrnkFELmldv3MusnGsjYa 4BQrFxC6mNH6NowGr/+XEe3Wf7v5Ho87a65fJcTuJPdnpBfsQu5p6G9sUIEFsWnrC9Lt GQWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=69gDsQrH2gVCzyyaWzYckrZ3JRg9HOcv8VmmRakCVzo=; b=khxW+b6Tl7alaVi7XdCj1XMjTVxNHZ4rMeo1fntPW+3H0agkJRS4aiAJqPs828Wac1 pfLCYDsdz3cW72Uv6fWW8hCE7G4Taej4uT2Tpp8AbqWCk78ILZJJIVaqMBPqBzI6kl8M tunozP+qVelgYhC0Fc0RmVSX8ayx5opu2uNhqBaR6Spo4CARWRwOn7QwS443AiefmjdM e5cRTH1oOiVr2lwx7XI05RB68Km8Lupz7lJ0Fa8vybuxj+2W7Sv6Liox7pj7Pz8T9rW1 WDCErG8EW06Yk9NQzL0hi0qqxYYvoTHZ73X/b6O19macXLVG8+a2STA3i9gC0O64YdAQ 1FGQ== X-Gm-Message-State: AG10YOS3u9PMFGpMl5l/sFjYaSfRpIs2V4VrCGQLmq1PdN/fjZRcAGa3qvpB5lfANUm+Z9/Tvhow1+jYsWs1UQ== MIME-Version: 1.0 X-Received: by 10.129.103.69 with SMTP id b66mr11739624ywc.113.1454807064368; Sat, 06 Feb 2016 17:04:24 -0800 (PST) Received: by 10.13.209.198 with HTTP; Sat, 6 Feb 2016 17:04:24 -0800 (PST) Received: by 10.13.209.198 with HTTP; Sat, 6 Feb 2016 17:04:24 -0800 (PST) In-Reply-To: References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <56B4E4B9.8030307@htt-consult.com> <56B5B350.3060703@mti-systems.com> Date: Sat, 6 Feb 2016 20:04:24 -0500 Message-ID: From: Christopher Morrow To: Barry Raveendran Greene Content-Type: multipart/alternative; boundary=001a1147ff2e49df47052b23aa3a Archived-At: X-Mailman-Approved-At: Mon, 08 Feb 2016 03:00:54 -0800 Cc: dots , Robert Moskowitz Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 01:04:26 -0000 --001a1147ff2e49df47052b23aa3a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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) On Feb 6, 2016 3:55 AM, "Barry Raveendran Greene" wrote= : > > Two key challenges: > > 1. What is being described is NOT GRE. It is a modification built on GRE > > 2. I don=E2=80=99t see you code this in hardware. > > Get someone to write some prototype code and see if this would even work. > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > --001a1147ff2e49df47052b23aa3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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).=C2=A0 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 reasonin= g)

On Feb 6, 2016 3:55 AM, "Barry Raveendran G= reene" <bgreene@senki.org&= gt; wrote:

Two key challenges:

1. What is being described is NOT GRE. It is a modification built on GRE
2. I don=E2=80=99t see you code this in hardware.

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

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots
--001a1147ff2e49df47052b23aa3a-- From nobody Mon Feb 8 05:48:51 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FC11B2B59 for ; Mon, 8 Feb 2016 05:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtXdieFaW9gh for ; Mon, 8 Feb 2016 05:48:48 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57AC1B2B38 for ; Mon, 8 Feb 2016 05:48:48 -0800 (PST) Received: from [216.82.242.179] by server-14.bemta-8.messagelabs.com id 70/6C-20638-FBC98B65; Mon, 08 Feb 2016 13:48:47 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-6.tower-86.messagelabs.com!1454939326!16354919!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 93492 invoked from network); 8 Feb 2016 13:48:46 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-6.tower-86.messagelabs.com with AES256-SHA encrypted SMTP; 8 Feb 2016 13:48:46 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0266.001; Mon, 8 Feb 2016 08:48:46 -0500 From: Stefan Fouant To: Christopher Morrow Thread-Topic: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt Thread-Index: AQHRYEAW4xVr63J61UW7HMYVJZWrh58fCY4AgAABtwCAAQ8EAIACFBLH Date: Mon, 8 Feb 2016 13:48:45 +0000 Message-ID: <88B15398-7F5B-449D-8D41-65FB0733002F@corero.com> References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <56B4E4B9.8030307@htt-consult.com> <56B5B350.3060703@mti-systems.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_88B153987F5B449D8D4165FB0733002Fcorerocom_" MIME-Version: 1.0 Archived-At: Cc: Barry Raveendran Greene , dots , Robert Moskowitz Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 13:48:50 -0000 --_000_88B153987F5B449D8D4165FB0733002Fcorerocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry for the top post (on cell). I think the reasoning for suggesting UDP was bad was that Robert said UDP i= s typically blocked on inbound. To be honest, this has not been my experien= ce at all. My observations are that I have rarely seen *all* UDP blocked an= d 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 > wrote: I wonder what happens to a receiver that gets a great packet which is not s= ome 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/pars= e/etc or create raw packets? This seems prone to badness. Why is tcp or UDP bad here? (I need to go read your reasoning) On Feb 6, 2016 3:55 AM, "Barry Raveendran Greene" > wrote: Two key challenges: 1. What is being described is NOT GRE. It is a modification built on GRE 2. I don=92t see you code this in hardware. Get someone to write some prototype code and see if this would even work. _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_88B153987F5B449D8D4165FB0733002Fcorerocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
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 r= arely seen *all* UDP blocked and typically *if* anything is blocked inbound, it's generally in the form of an ACL whi= ch is only blocking a particular source or dest port.

Stefan 

Sent from my iPhone

On Feb 8, 2016, at 6:00 AM, Christopher Morrow <christopher.morrow@gmail.com> 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 'deca= p and forward' (or encap).  I think you are asking for a user space da= emon to capture/parse/etc or create raw packets? This seems prone to badnes= s.

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

On Feb 6, 2016 3:55 AM, "Barry Raveendran G= reene" <bgreene@senki.org&= gt; wrote:

Two key challenges:

1. What is being described is NOT GRE. It is a modification built on GRE
2. I don=92t see you code this in hardware.

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

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots
_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ie= tf.org/mailman/listinfo/dots
--_000_88B153987F5B449D8D4165FB0733002Fcorerocom_-- From nobody Mon Feb 8 05:52:54 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDE71B2B7E for ; Mon, 8 Feb 2016 05:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mS5NYuT68r0f for ; Mon, 8 Feb 2016 05:52:48 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0650B1B2B7B for ; Mon, 8 Feb 2016 05:52:48 -0800 (PST) Received: by mail-pa0-x235.google.com with SMTP id ho8so74063138pac.2 for ; Mon, 08 Feb 2016 05:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=0bug2hmSDEn7ZyGl+Dj4nf3CuHxiJkpxjMTk32Ye2lg=; b=dGsPEvMyxmjKKz05q1gv4XdmlLuIZMJZ6pj25tjFW+P85GeMhpPBJsGUq7UJP952Xa 3AFLuvwCp8EvQxoR2ssleKcWiz/3nx6DSsM7MtAHedZl2mz2RJaHV1Nh9VqcZfPZpOiy FcEpVn/JbA/KdYNXjo2v15pV7vnNcIWx3chv0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=0bug2hmSDEn7ZyGl+Dj4nf3CuHxiJkpxjMTk32Ye2lg=; b=Vtgrle76IaP9Y10sxEtLrcW9vV+oVPR+iOEjx33GF1kJeja/i5K/YuPTMcv+etEE4l yAt5E7ldchyOcCJnqBEdFiOs5FUuYdWnsczk75HjM+kQ4YlZILmjEZcveAH1xHGt0sLo joMQkdvdQdsyVwBojFcaNd9ooApioaBqYgxioNvphkBolF8eqbY5XZVzaw+iZpeA8r6e TLaLi+8XPjAwyg4K0hFZ2/DrFXwi/uMM3Shf2TDizvkbI1W09f9xE7zPwWce3qmy+7xJ KBir3aqRurf3xHzMNqWHnZZEEb14klAol0MW8fn++W0vI72jXVIjybASu1kfoOVlJScj Rwfg== X-Gm-Message-State: AG10YORRVvuVIHsWdBesE621eMJVqsJs5eaP1dJSY9OgjFSNkgD0DQFjqUHnNGkbEBzNEOln X-Received: by 10.66.159.161 with SMTP id xd1mr31358868pab.104.1454939567704; Mon, 08 Feb 2016 05:52:47 -0800 (PST) Received: from [172.19.254.138] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id r5sm43862032pap.7.2016.02.08.05.52.44 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 08 Feb 2016 05:52:47 -0800 (PST) From: "Roland Dobbins" To: dots Date: Mon, 08 Feb 2016 20:52:41 +0700 Message-ID: In-Reply-To: <88B15398-7F5B-449D-8D41-65FB0733002F@corero.com> References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <56B4E4B9.8030307@htt-consult.com> <56B5B350.3060703@mti-systems.com> <88B15398-7F5B-449D-8D41-65FB0733002F@corero.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5213) Archived-At: Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 13:52:53 -0000 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. ----------------------------------- Roland Dobbins From nobody Mon Feb 8 05:57:33 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09A51B2B82 for ; Mon, 8 Feb 2016 05:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0Qls28rjdFN for ; Mon, 8 Feb 2016 05:57:30 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391111B2B81 for ; Mon, 8 Feb 2016 05:57:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1109; q=dns/txt; s=iport; t=1454939850; x=1456149450; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=AWxQYTeMSjy0HxA7ZFqvF8I6+GT1k2vAXW3InwVDGbY=; b=WOBzJxkPDb8HTX31pk5VEIRq35ByW1CcQlxBMtkUle9DZVRkk95bT81V 8f2zrq8rV54J8KTfROfzFX6giUkOzG5GYhBq6Lq7/0jLfshbxdpHi7tKk yfhZLDUn7lXnVNsa44b5U9JDAZZlUyGjCRjG0ksR1dKyVmeJdTcsRs9vp Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AgAgAwnrhW/49dJa1egzpSbQaIVbELA?= =?us-ascii?q?Q2BZhcKhWwCgSo4FAEBAQEBAQGBCoRBAQEBAwEBAQE3NAkOBAIBCA4DBAEBAR4?= =?us-ascii?q?JBycLFAkIAgQBEgiICwgOvEoBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYShDeIb?= =?us-ascii?q?AWHU48iAY1IjnqOPQEeAQFCggMZFIE0aodXfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,416,1449532800"; d="scan'208";a="235299572" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2016 13:57:29 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u18DvT85011403 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Feb 2016 13:57:29 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 8 Feb 2016 07:57:28 -0600 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Mon, 8 Feb 2016 07:57:28 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Roland Dobbins , dots Thread-Topic: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt Thread-Index: AQHRYEAWas3sLGVmlEWd5cwLIK6Kjp8fGlIAgAABtwCAAQ8DAIACZ+SAgAABGYD//5u4EA== Date: Mon, 8 Feb 2016 13:57:28 +0000 Message-ID: <0f494081c4d5483c9416d864fa9b9129@XCH-RCD-017.cisco.com> References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <56B4E4B9.8030307@htt-consult.com> <56B5B350.3060703@mti-systems.com> <88B15398-7F5B-449D-8D41-65FB0733002F@corero.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.232.22.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 13:57:32 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] 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 >=20 > On 8 Feb 2016, at 20:48, Stefan Fouant wrote: >=20 > > Robert said UDP is typically blocked on inbound. >=20 > Mainly on endpoint networks, enough to need a stateful alternative. Yup, and the firewall also typically includes configuration to permit UDP t= raffic to well-known destinations (SIP proxies, B2BUA, Media distribution d= evices etc.). I have not seen any customer blocking media streams for busin= ess calls to run over UDP and force the media streams to run over TCP. -Tiru >=20 > The case in the draft is overstated. And GRE is often blocked on endpoin= t > networks, too. >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Feb 8 06:35:58 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748F01B2C2A for ; Mon, 8 Feb 2016 06:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-JUeU6ZyRAr for ; Mon, 8 Feb 2016 06:35:54 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34E41B2C2C for ; Mon, 8 Feb 2016 06:35:54 -0800 (PST) Received: by mail-yk0-x229.google.com with SMTP id z13so87407578ykd.0 for ; Mon, 08 Feb 2016 06:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=rNeOhGnZHLHJ891QL26xjG+n5WwKYie+75bMQNY7T80=; b=W/4MTZE0N1h3b3ZlLoApXYSI6xE6C9NVQZ8pA0DudqZXevgSl14gIda2+EmmavV5eU /EoZMrKWnbQWghBrxJt3+SpPpIvQGTgnxW799w8wcbO0RCcvrAgwCHnndbjtZdKZ92sA Sh7uwNFguWbk7HQ7xB+sgSCdnO7z5ZDrAeAkzmvhYIa5+8YdlWzwWGbYqWF8OHmWWz6p /y7Mwvg0yA04RH6NIa1+QGFk9+6kVyGX4WFQun8w37Hwb7t2ZX52+zF8OdJLnz4lxkcV SsjFYIH0SKmj5tHWeaxoUcnBdg1sPP1/SVAk8GmOsjGE65tjDBeRQLuOkLKXbJgKmxBW IJ7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rNeOhGnZHLHJ891QL26xjG+n5WwKYie+75bMQNY7T80=; b=Y/EWsXdgWCXMk1uCH1tX5Iqbsen1+QfD0V7uxPDme8wFy15pYeRWkNP1rQOvVQhkEs PdRdLZ3EmhDiFnEdsTSNqB4fZ5QlTr25UYcEe3kfXc6pN8QrcOsT8NKCT1FFQXkKGxg5 cKO5JfyFs2zCrfquTg6rA8LzUqbfoNwYt9L8Zhgmyuwu3ct0UHr/uZK7awmOH3u9AVpU nZZKJPRH/JgjgxlMUL6TJQtK6Z+ORE5//UUC5dKimHkLez3oTXdjDjtc8eP/wogBDV6T V3c7Mhupa1iljOMlPYd0YarMkFzdzb0mWRByRKnWInM0xSFt6Fq6yBi2WXgfP6dQvydk Mdxw== X-Gm-Message-State: AG10YOSVbgTZT1wHyGGCspCEsYruimum7InDSnzOldaUB3hldfxauhxrduvbc6wFzBrFYgeC+MxZJq0Itpk40Q== MIME-Version: 1.0 X-Received: by 10.37.20.195 with SMTP id 186mr15261565ybu.60.1454942154006; Mon, 08 Feb 2016 06:35:54 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.13.209.198 with HTTP; Mon, 8 Feb 2016 06:35:53 -0800 (PST) In-Reply-To: <0f494081c4d5483c9416d864fa9b9129@XCH-RCD-017.cisco.com> References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <56B4E4B9.8030307@htt-consult.com> <56B5B350.3060703@mti-systems.com> <88B15398-7F5B-449D-8D41-65FB0733002F@corero.com> <0f494081c4d5483c9416d864fa9b9129@XCH-RCD-017.cisco.com> Date: Mon, 8 Feb 2016 09:35:53 -0500 X-Google-Sender-Auth: LEQiiQLZvjC92hR-MYmzyOiqq0w Message-ID: From: Christopher Morrow To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Roland Dobbins , dots Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 14:35:56 -0000 On Mon, Feb 8, 2016 at 8:57 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: Dots [mailto:dots-bounces@ietf.org] 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 draf= t- >> moskowitz-dots-gre-00.txt >> >> 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. > > 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 bus= iness calls to run over UDP and force the media streams to run over TCP. > 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? > -Tiru > >> >> The case in the draft is overstated. And GRE is often blocked on endpoi= nt >> networks, too. >> >> ----------------------------------- >> Roland Dobbins >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Feb 8 06:40:47 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD0D1B2C30 for ; Mon, 8 Feb 2016 06:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gwZZZCCL16C for ; Mon, 8 Feb 2016 06:40:43 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B7B1B2C0B for ; Mon, 8 Feb 2016 06:40:43 -0800 (PST) Received: by mail-pa0-x233.google.com with SMTP id cy9so74717188pac.0 for ; Mon, 08 Feb 2016 06:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=sw9mEGoba0UegaS7WTD05zaOMul3Sj+Tc6uBaHDXHeY=; b=bo3p2PMSUBESiRfmovW409R0BAXNpToo8ebdBVbyK+N4P+vQFRM8oBUzWk0ENdGa4u sd+QgWX7EQD+DzXNtRo42mRbSNQD/u1d0176LgwYVFO0r1EcKfHbQiSkZUA3sTEqg45p +mU2UU1KDOpbNi5mdVt7H4Vx6Odnj+qHb1KYI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=sw9mEGoba0UegaS7WTD05zaOMul3Sj+Tc6uBaHDXHeY=; b=F9tgWKMGoFWKqPUdp19YJgKhzXe3GjHIF+bXyGADgxks4Q9/PAtDOp2Z88xolQ1XlA 2EMDz0svSOaCZ47lbDszrJLo/S17ufaZehwEkaezXb1516OucRhxYh2horGPhaosBUeS fZxJmVjhyHfnkORpVCeMJnX9/k4VUAKjzOCuvUI+lqADeL12x2QuxCFf18PglxRs74rz 3Z1PjhqNPE3Jl1ouGSUyJ80dihk9VWYLZ/D+xfrJ+7QwK6JzTqux6oyqScXWurDCov2z GgFyIfcXoChN1ict/ubixb7nRLD+bFSAkdjjVE73thFe/Sv2FflqlUVEYvM3k/yNxfih A08g== X-Gm-Message-State: AG10YORqzR/1KBiGm+ywAgS7GM+WietdO2YVkHBBuNR+4hdwKi8XV3widQ46C+rWZt7PST1P X-Received: by 10.66.100.228 with SMTP id fb4mr42180506pab.84.1454942443323; Mon, 08 Feb 2016 06:40:43 -0800 (PST) Received: from [172.19.254.138] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id s21sm25343650pfi.29.2016.02.08.06.40.41 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 08 Feb 2016 06:40:42 -0800 (PST) From: "Roland Dobbins" To: dots Date: Mon, 08 Feb 2016 21:40:36 +0700 Message-ID: <5AAEA018-A171-40A2-BF1B-2574AC8D3101@arbor.net> In-Reply-To: References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <56B4E4B9.8030307@htt-consult.com> <56B5B350.3060703@mti-systems.com> <88B15398-7F5B-449D-8D41-65FB0733002F@corero.com> <0f494081c4d5483c9416d864fa9b9129@XCH-RCD-017.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5213) Archived-At: Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 14:40:45 -0000 On 8 Feb 2016, at 21:35, Christopher Morrow wrote: > 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" 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. ;> > If you're going to go the 'just use gre' as a header ... why not just > 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. ----------------------------------- Roland Dobbins From nobody Mon Feb 8 06:45:17 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7CF1B2C58 for ; Mon, 8 Feb 2016 06:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lw_rsTJpITJR for ; Mon, 8 Feb 2016 06:45:15 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id CB53E1ACDBB for ; Mon, 8 Feb 2016 06:45:14 -0800 (PST) Received: from [10.10.10.183] (h7.180.128.40.static.ip.windstream.net [40.128.180.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 05E7354059D; Mon, 8 Feb 2016 09:45:12 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: text/plain; charset=utf-8 From: Jared Mauch In-Reply-To: <5AAEA018-A171-40A2-BF1B-2574AC8D3101@arbor.net> Date: Mon, 8 Feb 2016 09:45:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <484E673A-354D-4A95-B4F1-090FC6F84AB1@puck.nether.net> References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <56B4E4B9.8030307@htt-consult.com> <56B5B350.3060703@mti-systems.com> <88B15398-7F5B-449D-8D41-65FB0733002F@corero.com> <0f494081c4d5483c9416d864fa9b9129@XCH-RCD-017.cisco.com> <5AAEA018-A171-40A2-BF1B-2574AC8D3101@arbor.net> To: Roland Dobbins X-Mailer: Apple Mail (2.3112) Archived-At: Cc: dots Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 14:45:17 -0000 > On Feb 8, 2016, at 9:40 AM, Roland Dobbins wrote: >=20 > On 8 Feb 2016, at 21:35, Christopher Morrow wrote: >=20 >> 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" >=20 > 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. >=20 > ;> 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 = =E2=80=98TCP giant=E2=80=99 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 nobody Mon Feb 8 06:48:08 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8C91B2C76 for ; Mon, 8 Feb 2016 06:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7v4cCBM6_78y for ; Mon, 8 Feb 2016 06:48:05 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72251B2C6F for ; Mon, 8 Feb 2016 06:48:05 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id q63so6972817pfb.0 for ; Mon, 08 Feb 2016 06:48:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=fJE0vdr8iuxXMLT2i9x39hG6I2aG4C6PMLpfOET6JBc=; b=kcT/Mw/eeVWk0v0IJv+clibYax61I8whJskBqCzDoxVHbqdrfl38JZ3QGZqJTj0ZMY r5W5I4ed2fdbNCzM6oDSz5bXrigeY2gxTJmKnGXYG8yQszop+c2TlgTFUzHea7Rlz30R 5Uh1ieRwAzshyMxkFr+t14rns+YdYJHTcs498= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=fJE0vdr8iuxXMLT2i9x39hG6I2aG4C6PMLpfOET6JBc=; b=mxf5DLtWvdqm5Jyg+6C6Xwfl/PTfMfPlGuDp8N8S5gLC3RtT4bCkahn11bYi5tS6a5 sZj80KPoMOg2BRM1u3OzVIrbnD7Winuma8trizIPtD3wv3XCjkEUJULP3SglQtJ0RaST P/K6u9wsuXSRgqM1dFLQQNj+EB1whAVQMrg+VcK5rmD/qC5D4ruhhrblOminX/EQiP2S 0qZlwQpLwl2KvYdODE8+gfTsUEk+3gJMWD9ydlwZolooNp8zSVn542ltVlcymdU04W9A eB0Ek5YC31Ye02Vb6KBwfxNgPzodjqHFV2pyyefIf6Yf+a6neZAMlMMErIun1sIK2IHt slXw== X-Gm-Message-State: AG10YOQSwFscZD6Ux4m0w6IYdQAdOTaEV9gPIdD3lOQvNNzyM+uL53h4DmRy9vtZlhMz+bm5 X-Received: by 10.98.18.215 with SMTP id 84mr42960801pfs.131.1454942885346; Mon, 08 Feb 2016 06:48:05 -0800 (PST) Received: from [172.19.254.138] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id r5sm44162886pap.7.2016.02.08.06.48.03 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 08 Feb 2016 06:48:04 -0800 (PST) From: "Roland Dobbins" To: dots Date: Mon, 08 Feb 2016 21:48:00 +0700 Message-ID: In-Reply-To: <484E673A-354D-4A95-B4F1-090FC6F84AB1@puck.nether.net> References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <56B4E4B9.8030307@htt-consult.com> <56B5B350.3060703@mti-systems.com> <88B15398-7F5B-449D-8D41-65FB0733002F@corero.com> <0f494081c4d5483c9416d864fa9b9129@XCH-RCD-017.cisco.com> <5AAEA018-A171-40A2-BF1B-2574AC8D3101@arbor.net> <484E673A-354D-4A95-B4F1-090FC6F84AB1@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5213) Archived-At: Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 14:48:07 -0000 On 8 Feb 2016, at 21:45, Jared Mauch wrote: > 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! ----------------------------------- Roland Dobbins From nobody Mon Feb 8 07:38:35 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BF01B2D5B for ; Mon, 8 Feb 2016 07:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWZYfCXRr9N5 for ; Mon, 8 Feb 2016 07:38:32 -0800 (PST) Received: from atl4mhob15.myregisteredsite.com (atl4mhob15.myregisteredsite.com [209.17.115.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF6A1B2D4C for ; Mon, 8 Feb 2016 07:38:32 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob15.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u18FcVpW032188 for ; Mon, 8 Feb 2016 10:38:31 -0500 Received: (qmail 18583 invoked by uid 0); 8 Feb 2016 15:38:31 -0000 X-TCPREMOTEIP: 166.176.251.68 X-Authenticated-UID: gclark@mti-systems.com Received: from unknown (HELO ?192.168.1.115?) (gclark@mti-systems.com@166.176.251.68) by 0 with ESMTPA; 8 Feb 2016 15:38:31 -0000 To: dots@ietf.org References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <56B4E4B9.8030307@htt-consult.com> <56B5B350.3060703@mti-systems.com> <88B15398-7F5B-449D-8D41-65FB0733002F@corero.com> <0f494081c4d5483c9416d864fa9b9129@XCH-RCD-017.cisco.com> <5AAEA018-A171-40A2-BF1B-2574AC8D3101@arbor.net> From: Gilbert Clark Message-ID: <56B8B676.1090508@mti-systems.com> Date: Mon, 8 Feb 2016 10:38:30 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5AAEA018-A171-40A2-BF1B-2574AC8D3101@arbor.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 15:38:34 -0000 On 02/08/2016 09:40 AM, Roland Dobbins wrote: > >> If you're going to go the 'just use gre' as a header ... why not just >> use IP bare? > > 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 :) >> or SCTP > > This makes much more sense than GRE (or pseudo-GRE), but still has > 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 nobody Mon Feb 8 08:21:02 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2892F1B2E84 for ; Mon, 8 Feb 2016 08:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlhYlSeGsYQC for ; Mon, 8 Feb 2016 08:20:58 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A021B2DCF for ; Mon, 8 Feb 2016 08:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2604; q=dns/txt; s=iport; t=1454948458; x=1456158058; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=q8ypGk9GtfD3jyI4nUJhH4Vf6VY2WjP1QWWVu37Rdhw=; b=LQVtFt/aV3Wm/lO8QmlR8JW/jxY9P8qxsMLu5M4LwONvvAEnTyKgttX7 KpxUTn+ihwz0zaBa3ycRoVUrHryoAbSU5muWLB3yLUXnubW06udMWgO9/ XRC94wTL3PF5WkDJOUO2OEBmk5j8gJQSXdBamBQ7nzQh1j6WsSank+Jyo 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQASv7hW/4ENJK1VCYM6Um0GiFWxC?= =?us-ascii?q?wENgWYXCoVsAoEvOBQBAQEBAQEBgQqEQQEBAQQBAQE3NAkOBAIBCA4DBAEBAR4?= =?us-ascii?q?JBycLFAkIAgQBEgiIEw69EAEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhKDPHuEC?= =?us-ascii?q?YRjBZZ1AYVLh32Oeo49AR4BAUKCMIE0aodXfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,416,1449532800"; d="scan'208";a="71296702" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2016 16:20:57 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u18GKvhg004676 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Feb 2016 16:20:57 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 8 Feb 2016 10:20:56 -0600 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Mon, 8 Feb 2016 10:20:56 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Gilbert Clark , "dots@ietf.org" Thread-Topic: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt Thread-Index: AQHRYEAWas3sLGVmlEWd5cwLIK6Kjp8fGlIAgAABtwCAAQ8DAIACZ+SAgAABGYD//5u4EIAAcFqAgAABUQCAABAuAP//pf/A Date: Mon, 8 Feb 2016 16:20:56 +0000 Message-ID: <259f1c6f437947eea2fea3e13b97c74c@XCH-RCD-017.cisco.com> References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <56B4E4B9.8030307@htt-consult.com> <56B5B350.3060703@mti-systems.com> <88B15398-7F5B-449D-8D41-65FB0733002F@corero.com> <0f494081c4d5483c9416d864fa9b9129@XCH-RCD-017.cisco.com> <5AAEA018-A171-40A2-BF1B-2574AC8D3101@arbor.net> <56B8B676.1090508@mti-systems.com> In-Reply-To: <56B8B676.1090508@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.69.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 16:21:01 -0000 Unfortunately SCTP has NAT/Firewall traversal problem, to overcome this Web= RTC Data channels use SCTP over DTLS over UDP https://tools.ietf.org/html/d= raft-ietf-rtcweb-data-channel-13. -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Gilbert Clark > Sent: Monday, February 08, 2016 9:09 PM > To: dots@ietf.org > Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft= - > moskowitz-dots-gre-00.txt >=20 > On 02/08/2016 09:40 AM, Roland Dobbins wrote: > > > >> If you're going to go the 'just use gre' as a header ... why not just > >> use IP bare? > > > > Firewall rules, ACLs, NATs, et. al. > > >=20 > 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. >=20 > I think it's probably best that we never speak of this idea again :) >=20 > >> or SCTP > > > > This makes much more sense than GRE (or pseudo-GRE), but still has > > supportability/prevalence issues. > > >=20 > 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 descr= ibing > the operation of DOTS over SCTP happens after any TCP draft is created an= d > adopted. >=20 > 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 stil= l > maintain its identity as a tunneling protocol. >=20 > In other words, a transport-capable GRE would be pseudo-GRE in the same > way that an apple is a pseudo-orange. >=20 > 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. >=20 > -Gilbert >=20 > [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. >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Feb 9 09:01:54 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADAC1ACD50 for ; Tue, 9 Feb 2016 09:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.152 X-Spam-Level: X-Spam-Status: No, score=-13.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQyE-7vENipe for ; Tue, 9 Feb 2016 09:01:46 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68F931ACD41 for ; Tue, 9 Feb 2016 09:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16185; q=dns/txt; s=iport; t=1455037302; x=1456246902; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=FsLXDcNQsI4IEzktmWCqYyzex7lNHZChiAVBbsCXDNg=; b=eRP4+P9bmIbjjIcd2r2dD+0PHNO5PyPjRA2m7Ndvgmlhp+4en+JHgvVc C06whWSVtRJSpeadwL6hO3xwGAdnCx5MkXaOULyaWBOYNZp3AqsQVQRrM TQgT7V6GuavVOSNWNum1dYtCU9njNghoZzI7/zufd45XjhYtVxMVpALzN k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgD4GbpW/4wNJK1egzpSbYhcsRsBD?= =?us-ascii?q?YFmFwELhWoCgTY4FAEBAQEBAQGBCoRBAQEBBAEBAWsJAhALDgMDAQIBJwcnHwk?= =?us-ascii?q?IBhMJEogADr5/AQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYSgW0IgkKEUoMLgQ8Fj?= =?us-ascii?q?Sd0hFOECoVMiASBW0qDeYMDhVKOPw8PAQFCggMZFIFVGy4BiFIBAQE?= X-IronPort-AV: E=Sophos;i="5.22,421,1449532800"; d="scan'208,217";a="235767590" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2016 17:01:41 +0000 Received: from [10.24.5.232] ([10.24.5.232]) (authenticated bits=0) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u19H1dfR018787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Feb 2016 17:01:40 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_669806B1-5E2C-4297-90E6-F040940D73FB" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: <56B4E4B9.8030307@htt-consult.com> Date: Mon, 8 Feb 2016 17:08:08 -0800 Message-Id: References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <56B4E4B9.8030307@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3112) X-Authenticated-User: dwing Archived-At: Cc: Gilbert Clark , dots@ietf.org Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 17:01:52 -0000 --Apple-Mail=_669806B1-5E2C-4297-90E6-F040940D73FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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 = wrote:=20 > 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 >=20 > = http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml = >=20 > My working list was: >=20 > ICMP > TCP > UDP > GRE > ESP > AH > L2TP > SCTP > ROHC >=20 > Note how short the list is. >=20 > I was searching for an IP protocol that: >=20 > 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) >=20 > 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. >=20 > I DO explain why I hold GRE is better than ESP. Principally to move = the security context up the stack to reduce fate-sharing. >=20 > 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. >=20 > I really did not want tunneling so much as not UDP or TCP. The cost = was tunneling. >=20 > If people feel there is value, I can put this thought process into the = draft. >=20 > And I am still thinking of getting a ethtypefor GRE that directly = supports ROHC and then squeeze the ____ out of the headers... >=20 > On 02/05/2016 11:36 AM, Gilbert Clark wrote: >> I haven't really had time to completely digest the draft as of yet, = but two thoughts: =20 >>=20 >> 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. >>=20 >> 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 ..."). >>=20 >> -Gilbert >>=20 >> 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. >>>=20 >>> 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. >>>=20 >>>=20 >>> -------- Forwarded Message -------- >>> Subject: New Version Notification for = draft-moskowitz-dots-gre-00.txt >>> Date: Wed, 03 Feb 2016 04:48:44 -0800 >>> From: internet-drafts@ietf.org = >>> To: Jinwei Xia , = Robert Moskowitz >>>=20 >>> 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. >>>=20 >>> 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 = >>>=20 >>>=20 >>> Abstract: >>> This document describes using a GRE tunnel to deliver DOTS = messages >>> between DOTS agents and compares it to other methods. >>>=20 >>> = =20 >>>=20 >>>=20 >>> 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. >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots = >>=20 >>=20 >>=20 >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots = >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --Apple-Mail=_669806B1-5E2C-4297-90E6-F040940D73FB Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=windows-1252
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 <rgm-sec@htt-consult.com> 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

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

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: internet-drafts@ietf.org
To: Jinwei Xia <xiajinwei@huawei.com>, Robert Moskowitz <rgm@htt-consult.com> 


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







_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots




_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots


--Apple-Mail=_669806B1-5E2C-4297-90E6-F040940D73FB-- From nobody Tue Feb 9 14:12:24 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3F71B2B15 for ; Tue, 9 Feb 2016 14:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoUQbKJT69C9 for ; Tue, 9 Feb 2016 14:12:21 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04DD1B2A9B for ; Tue, 9 Feb 2016 14:12:21 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id x65so651252pfb.1 for ; Tue, 09 Feb 2016 14:12:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=3+xOG+GCrhnxcFMr20GYQROZJjXPs96EvBP0nlJQG7g=; b=Ws03I6Lq+umTxgaFM3RKfs5ZvjC7wa3S91FxHtHB9AzFcGK/gn/o+Z98WtO82HqxPM hrdXj4+d/xtqJuOlY8xP+vm+ic8MGHidRa+BFEPOFqSTIwAXJ7eW5C+ux5SAqUwkmm4w leP/NmXUk4TfGidPsricLP9yRZMhz0BFL+uqg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=3+xOG+GCrhnxcFMr20GYQROZJjXPs96EvBP0nlJQG7g=; b=dk0gbsyD5JaCxx16coK+O/U2mdNSkf95BdeXZdr7O2xC5LUtwNp2BwA+4Ie/3rRltV ghNGVxwITaTSY+r4S5D91PcB29S96SAeqVKJ5iqil5zt6OWb50j9o/seDFvTkaxIpJUz W8eOaKxeXrw6369y4FVq7y/vbCJxx0UkMxlR94O2WVPUJOmL+plsJh2am4VIltX9x3gV be2EcVwI876fgcjSncGE7V3C/OKN8elTN/xuooo1i3y1QXO/Gc4lMsGtSkW+NVDi2ZW4 +pIuxy8cECdiUWqdOR2h/HVG3eefocB39w4VAZyrtIm5jv145DpVxYT6Rhm84styMhVc EilQ== X-Gm-Message-State: AG10YOSlcNnQyvK91kbU62pmVdyGGtwmyO7DV4sGeWOPrtvqdEB5CYpNV1j6Uwm459fnJTBk X-Received: by 10.98.71.15 with SMTP id u15mr53986367pfa.161.1455055941352; Tue, 09 Feb 2016 14:12:21 -0800 (PST) Received: from [172.19.254.138] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id e1sm110751pas.1.2016.02.09.14.12.18 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 09 Feb 2016 14:12:20 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 10 Feb 2016 05:12:11 +0700 Message-ID: <5FE5E38C-A6DE-4876-92FE-662A93F9644C@arbor.net> In-Reply-To: References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <56B4E4B9.8030307@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5213) Archived-At: Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 22:12:23 -0000 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. ;> ----------------------------------- Roland Dobbins From nobody Tue Feb 9 14:16:15 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9931B2BB8 for ; Tue, 9 Feb 2016 14:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iklf6FryZScv for ; Tue, 9 Feb 2016 14:16:12 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A133E1B2B44 for ; Tue, 9 Feb 2016 14:16:12 -0800 (PST) Received: by mail-pa0-x232.google.com with SMTP id cy9so699727pac.0 for ; Tue, 09 Feb 2016 14:16:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=vC7sxGF1PzJots9wsQZ4WZqqaZFw1bch0NLeZ1ei+XA=; b=MdgGjT7bjQkK7ZPMb4Dhkz0yRY3q+5EyW5gQjJYfkKl8CPv4QmpLHJj7FDQKLd1Ccm Hn2FsiQ26IirEoE9dMuuGr7xSgLaMDoef1WDBZarYUWXdkoU4hnkMIZG8JwGhY/Zx+Hg dtrq3nF33cKOfT9ehiGv2oPaXLfWhnpBNNHnw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=vC7sxGF1PzJots9wsQZ4WZqqaZFw1bch0NLeZ1ei+XA=; b=nHWzFWX8BgDsG/wGSlz3hw1W2hrbIAOaPIiX/Y/PNE9bD2rV0g5qwSLMmX+1f2imqV i809llrYXHZ4Dpw/Lb9nMpXIe82KZM809Tc7lcESR0w8rU+5SzmCrCmEUOqmXTAKZeO4 8VPsvXl+KO3yUA1G1gaE16bofPiRgioc9Eu+R1AEZ5W2Y0ayyQWqmPhJ8uMenC1BjRg1 J40hIvDVPcYhOs7YUSYohGU+xEI5w5Dkf/Pw3DcahAYthHJNe4FJhRijVcRnB0HFEMGa B9D/m4wCS6rdEC2GPsfN9USwJB5jSdri/jADn+ZmK7DgBTx2JPsVf236UkVaHZ6/a0Yp VWsQ== X-Gm-Message-State: AG10YORdfyNx2jiIk3HB4xsMwNUPD7ebDz9MVs3Q0Si+QzIOh2TWShp0s62lGvWKerntWLFy X-Received: by 10.66.101.74 with SMTP id fe10mr53566620pab.66.1455056172313; Tue, 09 Feb 2016 14:16:12 -0800 (PST) Received: from [172.19.254.138] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id t29sm118584pfi.8.2016.02.09.14.16.09 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 09 Feb 2016 14:16:11 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 10 Feb 2016 05:16:03 +0700 Message-ID: In-Reply-To: <56B8B676.1090508@mti-systems.com> References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <56B4E4B9.8030307@htt-consult.com> <56B5B350.3060703@mti-systems.com> <88B15398-7F5B-449D-8D41-65FB0733002F@corero.com> <0f494081c4d5483c9416d864fa9b9129@XCH-RCD-017.cisco.com> <5AAEA018-A171-40A2-BF1B-2574AC8D3101@arbor.net> <56B8B676.1090508@mti-systems.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5213) Archived-At: Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 22:16:13 -0000 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. ----------------------------------- Roland Dobbins From nobody Tue Feb 9 14:17:41 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817741B2BEB for ; Tue, 9 Feb 2016 14:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEpuFFNd64bd for ; Tue, 9 Feb 2016 14:17:39 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FD871B2BE9 for ; Tue, 9 Feb 2016 14:17:39 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id q63so737980pfb.0 for ; Tue, 09 Feb 2016 14:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=Sz+WD9PjPgTu/J87Mb9akBAQGgqa/s+KhMHD516gAR8=; b=gf4Fqm0abbqC4mTb8FXcu3LqJbFUnBahD+mpocai6RFwn3Ke08uMWtpSyNAre9vECW am1CqxazjRdRqZxwERAXScUbTL2fZfEnq/NqGLD6vanqCIQ+z6Z62MzAY3MKpZRJthl1 ul3xuzdgGyyfk2Yj6Jw/0UHsBFz/svJCAsIY4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=Sz+WD9PjPgTu/J87Mb9akBAQGgqa/s+KhMHD516gAR8=; b=ZnNlRAamsM1IepTpyUwO+AUUQTnK5vB/nmgLXVwqvr1O1xbWU7tq9a95YARXE78poY cCBUquOQlNSor5Q1HMU/CNYl6exLn0jCXZDJli/FxLe25/bpXJrWxAWfRjIlewvYraH+ s3wOk0gX+a1T4fArgoWr8GPuhsvRYkp2bBO9Bgzplkpsz5COQFOAgIwZzi5k2w0MHYQP /bvsuB1mZ+TIYyrFjgXDwXrcN0GnJZmeFfHKC4NUMNlYWsPf0UOGVzYPJvXY4WkRxFbQ fuz/wk2vcQmve/UGuqp6wCLqsiLeUxYgOfcKrMw/L1YfumPWq0pLu7SMxtnNOl6NUXge 1zSA== X-Gm-Message-State: AG10YORSatl1Uk3+RrdehqUIeCHKqHQidbrfGqWJ9P7TzlNgst/o9nL24BBO99Wm/ZcIAZkO X-Received: by 10.98.15.19 with SMTP id x19mr54241364pfi.60.1455056259008; Tue, 09 Feb 2016 14:17:39 -0800 (PST) Received: from [172.19.254.138] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id b63sm110787pfj.25.2016.02.09.14.17.32 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 09 Feb 2016 14:17:38 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Wed, 10 Feb 2016 05:17:23 +0700 Message-ID: <75293893-596A-418F-90F5-5063A0785D02@arbor.net> In-Reply-To: <259f1c6f437947eea2fea3e13b97c74c@XCH-RCD-017.cisco.com> References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <56B4E4B9.8030307@htt-consult.com> <56B5B350.3060703@mti-systems.com> <88B15398-7F5B-449D-8D41-65FB0733002F@corero.com> <0f494081c4d5483c9416d864fa9b9129@XCH-RCD-017.cisco.com> <5AAEA018-A171-40A2-BF1B-2574AC8D3101@arbor.net> <56B8B676.1090508@mti-systems.com> <259f1c6f437947eea2fea3e13b97c74c@XCH-RCD-017.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5213) Archived-At: Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 22:17:40 -0000 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). ----------------------------------- Roland Dobbins From nobody Tue Feb 9 14:18:59 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4510C1B2BEB for ; Tue, 9 Feb 2016 14:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmUOYBrRjKkE for ; Tue, 9 Feb 2016 14:18:56 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894741B2BE6 for ; Tue, 9 Feb 2016 14:18:56 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id e127so692776pfe.3 for ; Tue, 09 Feb 2016 14:18:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=71v/Wtba/pTLFbaKtZfJONMtiV7D0KdMQvk4gLUXB/A=; b=iGy3C1ziDzOKo2ooJOA/u9iL4uBt1kd7cJESQPCHSNimXlZLY1c0LO6IJFKApkyzf3 VjDgLm0Ja8t6b9/ob/ZFvz5ua28YYYxP53gu2AWKBmr0lEcnCbvWvTDQKPROOy2VkgZ0 e9WKbUIRFPbTeZ7oi1uPt4cJcRSFI8c2gTQzs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=71v/Wtba/pTLFbaKtZfJONMtiV7D0KdMQvk4gLUXB/A=; b=TSubcs+n1aG0zCIf7BxowLglHkN8jKLohKnh+ZxtPzikesZBNSETIYUefLrE+keYb9 8IX8yzK17VpOmPeJrRT8/B1WoV/RUUg8XdOq2PPfRK4rnnQf/bNOz9Uy6PFGj0/3VLmA d8dqRd+h32qQs+yntkdy1kud99RH/5weKLFeCN33JneprvKV3InaJLrTzMErhIpD5ALP kA5GdaLBgr/1L3jxuWxV1hjG7JMf9qWIRmoUkMgkECNdY/PQQaA2HQ34NNtWM654IIQL DTJEapk2VTy0/oXaxbvtgPj9aG3a73xX1rr0aL6VtpyCzCRqEwohdrV++/LEL+A3FgtV 6zQg== X-Gm-Message-State: AG10YORqBTbnlzw8rTeWTEK8CRG/CY9BAIWMzlP0LkEWIA3p3FAyvSOMk1dHoV/q9MvWCzp1 X-Received: by 10.98.69.78 with SMTP id s75mr54086278pfa.102.1455056336211; Tue, 09 Feb 2016 14:18:56 -0800 (PST) Received: from [172.19.254.138] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id x10sm73657pas.37.2016.02.09.14.18.53 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 09 Feb 2016 14:18:55 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 10 Feb 2016 05:18:46 +0700 Message-ID: <31636DF3-3495-47F5-98FD-D68238676233@arbor.net> In-Reply-To: <56B4E4B9.8030307@htt-consult.com> References: <56B1FC13.8060305@htt-consult.com> <56B4CF79.8010505@mti-systems.com> <56B4E4B9.8030307@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5213) Archived-At: Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 22:18:58 -0000 On 6 Feb 2016, at 1:06, Robert Moskowitz wrote: > 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... This sort of thing is way beyond the scope of the DOTS WG, IMHO. ----------------------------------- Roland Dobbins From nobody Tue Feb 9 20:17:06 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21401B36A5 for ; Tue, 9 Feb 2016 20:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4kpcsZ4vbX5 for ; Tue, 9 Feb 2016 20:17:00 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A54121B36A3 for ; Tue, 9 Feb 2016 20:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2878; q=dns/txt; s=iport; t=1455077820; x=1456287420; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LBtFCRM3uq/vQvuLBqYblc8dFUDyCCNaU3wzV+kvUrw=; b=dXyaCha1ddyTWmjvo8gw8nNBMhGHrA8cpd0A3IvUmt6huGQcCuFZReqS 5aZeegkRj6Av45nyCrnrFVW84iq6QdHNcPPKyLTBFR/txnn/IN98SvJbJ KvUQ1WAeqhWFn0S6ufQFdVNkDuMXcnXfLsRDPmYAwkDVnwEA6vXT5Tx4d k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQAUubpW/40NJK1egzpSbQaIVrEgA?= =?us-ascii?q?Q2BZiGFbAIcgRU4FAEBAQEBAQF/C4RBAQEBBCMRQw4EAgEIEQQBAQMCIwMCAgI?= =?us-ascii?q?wFAEGAQEFAwIEEwiIEw6wUo57AQEBAQEBAQEBAQEBAQEBAQEBAQEBFXuFF4Q3h?= =?us-ascii?q?A0NgxiBOgWNJ4lRAYVLh32BY0qDeYhVhW+ITwEeAQFCg2RqAYcaPHwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,424,1449532800"; d="scan'208";a="69885436" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Feb 2016 04:16:59 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u1A4GxR2020424 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Feb 2016 04:16:59 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 9 Feb 2016 22:16:59 -0600 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Tue, 9 Feb 2016 22:16:59 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "dots@ietf.org" Thread-Topic: New Version Notification for draft-reddy-dots-transport-02.txt Thread-Index: AQHRY7c9avFvV/O2OkehIfPg9TO+E58kqItg Date: Wed, 10 Feb 2016 04:16:59 +0000 Message-ID: <3b252758719042ac91db1547794b2dc1@XCH-RCD-017.cisco.com> References: <20160210035757.19979.34015.idtracker@ietfa.amsl.com> In-Reply-To: <20160210035757.19979.34015.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.58.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Dots] FW: New Version Notification for draft-reddy-dots-transport-02.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 04:17:04 -0000 SGkgYWxsLA0KDQpUaGlzIHVwZGF0ZSB0byB0aGUgZHJhZnQgaW5jbHVkZXMgdGhlIGZvbGxvd2lu ZyBjaGFuZ2VzLg0KDQoqIFByb3Bvc2VzIEhhcHB5RXllYmFsbHMgbWVjaGFuaXNtIHRvIGNvbnZl eSBET1RTIHNpZ25hbA0KKiBBZGRyZXNzZXMgY29tbWVudHMgZnJvbSB0aGUgV0cuDQoqIChEKVRM UyBwcm90b2NvbCBwcm9maWxlIHRvIHJlZHVjZSBkZWxheSB0byBjb252ZXkgRE9UUyBzaWduYWwN Cg0KQ29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KDQotVGlydQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFtt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFdlZG5lc2RheSwgRmVicnVh cnkgMTAsIDIwMTYgOToyOCBBTQ0KVG86IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBEYW4g V2luZyAoZHdpbmcpOyBNaWtlIEdlbGxlciAobWdlbGxlcik7IFJvYmVydCBNb3Nrb3dpdHo7IE1v aGFtZWQgQm91Y2FkYWlyOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQpTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJlZGR5LWRvdHMtdHJhbnNwb3J0LTAy LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1yZWRkeS1kb3RzLXRyYW5zcG9y dC0wMi50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaXJ1bWFsZXN3YXIg UmVkZHkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQt cmVkZHktZG90cy10cmFuc3BvcnQNClJldmlzaW9uOgkwMg0KVGl0bGU6CQlDby1vcGVyYXRpdmUg RERvUyBNaXRpZ2F0aW9uDQpEb2N1bWVudCBkYXRlOgkyMDE2LTAyLTA5DQpHcm91cDoJCUluZGl2 aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxNw0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yZWRkeS1kb3RzLXRyYW5zcG9ydC0wMi50 eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1yZWRkeS1kb3RzLXRyYW5zcG9ydC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtcmVkZHktZG90cy10cmFuc3BvcnQtMDINCkRpZmY6ICAgICAgICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcmVkZHktZG90cy10cmFu c3BvcnQtMDINCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyBtZWNoYW5p c21zIHRoYXQgYSBET1RTIGNsaWVudCBjYW4gdXNlLCB3aGVuDQogICBpdCBkZXRlY3RzIGEgcG90 ZW50aWFsIERpc3RyaWJ1dGVkIERlbmlhbC1vZi1TZXJ2aWNlIChERG9TKSBhdHRhY2ssDQogICB0 byBzaWduYWwgdGhhdCB0aGUgRE9UUyBjbGllbnQgaXMgdW5kZXIgYW4gYXR0YWNrIG9yIHJlcXVl c3QgYW4NCiAgIHVwc3RyZWFtIERPVFMgc2VydmVyIHRvIHBlcmZvcm0gaW5ib3VuZCBmaWx0ZXJp bmcgaW4gaXRzIGluZ3Jlc3MNCiAgIHJvdXRlcnMgZm9yIHRyYWZmaWMgdGhhdCB0aGUgRE9UUyBj bGllbnQgd2lzaGVzIHRvIGRyb3AuICBUaGUgRE9UUw0KICAgc2VydmVyIGNhbiB0aGVuIHVuZGVy dGFrZSBhcHByb3ByaWF0ZSBhY3Rpb25zIChpbmNsdWRpbmcsIGJsYWNraG9sZSwNCiAgIGRyb3As IHJhdGUtbGltaXQsIG9yIGFkZCB0byB3YXRjaCBsaXN0KSBvbiB0aGUgc3VzcGVjdCB0cmFmZmlj IHRvIHRoZQ0KICAgRE9UUyBjbGllbnQsIHRodXMgcmVkdWNpbmcgdGhlIGVmZmVjdGl2ZW5lc3Mg b2YgdGhlIGF0dGFjay4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue Feb 9 20:35:23 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC28B1B369A for ; Tue, 9 Feb 2016 20:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdjP0TBhqfeL for ; Tue, 9 Feb 2016 20:35:19 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C40F71B36C7 for ; Tue, 9 Feb 2016 20:35:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3980; q=dns/txt; s=iport; t=1455078919; x=1456288519; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=vB3nTSnSXDMWf0MoZMIheYFSfQtrl6wof/zvelX6nok=; b=c+9zerJrg+GnUllOuMIFm5QRddmkTbosRbDvVeSZuTxORnwHX4By15kn JxhSdWvp1Tvh/x6RjnsDd32pHltPjWirn+6+qpG8+lQ5eIMXk8o/FHGx6 U4mzuTcAfeBjak3+kOUF/9Yib2oA3Ups1G2mLjwANut/xEieUHh1WDMur g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQB0vbpW/4YNJK1egzpSbQaIVrEgA?= =?us-ascii?q?Q2BZhcKhWwCgS84FAEBAQEBAQGBCoRBAQEBBAEBATc0FwQCAQgRBAEBHwkHJws?= =?us-ascii?q?UCQgBAQQBEgiIEw6/UQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhKEN4QahFIFh?= =?us-ascii?q?0+HB4giAYVLgmyFEYFjhEOIVYptg1EBHgEBQoIAHIFIaodXfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,424,1449532800"; d="scan'208";a="71907160" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Feb 2016 04:35:18 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u1A4ZIDB032352 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Feb 2016 04:35:18 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 9 Feb 2016 22:35:18 -0600 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Tue, 9 Feb 2016 22:35:18 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Roman D. Danyliw" , "dots@ietf.org" Thread-Topic: draft-reddy-dots-transport-01 questions/comments Thread-Index: AdESzrt3abkfTKpBT2qmQFMcQzRfnhQ60sqQ Date: Wed, 10 Feb 2016 04:35:18 +0000 Message-ID: <474c57c98ca8488fbf1486baaf8dd8c1@XCH-RCD-017.cisco.com> References: <359EC4B99E040048A7131E0F4E113AFCD95473F4@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCD95473F4@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.58.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-reddy-dots-transport-01 questions/comments X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 04:35:22 -0000 Hi Roman, Thanks for the comments. We have updated the draft https://tools.ietf.org/h= tml/draft-reddy-dots-transport-02 to address all your comments, Please have= a look. See inline > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman D. Danyliw > Sent: Saturday, October 31, 2015 6:31 AM > To: dots@ietf.org > Subject: [Dots] draft-reddy-dots-transport-01 questions/comments >=20 > Hello Tiru, Dan, Prashanth, Mike, Mohamed and Robert! >=20 > [Note: This entire message is written as an individual contributor. Chai= r hat > off] >=20 > In reading draft-reddy-dots-transport-01, I had a few questions and > comments. Given that this is an early -01 draft, I readily acknowledge t= hat it > might be premature to broach them so please defer as necessary. >=20 > ** Page 5, Section 4.1.1: policy-id: "This identifier must be unique for = each > policy bound to the DOTS client." > I had difficulty understanding what this sentence meant. Is this uniquen= ess > property the same as saying that (a) every distinct SOS request needs a > unique policy-id? (b) this policy-id needs to be unique relative to the a= ctive > requests with the DOTS server? The text clearly states that the "documen= t > does not make assumption about this identifier is generated" but are any > assumptions made about the state kept? >=20 > ** Page 5, Section 4.1.1: target-ip and target-port: Each of these fields= can > take a list. What is the format of that list? Figure 7 for example sugg= ests that > ranges are possible (e.g., 1-65535). >=20 > ** Section 4 presents a RESTful API. However, the current text only desc= ribes > the request. What do responses look like? Does the client get back a 20= 0 > code on success? What does the server return when an unrecognized policy= - > id is passed when trying to retrieve the active SOSes? How are unrecogni= zed > fields treated? >=20 > ** Page 6, Section 4.1.1: Signal SOS: "... thus sending a maximum of 500 = bytes > of SOS message ..." > What happens if the SOS message needs to be more than 500 bytes? > Perhaps the request has a really long URL and a number of individual IP > addresses that aren't aggregated. Does the request then need to be split= into > separate SOS messages? >=20 > ** Page 6, Section 4.1.1: Signal SOS: How should multiple instances of an= y of > the fields be parsed (e.g., multiple target-ip or policy-id)? >=20 > ** Page 7, Section 4.1.2: Retrieving SOS: What does a response look like = when > retrieving a specific SOS? Is it an HTTP response with the body of the J= SON > that made the request? >=20 > ** Page 7, Section 4.1.2: Retrieving SOS: What does the response for all = SOS > look like? In what order are they returned? >=20 > ** Page 7, Section 4.2: REST: This introductory section explicitly refere= nces a > DOTS client, relay and server. Can there just be a client talking to the= server ? Yes, it's discussed in the last paragraph of this section that DOTS client = can directly talk to the DOTS server. -Tiru >=20 > ** Page 8, Section 4.2.1.1: Install filtering rules: Are any of the descr= ibed > fields are optional? >=20 > ** Page 9, Section 4.2.1.1: lifetime: "Upon expiry of this lifetime, and = if the > request is not reiterated, the rule will be withdrawn ..." > How is a request reiterated? Just resend the same message? >=20 > ** Page 9, Section 4.2.1.1: lifetime: What happens if a message is "reite= rated" > without being expired. For example: > Send: (time=3D0; policy-id=3D1; lifetime=3D100) > Send: (time=3D10; policy-id=3D1; lifetime=3D100) >=20 > At time=3D10 what is the value of the lifetime counter for policy-id=3D1?= Is it 90? > Or 90+100? >=20 > Regards, > Roman >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Feb 10 06:53:34 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E061B2B85 for ; Wed, 10 Feb 2016 06:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_gTIunZjG6N for ; Wed, 10 Feb 2016 06:53:31 -0800 (PST) Received: from atl4mhob20.myregisteredsite.com (atl4mhob20.registeredsite.com [209.17.115.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1DF1B2B83 for ; Wed, 10 Feb 2016 06:53:30 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob20.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u1AErTwc031049 for ; Wed, 10 Feb 2016 09:53:29 -0500 Received: (qmail 26899 invoked by uid 0); 10 Feb 2016 14:53:29 -0000 X-TCPREMOTEIP: 75.118.191.143 X-Authenticated-UID: gclark@mti-systems.com Received: from unknown (HELO localhost.localdomain) (gclark@mti-systems.com@75.118.191.143) by 0 with ESMTPA; 10 Feb 2016 14:53:29 -0000 To: dots@ietf.org References: <20160210035757.19979.34015.idtracker@ietfa.amsl.com> <3b252758719042ac91db1547794b2dc1@XCH-RCD-017.cisco.com> From: Gilbert Clark Message-ID: <56BB4EE9.7000406@mti-systems.com> Date: Wed, 10 Feb 2016 09:53:29 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <3b252758719042ac91db1547794b2dc1@XCH-RCD-017.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] FW: New Version Notification for draft-reddy-dots-transport-02.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 14:53:33 -0000 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? * 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 nobody Wed Feb 17 00:06:42 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0971B3466 for ; Wed, 17 Feb 2016 00:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_7BR2CAY673 for ; Wed, 17 Feb 2016 00:06:39 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B821B3409 for ; Wed, 17 Feb 2016 00:06:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3732; q=dns/txt; s=iport; t=1455696399; x=1456905999; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=9dPcIWkb+dsyGobdVaSG/ECIUd9DjAOiC4MGyeLfusQ=; b=adKtbdM6gH9nyrLAW4Kkt7c9rjE33uzPFexC9kvjMSi3wMV3f5Vx5Vuu C1fwNN6aTW+zB53GiRNwHSzCXu5YE1IMEj7xz7RCfJzILwGrOn54C9KCy +e1LCj7K+m6+eC30DeONQn2UuwZ1N0m0vd/ip4ApEs5ygJNp+nRO9QO/E s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQB7KcRW/4sNJK1egzpSbQa6MwENg?= =?us-ascii?q?WcXCoVsAoE9OBQBAQEBAQEBgQqEQQEBAQICAQEBNzQJDgQCAQgOAwQBAQEeCQc?= =?us-ascii?q?nCxQIAQgCBAESCAGIEQ67KQEBAQEBAQEBAQEBAQEBAQEBAQEBARWGEoQ7hB2EU?= =?us-ascii?q?gWXAwGFUod/gWOEQ4hUhXGIVQEeAQFCg2NqAYdkfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,459,1449532800"; d="scan'208";a="74144228" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Feb 2016 08:06:21 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u1H86LKv015785 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Feb 2016 08:06:21 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 17 Feb 2016 02:06:20 -0600 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Wed, 17 Feb 2016 02:06:20 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Gilbert Clark , "dots@ietf.org" Thread-Topic: [Dots] FW: New Version Notification for draft-reddy-dots-transport-02.txt Thread-Index: AQHRY7c9avFvV/O2OkehIfPg9TO+E58kqItggAEaNoCAChZcEA== Date: Wed, 17 Feb 2016 08:06:20 +0000 Message-ID: References: <20160210035757.19979.34015.idtracker@ietfa.amsl.com> <3b252758719042ac91db1547794b2dc1@XCH-RCD-017.cisco.com> <56BB4EE9.7000406@mti-systems.com> In-Reply-To: <56BB4EE9.7000406@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.76.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] FW: New Version Notification for draft-reddy-dots-transport-02.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 08:06:41 -0000 Hi Gilbert, Thanks for the review, Please see inline > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Gilbert Clark > Sent: Wednesday, February 10, 2016 3:53 PM > To: dots@ietf.org > Subject: Re: [Dots] FW: New Version Notification for draft-reddy-dots- > transport-02.txt >=20 >=20 > 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. >=20 > Hi: >=20 > Just a few quick comments while skimming this draft. >=20 > * 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 HT= TP. We may end up using COAP itself, but the basic idea here was to use a s= ignaling mechanism that would look the same over UDP and TCP to make it eas= ier on the DOTS client and server. >=20 > * 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: >=20 > { > "policy-id": number, > "target-ip": string, > "target-port": string, > "target-protocol": string, > } >=20 > 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 de= fine these parameters in this draft or a separate draft. >=20 > "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]." >=20 > * 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 a= nd TCP. > * 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. Sure, will move to a different section. > * 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 ht= tp://www.ietf.org/proceedings/94/slides/slides-94-tsvwg-14.pdf and discusse= d 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 dr= aft explains that connectionless transport is strongly recommended and conn= ection-oriented transport may be necessary due to network policy or middlew= are limitations. -Tiru >=20 > -Gilbert >=20 > [1] https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Feb 17 06:19:32 2016 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A0E1B3B01; Wed, 17 Feb 2016 06:18:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160217141825.6180.94956.idtracker@ietfa.amsl.com> Date: Wed, 17 Feb 2016 06:18:25 -0800 Archived-At: X-Mailman-Approved-At: Wed, 17 Feb 2016 06:19:32 -0800 Cc: rdd@cert.org, dots-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, dots@ietf.org Subject: [Dots] dots - New Meeting Session Request for IETF 95 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 14:18:25 -0000 A new meeting session request has just been submitted by Roman Danyliw, a Chair of the dots working group. --------------------------------------------------------- Working Group Name: DDoS Open Threat Signaling Area Name: Security Area Session Requester: Roman Danyliw Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: mile sacm i2nsf saag Second Priority: opsawg opsarea Special Requests: A meeting time that avoids Monday morning is requested. --------------------------------------------------------- From nobody Wed Feb 17 10:24:59 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDD61B2BD2 for ; Wed, 17 Feb 2016 10:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvKchgTcWh6c for ; Wed, 17 Feb 2016 10:24:55 -0800 (PST) Received: from atl4mhob20.myregisteredsite.com (atl4mhob20.registeredsite.com [209.17.115.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7179B1B2BCD for ; Wed, 17 Feb 2016 10:24:55 -0800 (PST) Received: from atl4oxapp110.mgt.hosting.qts.netsol.com ([10.30.71.186]) by atl4mhob20.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u1HIOrsl039131; Wed, 17 Feb 2016 13:24:53 -0500 Date: Wed, 17 Feb 2016 13:24:53 -0500 (EST) From: "gclark mti-systems.com" To: "Tirumaleswar Reddy (tireddy)" , dots@ietf.org Message-ID: <1615392409.17264.1455733493310.JavaMail.vpopmail@atl4oxapp110.mgt.hosting.qts.netsol.com> In-Reply-To: References: <20160210035757.19979.34015.idtracker@ietfa.amsl.com> <3b252758719042ac91db1547794b2dc1@XCH-RCD-017.cisco.com> <56BB4EE9.7000406@mti-systems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.6.2-Rev35 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Dots] FW: New Version Notification for draft-reddy-dots-transport-02.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "gclark mti-systems.com" List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 18:24:58 -0000 Hi! Further comments inline: > On February 17, 2016 at 3:06 AM "Tirumaleswar Reddy (tireddy)" > wrote: > > > Hi Gilbert, > > Thanks for the review, Please see inline > > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Gilbert Clark > > Sent: Wednesday, February 10, 2016 3:53 PM > > To: dots@ietf.org > > 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. > > > > > "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. > > * 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. 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 nobody Thu Feb 18 23:31:59 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890A01ACDB1 for ; Thu, 18 Feb 2016 23:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYR3LUxvWygZ for ; Thu, 18 Feb 2016 23:31:56 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0065C1A8AC1 for ; Thu, 18 Feb 2016 23:31:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10852; q=dns/txt; s=iport; t=1455867115; x=1457076715; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=fj3AixyDEOMuhGKZ2xtHIDtyrz+Wj2VNm0rUCl+HeEE=; b=hHnNurFYD8EhurDZpPBuyFxpzOc31wzYmrXXf5RG1uvR5qhOEs3tKsFj wvXvGvAfapizak7EHrE2SDFaWjHJ7Pjx9CsxpYZCT/6jxIB1vObspD5Yp VJWZ88hRU49y7JlKwi/1UCnhsdTI3N3cc2rsoat9h0vr1nkRY0BUtF92o E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQB/w8ZW/5hdJa1egzpSbQa6JgENg?= =?us-ascii?q?WchhWwCHIE3OBQBAQEBAQEBZCeEQQEBAQIBASMRQw4GAQgRBAEBAQICIwMCBDA?= =?us-ascii?q?UAQcBCQEEARIIAYgJCA6sZo8bAQEBAQEBAQEBAQEBAQEBAQEBAQEWe4UXgz59h?= =?us-ascii?q?B0ugmqBOgWXBQGFVoJthRKBY4RDhzKBIoVxiFUBHgEBQoICGYFIagGHPn0BAQE?= X-IronPort-AV: E=Sophos;i="5.22,469,1449532800"; d="scan'208";a="72932068" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2016 07:31:54 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1J7Vsph012447 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Feb 2016 07:31:54 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 19 Feb 2016 01:31:53 -0600 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Fri, 19 Feb 2016 01:31:54 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "gclark mti-systems.com" , "dots@ietf.org" Thread-Topic: [Dots] FW: New Version Notification for draft-reddy-dots-transport-02.txt Thread-Index: AdFq55Wu6t5spHmNQGaZHud2Gb01qA== Date: Fri, 19 Feb 2016 07:31:54 +0000 Message-ID: <952cee8779a64dba8d7fa6abaf20c29d@XCH-RCD-017.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.61.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] FW: New Version Notification for draft-reddy-dots-transport-02.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 07:31:58 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBnY2xhcmsgbXRpLXN5c3RlbXMu Y29tIFttYWlsdG86Z2NsYXJrQG10aS1zeXN0ZW1zLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBG ZWJydWFyeSAxNywgMjAxNiA3OjI1IFBNDQo+IFRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVk ZHkpOyBkb3RzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbRG90c10gRlc6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcmVkZHktZG90cy0NCj4gdHJhbnNwb3J0LTAyLnR4dA0K PiANCj4gSGkhDQo+IA0KPiBGdXJ0aGVyIGNvbW1lbnRzIGlubGluZToNCj4gDQo+ID4gT24gRmVi cnVhcnkgMTcsIDIwMTYgYXQgMzowNiBBTSAiVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSIN Cj4gPiA8dGlyZWRkeUBjaXNjby5jb20+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPiBIaSBHaWxiZXJ0 LA0KPiA+DQo+ID4gVGhhbmtzIGZvciB0aGUgcmV2aWV3LCBQbGVhc2Ugc2VlIGlubGluZQ0KPiA+ DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogRG90cyBbbWFp bHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdpbGJlcnQgQ2xhcmsNCj4g PiA+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTAsIDIwMTYgMzo1MyBQTQ0KPiA+ID4gVG86 IGRvdHNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbRG90c10gRlc6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3INCj4gPiA+IGRyYWZ0LXJlZGR5LWRvdHMtIHRyYW5zcG9ydC0wMi50 eHQNCj4gPiA+DQo+ID4gPg0KPiA+ID4gT24gMDIvMDkvMjAxNiAxMToxNiBQTSwgVGlydW1hbGVz d2FyIFJlZGR5ICh0aXJlZGR5KSB3cm90ZToNCj4gPiA+ID4gSGkgYWxsLA0KPiA+ID4gPg0KPiA+ ID4gPiBUaGlzIHVwZGF0ZSB0byB0aGUgZHJhZnQgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBjaGFu Z2VzLg0KPiA+ID4gPg0KPiA+ID4gPiAqIFByb3Bvc2VzIEhhcHB5RXllYmFsbHMgbWVjaGFuaXNt IHRvIGNvbnZleSBET1RTIHNpZ25hbA0KPiA+ID4gPiAqIEFkZHJlc3NlcyBjb21tZW50cyBmcm9t IHRoZSBXRy4NCj4gPiA+ID4gKiAoRClUTFMgcHJvdG9jb2wgcHJvZmlsZSB0byByZWR1Y2UgZGVs YXkgdG8gY29udmV5IERPVFMgc2lnbmFsDQo+ID4gPiA+DQo+ID4gPiA+IENvbW1lbnRzIGFuZCBz dWdnZXN0aW9ucyBhcmUgd2VsY29tZS4NCj4gPiA+DQo+ID4gPiBIaToNCj4gPiA+DQo+ID4gPiBK dXN0IGEgZmV3IHF1aWNrIGNvbW1lbnRzIHdoaWxlIHNraW1taW5nIHRoaXMgZHJhZnQuDQo+ID4g Pg0KPiA+ID4gKiBJcyBydW5uaW5nIEhUVFAgb3ZlciBVRFAgd2VsbC1kZWZpbmVkPyAgQ29BUCBt aWdodCBiZSBvbmUNCj4gPiA+IGNhbmRpZGF0ZSwgYW5kIFFVSUMgWzFdIG1pZ2h0IGJlIGFub3Ro ZXIgLi4uIGJ1dCB0aG9zZSBhcmVuJ3QgcmVhbGx5DQo+ID4gPiBIVFRQIGluIHRoZSBzdHJpY3Rl c3Qgc2Vuc2Ugb2YgdGhlIHdvcmQsIGFyZSB0aGV5Pw0KPiA+DQo+ID4gSXQncyBsaWtlIENPQVAg KHJ1bnMgb3ZlciBib3RoIFRDUCBhbmQgVURQKSBhbmQgdXNlcyBzaW1pbGFyIGZlYXR1cmVzIG9m DQo+IEhUVFAuDQo+ID4gV2UgbWF5IGVuZCB1cCB1c2luZyBDT0FQIGl0c2VsZiwgYnV0IHRoZSBi YXNpYyBpZGVhIGhlcmUgd2FzIHRvIHVzZSBhDQo+ID4gc2lnbmFsaW5nIG1lY2hhbmlzbSB0aGF0 IHdvdWxkIGxvb2sgdGhlIHNhbWUgb3ZlciBVRFAgYW5kIFRDUCB0byBtYWtlDQo+ID4gaXQgZWFz aWVyIG9uIHRoZSBET1RTIGNsaWVudCBhbmQgc2VydmVyLg0KPiA+DQo+IA0KPiBPa2F5IC4uLiBi dXQgSSB0aGluayB0aGlzIGRpc2N1c3Npb24gaXMgYWN0dWFsbHkgdGhlIGNvcmUgb2YgYSAqdHJh bnNwb3J0Kg0KPiBzcGVjaWZpY2F0aW9uIDopDQo+IA0KPiA+ID4NCj4gPiA+ICogR2VuZXJhbGx5 LCBJJ20gbm90IHN1cmUgaG93IEkgZmVlbCBhYm91dCBtaXhpbmcgbWVzc2FnZSBtb2RlbCB3aXRo DQo+ID4gPiBzcGVjaWZpY2F0aW9ucyByZWdhcmRpbmcgaG93IHRoZSBtb2RlbCBzaG91bGQgYmUg dHJhbnNtaXR0ZWQuICBJbiBteQ0KPiA+ID4gb3Bpbmlvbiwgc2VjdGlvbnMgc3VjaCBhczoNCj4g PiA+DQo+ID4gPiAgICB7DQo+ID4gPiAgICAgICAicG9saWN5LWlkIjogbnVtYmVyLA0KPiA+ID4g ICAgICAgInRhcmdldC1pcCI6IHN0cmluZywNCj4gPiA+ICAgICAgICJ0YXJnZXQtcG9ydCI6IHN0 cmluZywNCj4gPiA+ICAgICAgICJ0YXJnZXQtcHJvdG9jb2wiOiBzdHJpbmcsDQo+ID4gPiAgICAg fQ0KPiA+ID4NCj4gPiA+IHdvdWxkIGJlIGJlc3QgZGVmaW5lZCBpbiBhIHNlcGFyYXRlIGRyYWZ0 LCBzaW5jZSB0aGVyZSBhcmUgKmFsbA0KPiA+ID4ga2luZHMqIG9mIHdheXMgdG8gZ2V0IHRoYXQg ZGF0YSBmcm9tIHBvaW50IEEgdG8gcG9pbnQgQiAuLi4gbm90IGFsbA0KPiA+ID4gb2Ygd2hpY2gg aW52b2x2ZSBHRVQsIFBPU1QsIFBVVCwgb3IgREVMRVRFLg0KPiA+DQo+ID4gQWdyZWVkLiBBcyB5 b3Uga25vdyBMNyBwcm90b2NvbCBmb3IgRE9UUyBzaWduYWwgaXMgbm90IGZpbmFsaXplZC4gT25j ZQ0KPiA+IHRoZSBXRyBhZ3JlZXMgdG8gdXNlIHRoaXMgcHJvcG9zZWQgbWVjaGFuaXNtLCB3ZSBj YW4gdGhlbiBkaXNjdXNzDQo+ID4gd2hldGhlciB0byBkZWZpbmUgdGhlc2UgcGFyYW1ldGVycyBp biB0aGlzIGRyYWZ0IG9yIGEgc2VwYXJhdGUgZHJhZnQuDQo+IA0KPiBTdXJlIC4uLiBidXQgSSB0 aGluayB0aGF0IGRlZmluaW5nIGFuZCBhZ3JlZWluZyB0byBhIHRyYW5zcG9ydCAqZmlyc3QqDQo+ IGFwcHJvYWNoZXMgdGhlIHByb2JsZW0gYmFja3dhcmRzLiAgV2Ugc2hvdWxkIGZpcnN0IGRlZmlu ZSB3aGF0IHdlIHdhbnQgdG8NCj4gdHJhbnNwb3J0ICh0aGUgbW9kZWxzIGFuZCB0aGUgYXNzb2Np YXRlZCB2ZXJicyksICp0aGVuKiBkZWZpbmUgaG93IHRvIG1hcA0KPiB0aG9zZSBhY3Rpb25zIG9u dG8gYSByZWFzb25hYmxlIHByb3RvY29sLg0KPiANCj4gV2l0aCB0aGF0IHNhaWQsIGl0IHNlZW1z IGxpa2UgdGhpcyBkcmFmdCBhY3R1YWxseSBmb2N1c2VzIG1vcmUgb24gdGhlIG1vZGVscw0KPiBh bmQgdGhlIGFzc29jaWF0ZWQgYWN0aW9ucyB0aGFuIGl0IGRvZXMgb24gKmhvdyogdGhpbmdzIGFy ZSBhY3R1YWxseSBzZW50LiAgQXMNCj4gc3VjaCwgaXQgZG9lc24ndCBzdHJpa2UgbWUgYXMgYSB0 cmFuc3BvcnQgZHJhZnQgc28gbXVjaCBhcyBpdCBpcyBhIHNwZWNpZmljYXRpb24NCj4gb2YgYSBt b3JlIGdlbmVyYWwgRE9UUyBtb2RlbC4gIEkgdGhpbmsgdGhlIGluY2x1c2lvbiBvZiAiLXRyYW5z cG9ydCIgaW4gdGhlDQo+IHRpdGxlIG1hZGUgbWUgZXhwZWN0IHRvIGZpbmQgc29tZXRoaW5nIGlu IHRoZSBkb2N1bWVudCB0aGF0IEkgZGlkbid0LCB3aGljaCBJDQo+IGZvdW5kIHRvIGJlIGNvbmZ1 c2luZy4NCj4gDQo+IFRodXMsIEkgdGhpbmsgSSdkIGJlIGhhcHBpZXIgaWYgdGhlIGRyYWZ0IHdl cmUgcmVuYW1lZCB0byBzdWdnZXN0IGl0IGZvY3VzZXMNCj4gbW9yZSBzcGVjaWZpY2FsbHkgb24g ZGVmaW5pbmcgbW9kZWxzIC8gdmVyYnM6IHVzaW5nIGEgUkVTVCB2b2NhYnVsYXJ5IHRvDQo+IGRl ZmluZSBzdWNoIHRoaW5ncyBpcyBmaW5lLCBJIHRoaW5rLCBhbmQgbWFrZXMgYSBncmVhdCBkZWFs IG9mIHNlbnNlIGlmIHRoZQ0KPiBleHBlY3RhdGlvbiBpcyB0aGF0IHRoZSBmb2xrcyBpbXBsZW1l bnRpbmcgRE9UUyB3aWxsIGJlIHVzaW5nIHNvbWV0aGluZw0KPiBIVFRQLWxpa2UgdG8gdHJhbnNw b3J0IG1lc3NhZ2VzIGJhY2sgYW5kIGZvcnRoLg0KPiANCj4gQSBzZXQgb2YgYWRkaXRpb25hbCBz cGVjaWZpY2F0aW9ucyBjb3VsZCB0aGVuIGZvY3VzIG9uIGhvdyB0byBtYXAgdGhvc2UNCj4gbW9k ZWxzIGFuZCB2ZXJicyB0byBkaWZmZXJlbnQgcHJvdG9jb2xzIChlLmcuIEhUVFAgMS4xLCBIVFRQ IDIsIENvQVAsIFFVSUMpOg0KPiB0aGVzZSBhZGRpdGlvbmFsIHNwZWNpZmljYXRpb25zIHdvdWxk IGJlICItdHJhbnNwb3J0IiBkcmFmdHMgb2YgdGhlIGZvcm0gIi0NCj4gdHJhbnNwb3J0LWh0dHAi LCAiLXRyYW5zcG9ydC1xdWljIiwgIi10cmFuc3BvcnQtY29hcCIsIGV0Yy4NCg0KV2h5IGlzIHRo ZXJlIG5lZWQgZm9yIGRpZmZlcmVudCBwcm90b2NvbHMgPw0KV0cgSSBndWVzcyBoYXMgdG8gZGlz Y3VzcyBhbmQgcGljayBvbmUgTDcgcHJvdG9jb2wuIEhUVFAgMS4xIGFuZCBIVFRQIDIgb25seSBy dW4gb24gVENQLCBRVUlDIG9ubHkgcnVucyBvbiBVRFAgKGFuZCBpdCdzIG5vdCB5ZXQgc3RhbmRh cmRpemVkKSwgQ29BUCBjYW4gcnVuIG92ZXIgYm90aCBVRFAgYW5kIFRDUCBhbmQgcnVubmluZyBj b2RlIGlzIGF2YWlsYWJsZS4NCg0KPiANCj4gPg0KPiA+ID4NCj4gPiA+ICJUbyBvdmVyY29tZSB0 aGVzZSBjb25uZWN0aW9uIHNldHVwIHByb2JsZW1zLCB0aGUgRE9UUyBjbGllbnQgTVVTVA0KPiA+ ID4gdHJ5IGNvbm5lY3RpbmcgdG8gdGhlIERPVFMgc2VydmVyIHVzaW5nIGJvdGggSVB2NiBhbmQg SVB2NCwgYW5kIE1VU1QNCj4gPiA+IHRyeSBib3RoIERUTFMgb3ZlciBVRFAgYW5kIFRMUyBvdmVy IFRDUCBpbiBhIGZhc2hpb24gc2ltaWxhciB0byB0aGUNCj4gPiA+ICJIYXBweSBFeWViYWxscyIg bWVjaGFuaXNtIFtSRkM2NTU1XS4iDQo+ID4gPg0KPiA+ID4gKiBJJ20gbm90IHN1cmUgdGhhdCBE VExTIG9yIFRMUyBpcyAiTVVTVCIgc28gbXVjaCBhcyBhICJTSE9VTEQiIC4uLg0KPiA+ID4gYnV0 IGluIHRoZSBldmVudCB0aGF0IFRMUyBvciBEVExTIGFyZSBub3QgdXNlZCwgRE9UUyBtZXNzYWdl cyBNVVNUDQo+ID4gPiBiZSBzZW50IHRocm91Z2ggYSBjaGFubmVsIHRoYXQgZ3VhcmFudGVlcyBp bnRlZ3JpdHkgYW5kDQo+ID4gPiBjb25maWRlbnRpYWxpdHkgYXQgb25lIGxheWVyIG9yIGFub3Ro ZXIuDQo+ID4NCj4gPiBXZSB3YW50IHRvIG1ha2UgaXQgbWFuZGF0b3J5IHRvIG1lZXQgdGhlIHNl Y3VyaXR5IHJlcXVpcmVtZW50cw0KPiA+IGRpc2N1c3NlZCBpbg0KPiA+IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTAwIGZvciBib3RoDQo+ ID4gVURQIGFuZCBUQ1AuDQo+IA0KPiBPa2F5IC4uLiBidXQgdGhlIHBocmFzaW5nIGFzIGl0IGV4 aXN0cyBpbiB0aGUgZHJhZnQgaW1wbGllcyB0aGF0ICpvbmx5KiBUTFMgb3INCj4gRFRMUyBtYXkg KmV2ZXIqIGJlIHVzZWQgdG8gZnVsZmlsbCB0aGVzZSBzZWN1cml0eSByZXF1aXJlbWVudHMuICAN Cj4gSSdtIG5vdA0KPiBjb252aW5jZWQgdGhhdCB0aGlzIGlzIHRoZSBjYXNlLCBhbmQgdGhlcmVm b3JlIGJlbGlldmUgbW9yZSBnZW5lcmljIHBocmFzaW5nDQo+IGNvdWxkIGJlIGFwcHJvcHJpYXRl IGhlcmUuICBTb21lb25lIGNhbiAoYW5kIG5vIGRvdWJ0IHdpbGwgOikgY29ycmVjdCBtZSBpZg0K PiBJJ20gd3JvbmcsIGhvd2V2ZXIuDQoNCkRPVFMgYWdlbnRzIG11c3Qgc3VwcG9ydCBvbmUgc2Vj dXJpdHkgbWVjaGFuaXNtIGZvciBpbnRlcm9wZXJhYmlsaXR5LCBkb24ndCBzZWUgYSBuZWVkIGZv ciBtdWx0aXBsZSBzZWN1cml0eSBtZWNoYW5pc20gdG8gbWVldCB0aGUgcmVxdWlyZW1lbnRzLg0K DQo+IA0KPiA+ID4gKiBIYXBweSBleWViYWxscyBzZWVtcyBsaWtlIGEgcHJldHR5IGdvb2QgaWRl YSwgYnV0IHdoYXQncyB0aGUNCj4gPiA+IGp1c3RpZmljYXRpb24gZm9yIG1ha2luZyBpdCBhICJN VVNUIj8NCj4gPg0KPiA+IFRyYW5zcG9ydCBzZWxlY3Rpb24gZm9yIERPVFMgc2lnbmFsIHdhcyBw cmVzZW50ZWQgaW4gVFNWV0cgV0cgYXQNCj4gPiBJRVRGLTk0DQo+ID4gaHR0cDovL3d3dy5pZXRm Lm9yZy9wcm9jZWVkaW5ncy85NC9zbGlkZXMvc2xpZGVzLTk0LXRzdndnLTE0LnBkZiBhbmQNCj4g PiBkaXNjdXNzZWQgaW4gdGhlIFdHLiBUaGUgY29uc2Vuc3VzIHdhcyB0byB1c2UgYm90aCBVRFAg YW5kIFRDUCwgYW5kDQo+ID4gSGFwcHkgZXllYmFsbHMgbWVjaGFuaXNtIHdpbGwgaGVscCByZWR1 Y2UgZGVsYXkgdG8gY29udmV5IERPVFMgc2lnbmFsLg0KPiA+IERPVFMgcmVxdWlyZW1lbnQgZHJh ZnQgZXhwbGFpbnMgdGhhdCBjb25uZWN0aW9ubGVzcyB0cmFuc3BvcnQgaXMNCj4gPiBzdHJvbmds eSByZWNvbW1lbmRlZCBhbmQgY29ubmVjdGlvbi1vcmllbnRlZCB0cmFuc3BvcnQgbWF5IGJlDQo+ IG5lY2Vzc2FyeSBkdWUgdG8gbmV0d29yayBwb2xpY3kgb3IgbWlkZGxld2FyZSBsaW1pdGF0aW9u cy4NCj4gDQo+IEkgdW5kZXJzdGFuZCB0aGUgY29uc2Vuc3VzIGlzIHRvIHN1cHBvcnQgYm90aCBU Q1AgYW5kIFVEUC4gIFRoYXQgbWFrZXMNCj4gc2Vuc2UuDQo+IA0KPiBXaXRoIHRoYXQgc2FpZCwg SSdtIG5vdCBzdXJlIHRoYXQgYSAqZGlzY292ZXJ5IG1lY2hhbmlzbSogKG9yIHRoZSBoYXBweQ0K PiBleWViYWxscyBtZWNoYW5pc20gc3BlY2lmaWNhbGx5KSBzaG91bGQgbmVjZXNzYXJpbHkgYmUg bWFuZGF0b3J5IGluIGFsbA0KPiBjYXNlcy4gIEluIGNhc2VzIHdoZXJlIHRoZSBwcm9wZXJ0aWVz IG9mIHRoZSBsaW5rIGFyZSBrbm93biAoZS5nLiBJJ20gbm90DQo+IHNob290aW5nIERPVFMgbm90 aWZpY2F0aW9uIHRocm91Z2ggdGhlIGxpbmsgdGhhdCdzIHVuZGVyIGF0dGFjaywgYnV0IGluc3Rl YWQNCj4gdGhyb3VnaCBhIGRpZmZlcmVudCAvIGRlZGljYXRlZCBsaW5rIHRoYXQgZS5nLiB1c2Vz IElQU0VDIHRvIGNvbW11bmljYXRlIHdpdGgNCj4gYW4gdXBzdHJlYW0gcHJvdmlkZXIgdGhhdCBj YW4gaGVscCBtZSBkZWZlbmQpLCBJIGRvbid0IHRoaW5rIGl0IG1ha2VzIGFzDQo+IG11Y2ggc2Vu c2UgdG8gZm9yY2UgYXV0by1kaXNjb3ZlcnkgaW4gdGhhdCBtYW5uZXIuICBBZGRpdGlvbmFsbHks IGlmIGhhcHB5DQo+IGV5ZWJhbGxzIGlzIGV4cGxpY2l0bHkgcmVxdWlyZWQgYnkgdGhlIGRvY3Vt ZW50LCBvbmx5IGhhcHB5IGV5ZWJhbGxzIG1heQ0KPiAqZXZlciogYmUgdXNlZCBieSBpbXBsZW1l bnRhdGlvbnMgdGhhdCB3aXNoIHRvIHN0cmljdGx5IGNvbmZvcm0gdG8gdGhlIERPVFMNCj4gc3Bl Y2lmaWNhdGlvbi4NCj4gDQo+IEZ1cnRoZXIsIHRoZSBzZWxlY3Rpb24gKG9yIG5vdCkgb2YgaGFw cHkgZXllYmFsbHMgZG9lcyBub3QgYWZmZWN0IGhvdw0KPiBpbXBsZW1lbnRhdGlvbnMgaW50ZXIt b3BlcmF0ZSB3aXRoIGVhY2ggb3RoZXIsIGFuZCB0aGVyZWZvcmUgaXNuJ3QNCj4gbmVjZXNzYXJp bHkgc29tZXRoaW5nIHRoYXQgbmVlZHMgdG8gYmUgc3RyaWN0bHkgZW5mb3JjZWQgaW4gb3JkZXIg dG8gYnVpbGQgYW4NCj4gaW1wbGVtZW50YXRpb24gb2YgRE9UUyB0aGF0IGNvbmZvcm1zIHdpdGgg dGhpcyBkcmFmdC4gIEl0ICppcyogZ2VuZXJhbGx5IGENCj4gZ29vZCBpZGVhIC4uLiBidXQgZnJv bSBhIHBoaWxvc29waGljYWwgc3RhbmRwb2ludCwgSSdtIHBlcnNvbmFsbHkgb3Bwb3NlZCB0bw0K PiB0aGUgaWRlYSBvZiAqZm9yY2luZyogYW55IHNwZWNpZmljIGRlY2lzaW9ucyB1cG9uIHRob3Nl IGltcGxlbWVudGluZyB0aGUNCj4gcHJvdG9jb2wgd2l0aG91dCBhIHZlcnkgZ29vZCByZWFzb24g dG8gZG8gc28uICBUaGlzIGlzIGVzcGVjaWFsbHkgdHJ1ZSBpbiBjYXNlcw0KPiB3aGVyZSB0aGVy ZSBpcyBhIGNoYW5jZSB0aGF0IHN1Y2ggYSBtYW5kYXRlIG1heSBsZWFkIHRvIHN1Ym9wdGltYWwN Cj4gcGVyZm9ybWFuY2UuDQoNCkdvdCBpdCwgd2lsbCBjaGFuZ2UgdG8gbm9uLW5vcm1hdGl2ZS4N Cg0KLVRpcnUNCg0KPiANCj4gQ2hlZXJzLA0KPiBHaWxiZXJ0DQo+IA0KPiBbMV0gUXVvdGluZyBz ZWN0aW9uIDMgb2YgUkZDIDc1NDA6ICJBbiBIVFRQLzIgY29ubmVjdGlvbiBpcyBhbiBhcHBsaWNh dGlvbi0NCj4gbGF5ZXIgcHJvdG9jb2wgcnVubmluZyBvbiB0b3Agb2YgYSBUQ1AgY29ubmVjdGlv biAoW1RDUF0pLiAgVGhlIGNsaWVudCBpcyB0aGUNCj4gVENQIGNvbm5lY3Rpb24gaW5pdGlhdG9y LiINCg== From nobody Thu Feb 18 23:35:23 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC521A00A0 for ; Thu, 18 Feb 2016 23:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8UjD3AX50Dw for ; Thu, 18 Feb 2016 23:35:21 -0800 (PST) Received: from smtp78.ord1c.emailsrvr.com (smtp78.ord1c.emailsrvr.com [108.166.43.78]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305EF1A0058 for ; Thu, 18 Feb 2016 23:35:21 -0800 (PST) Received: from smtp10.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp10.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 9D43038013F; Fri, 19 Feb 2016 02:35:20 -0500 (EST) X-Auth-ID: bgreene@senki.org Received: by smtp10.relay.ord1c.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id 1F8DC38013D; Fri, 19 Feb 2016 02:35:18 -0500 (EST) X-Sender-Id: bgreene@senki.org Received: from [192.168.100.181] ([UNAVAILABLE]. [210.213.241.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:25 (trex/5.5.4); Fri, 19 Feb 2016 02:35:20 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Barry Raveendran Greene In-Reply-To: <952cee8779a64dba8d7fa6abaf20c29d@XCH-RCD-017.cisco.com> Date: Fri, 19 Feb 2016 15:35:12 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <73F10903-2270-482B-AF11-090F82DC312E@senki.org> References: <952cee8779a64dba8d7fa6abaf20c29d@XCH-RCD-017.cisco.com> To: "Tirumaleswar Reddy (tireddy)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "gclark mti-systems.com" , "dots@ietf.org" Subject: Re: [Dots] FW: New Version Notification for draft-reddy-dots-transport-02.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 07:35:22 -0000 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.=20= From nobody Fri Feb 19 06:42:07 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C091B2D71 for ; Fri, 19 Feb 2016 06:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAtUhjE9qcFl for ; Fri, 19 Feb 2016 06:42:03 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.231.228]) by ietfa.amsl.com (Postfix) with ESMTP id 85EB41A903C for ; Fri, 19 Feb 2016 06:41:46 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 7EC204E60E for ; Fri, 19 Feb 2016 23:41:45 +0900 (JST) Received: from SR2-nishizuka.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 628373AC97 for ; Fri, 19 Feb 2016 23:41:45 +0900 (JST) References: <20160219143213.18440.22155.idtracker@ietfa.amsl.com> To: dots@ietf.org From: kaname nishizuka X-Forwarded-Message-Id: <20160219143213.18440.22155.idtracker@ietfa.amsl.com> Message-ID: <56C729D0.2080707@nttv6.jp> Date: Fri, 19 Feb 2016 23:42:24 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160219143213.18440.22155.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------060702070806040408010404" Archived-At: Subject: [Dots] Fwd: New Version Notification for draft-nishizuka-dots-inter-domain-mechanism-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 14:42:05 -0000 This is a multi-part message in MIME format. --------------060702070806040408010404 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, We submitted a new draft regarding to a cooperative DDoS protection. Summary of the draft: As DDoS attack evolves rapidly in the aspect of volume and sophistication, cooperation among operators for sharing the capacity of the protection system to cope with it becomes very necessary. This document describes some possible solutions to the cooperative DDoS protection problems. The inter-domain protocol (or signaling mechanism) for the goal of DDoS protection coordination is the main focus of this document. We're all happy to have discussions. Any comments and suggestions are welcome. thanks in advance, kaname -------- Forwarded Message -------- Subject: New Version Notification for draft-nishizuka-dots-inter-domain-mechanism-00.txt Date: Fri, 19 Feb 2016 06:32:13 -0800 From: internet-drafts@ietf.org To: Luyuan Fang , Kaname Nishizuka , Jinwei Xia , Dacheng Zhang , Liang Xia A new version of I-D, draft-nishizuka-dots-inter-domain-mechanism-00.txt has been successfully submitted by Kaname Nishizuka and posted to the IETF repository. Name: draft-nishizuka-dots-inter-domain-mechanism Revision: 00 Title: Inter-domain cooperative DDoS protection problems and mechanism Document date: 2016-02-19 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-nishizuka-dots-inter-domain-mechanism-00.txt Status: https://datatracker.ietf.org/doc/draft-nishizuka-dots-inter-domain-mechanism/ Htmlized: https://tools.ietf.org/html/draft-nishizuka-dots-inter-domain-mechanism-00 Abstract: As DDoS attack evolves rapidly in the aspect of volume and sophistication, cooperation among operators for sharing the capacity of the protection system to cope with it becomes very necessary. This document describes some possible solutions to the cooperative inter-domain DOTS problems. 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 --------------060702070806040408010404 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi all,

We submitted a new draft regarding to a cooperative DDoS protection.

Summary of the draft:
   As DDoS attack evolves rapidly in the aspect of volume and
   sophistication, cooperation among operators for sharing the capacity
   of the protection system to cope with it becomes very necessary.
   This document describes some possible solutions to the cooperative
   DDoS protection problems.
   The inter-domain protocol (or signaling mechanism) for the goal of
   DDoS protection coordination is the main focus of this document.

We're all happy to have discussions. Any comments and suggestions are welcome.

thanks in advance,
kaname


-------- Forwarded Message --------
Subject: New Version Notification for draft-nishizuka-dots-inter-domain-mechanism-00.txt
Date: Fri, 19 Feb 2016 06:32:13 -0800
From: internet-drafts@ietf.org
To: Luyuan Fang <lufang@microsoft.com>, Kaname Nishizuka <kaname@nttv6.jp>, Jinwei Xia <xiajinwei@huawei.com>, Dacheng Zhang <dacheng.zdc@aliabab-inc.com>, Liang Xia <frank.xialiang@huawei.com> 


A new version of I-D, draft-nishizuka-dots-inter-domain-mechanism-00.txt
has been successfully submitted by Kaname Nishizuka and posted to the
IETF repository.

Name:		draft-nishizuka-dots-inter-domain-mechanism
Revision:	00
Title:		Inter-domain cooperative DDoS protection problems and mechanism
Document date:	2016-02-19
Group:		Individual Submission
Pages:		22
URL:            https://www.ietf.org/internet-drafts/draft-nishizuka-dots-inter-domain-mechanism-00.txt
Status:         https://datatracker.ietf.org/doc/draft-nishizuka-dots-inter-domain-mechanism/
Htmlized:       https://tools.ietf.org/html/draft-nishizuka-dots-inter-domain-mechanism-00


Abstract:
   As DDoS attack evolves rapidly in the aspect of volume and
   sophistication, cooperation among operators for sharing the capacity
   of the protection system to cope with it becomes very necessary.
   This document describes some possible solutions to the cooperative
   inter-domain DOTS problems.

                                                                                  


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


--------------060702070806040408010404-- From nobody Fri Feb 19 07:13:41 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0B81B317D for ; Fri, 19 Feb 2016 07:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tD7b89fSK87P for ; Fri, 19 Feb 2016 07:13:38 -0800 (PST) Received: from atl4mhob18.myregisteredsite.com (atl4mhob18.myregisteredsite.com [209.17.115.111]) by ietfa.amsl.com (Postfix) with ESMTP id 7F07C1B317A for ; Fri, 19 Feb 2016 07:13:38 -0800 (PST) Received: from atl4oxapp110.mgt.hosting.qts.netsol.com ([10.30.71.186]) by atl4mhob18.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u1JFDaBK042444; Fri, 19 Feb 2016 10:13:36 -0500 Date: Fri, 19 Feb 2016 10:13:36 -0500 (EST) From: "gclark mti-systems.com" To: "Tirumaleswar Reddy (tireddy)" , dots@ietf.org Message-ID: <179321819.6310.1455894816825.JavaMail.vpopmail@atl4oxapp110.mgt.hosting.qts.netsol.com> In-Reply-To: <952cee8779a64dba8d7fa6abaf20c29d@XCH-RCD-017.cisco.com> References: <952cee8779a64dba8d7fa6abaf20c29d@XCH-RCD-017.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.6.2-Rev35 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Dots] FW: New Version Notification for draft-reddy-dots-transport-02.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "gclark mti-systems.com" List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 15:13:39 -0000 Hi! Inline: > 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 nobody Fri Feb 19 09:03:37 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7701B3269 for ; Fri, 19 Feb 2016 09:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LppnLA_rIpwA for ; Fri, 19 Feb 2016 09:03:21 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9E6D1AC3F0 for ; Fri, 19 Feb 2016 09:03:21 -0800 (PST) Received: by mail-pa0-x22a.google.com with SMTP id fl4so53289131pad.0 for ; Fri, 19 Feb 2016 09:03:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=NCAx/8L811HRfAN7xYBTwAqv9bwePi6zLSB/TroG9lI=; b=aolKytjE+is9jDOWU2gp95MEz7t0rROIRaXNvUKf32XQXI/02dUFi8Q7uvCp8HJRLd yBwjN+sB+8YDUUTJw8w/hBKy+OsS88J/6y4oU9k9XuaC7fwbdZ7fHT1W003VyzI/yux8 2Wx6ex3pXS3gPdXoszNJ6S8GfBC2IiaBbLMY4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=NCAx/8L811HRfAN7xYBTwAqv9bwePi6zLSB/TroG9lI=; b=kKj+8sBAohUVLKOgC/hCNdKjCgsVPhEZgOk6SpXFF9Y61PFl2btK1HxqKDux+sds7M oub0c19y4G5vJQJBnb8PdiccoR6QBT4Pc9lrvG+6utLGfvT96E6BWGZaKHVc2feeCHAT fqvXIoLBQbzZp27lAhAfcovB0P0Fz83xslD5bA5fZTUrTVyq3v2UvLba/Aid4vH7ceHn a8W+PfNVYoC8F0h3+qVacCpIb5x/AJtLn4Hx+oMcbtGz41UPsZYqlYWpffwo6gfcWhFL wX8/lUbBfoQww6ja+/J6LwiilBCfioZRsO38vLLqxykZSn6YeAzA/Df0zknMbRLDLgiK bPVg== X-Gm-Message-State: AG10YOTWuULsZnGfnqOU/eLu2Ubb70LZn7A/v6G/6l7GsU/OHDH0ONJj5SpJ8zzlV0TVvlat X-Received: by 10.66.248.168 with SMTP id yn8mr19635109pac.24.1455901401370; Fri, 19 Feb 2016 09:03:21 -0800 (PST) Received: from [172.19.254.138] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id xa9sm19110919pab.44.2016.02.19.09.03.19 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 19 Feb 2016 09:03:20 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Sat, 20 Feb 2016 00:03:17 +0700 Message-ID: <34F87D2A-9BFB-4C57-B25C-2501FEB654AE@arbor.net> In-Reply-To: <56C729D0.2080707@nttv6.jp> References: <20160219143213.18440.22155.idtracker@ietfa.amsl.com> <56C729D0.2080707@nttv6.jp> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5213) Archived-At: Subject: Re: [Dots] New Version Notification for draft-nishizuka-dots-inter-domain-mechanism-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 17:03:27 -0000 On 19 Feb 2016, at 21:42, kaname nishizuka wrote: > Any comments and suggestions are welcome. This draft is partially or wholly duplicative of draft-ietf-dots-use-cases-00, draft-ietf-dots-requirements-00, and draft-reddy-dots-transport-02; it is overly prescriptive (e.g., talk about flow telemetry); premature (e.g., talk about JSON, certs, message formats, and so forth); incomplete (doesn't mention relays at all); and contains factually incorrect statements (e.g., that provisioning must take place prior to an attack; in point of fact, one of the rationales for DOTS is that it allows for dynamic registration and auto-provisioning even during an attack). Have the submitters been following the discussions around the three drafts mentioned above? ----------------------------------- Roland Dobbins From nobody Sat Feb 20 11:33:25 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E481A909E for ; Sat, 20 Feb 2016 11:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.796 X-Spam-Level: ** X-Spam-Status: No, score=2.796 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOeY49I2Ys1O for ; Sat, 20 Feb 2016 11:33:22 -0800 (PST) Received: from atl4mhob21.registeredsite.com (unknown [209.17.115.115]) by ietfa.amsl.com (Postfix) with ESMTP id 456981A8AAC for ; Sat, 20 Feb 2016 11:33:22 -0800 (PST) Received: from atl4oxapp104.mgt.hosting.qts.netsol.com ([10.30.71.141]) by atl4mhob21.registeredsite.com (8.14.4/8.14.4) with ESMTP id u1KJXJlh122229; Sat, 20 Feb 2016 14:33:19 -0500 Date: Sat, 20 Feb 2016 14:33:19 -0500 (EST) From: "gclark mti-systems.com" To: "Tirumaleswar Reddy (tireddy)" , Barry Raveendran Greene Message-ID: <742256666.3638.1455996799480.JavaMail.vpopmail@atl4oxapp104.mgt.hosting.qts.netsol.com> In-Reply-To: <73F10903-2270-482B-AF11-090F82DC312E@senki.org> References: <952cee8779a64dba8d7fa6abaf20c29d@XCH-RCD-017.cisco.com> <73F10903-2270-482B-AF11-090F82DC312E@senki.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.6.2-Rev35 X-Originating-Client: open-xchange-appsuite Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] FW: New Version Notification for draft-reddy-dots-transport-02.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "gclark mti-systems.com" List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 19:33:23 -0000 Hi: > The worry is getting message upstream in a DoS. That is NOT a protocol > 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 From nobody Mon Feb 22 18:21:08 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24731B3C69 for ; Mon, 22 Feb 2016 18:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbbFZTZEieQJ for ; Mon, 22 Feb 2016 18:21:05 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:a::4]) by ietfa.amsl.com (Postfix) with ESMTP id 434D61B3C07 for ; Mon, 22 Feb 2016 18:21:05 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 8A3104E891; Tue, 23 Feb 2016 11:21:04 +0900 (JST) Received: from SR2-nishizuka.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 7C8133ACA8; Tue, 23 Feb 2016 11:21:04 +0900 (JST) To: Roland Dobbins , dots@ietf.org References: <20160219143213.18440.22155.idtracker@ietfa.amsl.com> <56C729D0.2080707@nttv6.jp> <34F87D2A-9BFB-4C57-B25C-2501FEB654AE@arbor.net> From: kaname nishizuka Message-ID: <56CBC23F.8070200@nttv6.jp> Date: Tue, 23 Feb 2016 11:21:51 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <34F87D2A-9BFB-4C57-B25C-2501FEB654AE@arbor.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] New Version Notification for draft-nishizuka-dots-inter-domain-mechanism-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 02:21:07 -0000 Hi Roland, I appreciate your comments. We are following discussions about those drafts on the ML, then, we thought that the problems of cooperative DDoS protection are not documented clearly so far. Thus we wrote that part in our draft and included mechanism part straightforwardly. The comparison between centralized and distributed architecture of coordination of DDoS protection service providers is useful especially for operators and will be on the track of discussion in course of time. Our draft is not intended to bypass the existing drafts but to extend important discussion points for specification. thank you, kaname On 2016/02/20 2:03, Roland Dobbins wrote: > On 19 Feb 2016, at 21:42, kaname nishizuka wrote: > >> Any comments and suggestions are welcome. > > This draft is partially or wholly duplicative of draft-ietf-dots-use-cases-00, draft-ietf-dots-requirements-00, and draft-reddy-dots-transport-02; it is overly prescriptive (e.g., talk about flow telemetry); premature (e.g., talk about JSON, certs, message formats, and so forth); incomplete (doesn't mention relays at all); and contains factually incorrect statements (e.g., that provisioning must take place prior to an attack; in point of fact, one of the rationales for DOTS is that it allows for dynamic registration and auto-provisioning even during an attack). > > Have the submitters been following the discussions around the three drafts mentioned above? > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Feb 24 00:52:41 2016 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA841B485D for ; Wed, 24 Feb 2016 00:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yAU7vYMnvSy for ; Wed, 24 Feb 2016 00:52:37 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95ADC1B4858 for ; Wed, 24 Feb 2016 00:52:37 -0800 (PST) Received: by mail-pa0-x235.google.com with SMTP id fy10so9213462pac.1 for ; Wed, 24 Feb 2016 00:52:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=oAs2viUP2UjE2SzxGNjUuN0NjEemB549qqt1vP9msZE=; b=ddlAWYi7j0PCTTzVzuCtyRTQfeBE8dOebBB1mnL12/UVXgiCTzKJuyvVs+fcphGA6H jHbo60TJiNFefRc5gXxjAEJGoRTdiMGilQQtA5IOCloNGjaXrwrzUvVyzg+nN76lkdpE G1u32IIFJnxEjO6zC6QEOM3KJMw24HS3ae5lg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=oAs2viUP2UjE2SzxGNjUuN0NjEemB549qqt1vP9msZE=; b=XoTHRgSssndPe+0gh8VskMPWupHm1tDc3HZ/PxkmAEAqIisrViL7YJ1CkDNeSfCSxj diHy2kx6tgMIVXtU+FvwH+w+ml+kzVkYr87qJOUY/hViuu0CV5yZ43LatREUdV0FW7pT naRyA4BJhwUtpqGfV0DzzTcO4txaN+CcJifgkamh6Kgly37iVUDSn4CGGxgkmyXmL20O o3UNCAgJLJf6c3ZtboAV/DZLFhdeZl0JFm5dKtUAqKqYFGudd8D8J32k01l15WARW8EO nfXFelKlhDM3Bu0mJjF3gjcUNGs2hEOsZLVoT3IC5OHrhPmGh5ZKvGrVBRmYkeDICmYi AeVA== X-Gm-Message-State: AG10YOS9DtCLXv16KItNQrZo0uCyGby9Ai59Du75n4T65+zw0C/O6fIJ+JIHpodZqvWfee20 X-Received: by 10.66.254.168 with SMTP id aj8mr53431608pad.18.1456303957217; Wed, 24 Feb 2016 00:52:37 -0800 (PST) Received: from [172.19.254.138] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id r5sm3155928pap.7.2016.02.24.00.52.35 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 24 Feb 2016 00:52:36 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 24 Feb 2016 15:52:31 +0700 Message-ID: <8F3BBFDC-76A7-416E-BA85-16A80F13EE69@arbor.net> In-Reply-To: <56CBC23F.8070200@nttv6.jp> References: <20160219143213.18440.22155.idtracker@ietfa.amsl.com> <56C729D0.2080707@nttv6.jp> <34F87D2A-9BFB-4C57-B25C-2501FEB654AE@arbor.net> <56CBC23F.8070200@nttv6.jp> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5226) Archived-At: Subject: Re: [Dots] New Version Notification for draft-nishizuka-dots-inter-domain-mechanism-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 08:52:40 -0000 On 23 Feb 2016, at 9:21, kaname nishizuka wrote: > Our draft is not intended to bypass the existing drafts but to extend > important discussion points for specification. It does not accomplish this goal, IMHO. Instead, it makes several unwarranted assumptions and factually incorrect statements about both the current state of DDoS mitigation and the projected enhancements to DDoS mitigation which are the goal of the DOTS WG. ----------------------------------- Roland Dobbins