From nobody Thu Feb 2 13:22:35 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B6D129581 for ; Thu, 2 Feb 2017 13:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 wW2vGmCSVjKN for ; Thu, 2 Feb 2017 13:22:34 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC646129505 for ; Thu, 2 Feb 2017 13:22:33 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v12LMWAc009441 for ; Thu, 2 Feb 2017 16:22:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1486070552; bh=f+My7Aea5CxGqsbwwVKYogpq0Ki7Mxzm+gk92fTFIL0=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version:Sender: Reply-To:Cc:In-Reply-To:References; b=SnVgJFOgj84XdZG0xlSGX3BFs6SM2Hhojv8U+wQu3DGHDz1JCyKjxP3OptNLrQduR 9KFNV89CrY/ATxFqy30zztKwyvm7L69VmXEZ5dVAEs3DilbgZ/qFnzJqbRNOFlutQg kTLvbAk0NewNdhqw2PCFY6KnftVotBsqJXgC6jS4= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v12LMVA9021643 for ; Thu, 2 Feb 2017 16:22:31 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0319.002; Thu, 2 Feb 2017 16:22:31 -0500 From: "Roman D. Danyliw" To: "dots@ietf.org" Thread-Topic: Virtual Interim Meeting in February 2017 Scheduling Poll Thread-Index: AdJ9mXuraWcYzb9LRM+GS4VXqLGTvA== Date: Thu, 2 Feb 2017 21:22:30 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104EF8558@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC0104EF8558marathon_" MIME-Version: 1.0 Archived-At: Subject: [Dots] Virtual Interim Meeting in February 2017 Scheduling Poll X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 02 Feb 2017 21:22:35 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC0104EF8558marathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello WG! Authors have been working hard among themselves to complete the actions fro= m our Seoul meeting, but limited on-list discussion has occurred. It is ti= me for us to synchronize with a virtual interim meeting. Help suggest the = best day during the week of February 20th by completing a Doodle poll -- ht= tp://doodle.com/poll/beht9kftmee7inbe. Your input would be appreciated by Wednesday, February 8, 2017. Regards, Roman --_000_359EC4B99E040048A7131E0F4E113AFC0104EF8558marathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello WG!

 

Authors have been working hard among themselves to c= omplete the actions from our Seoul meeting, but limited on-list discussion = has occurred.  It is time for us to synchronize with a virtual interim= meeting.  Help suggest the best day during the week of February 20th by completing a Doodle poll -- http://doodle.com/poll/beht9kftmee7inbe. 

 

Your input would be appreciated by Wednesday, Februa= ry 8, 2017.

 

Regards,

Roman

--_000_359EC4B99E040048A7131E0F4E113AFC0104EF8558marathon_-- From nobody Tue Feb 7 05:56:17 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE845129BFE for ; Tue, 7 Feb 2017 05:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 9xdPdNWxbEce for ; Tue, 7 Feb 2017 05:56:14 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E03129547 for ; Tue, 7 Feb 2017 05:56:14 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v17DuCLI018974 for ; Tue, 7 Feb 2017 08:56:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1486475772; bh=HolEBKln8HDwBWnnqimlCk3FwaxexGqU/dVp0cJaRkI=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version:Sender: Reply-To:Cc:In-Reply-To:References; b=GTaUT9lZReIWtPVjSaJlRvL+0sjW0m8HL871+FkGAst+3QfGQJqzV6g5Gys8ZDI7h rtUtRftPA+7N6jGADILYuZyCKDB7c84f4TXosDAN42z3dQhn0fD+iNylYOZwKJgxeT SjhhksHPWvXPwSmZyMi7Wmva1i+ngznIQL1UhLz4= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v17DuC0O016503 for ; Tue, 7 Feb 2017 08:56:12 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0319.002; Tue, 7 Feb 2017 08:56:11 -0500 From: "Roman D. Danyliw" To: "dots@ietf.org" Thread-Topic: REMINDER: Virtual Interim Meeting in February 2017 Scheduling Poll Thread-Index: AdKBSZCMv6BebWjIR4uJJqJ7Fhvgyg== Date: Tue, 7 Feb 2017 13:56:10 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104EFB9D8@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC0104EFB9D8marathon_" MIME-Version: 1.0 Archived-At: Subject: [Dots] REMINDER: Virtual Interim Meeting in February 2017 Scheduling Poll X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 07 Feb 2017 13:56:16 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC0104EFB9D8marathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello WG! As a reminder, the poll on scheduling the interim meeting this month closes= tomorrow. If you haven't shared your availability yet please go to the po= ll -- http://doodle.com/poll/beht9kftmee7inbe. Also, if you'd like time on the agenda, please send a request to the chairs= . Regards, Roman From: Roman D. Danyliw Sent: Thursday, February 02, 2017 4:22 PM To: dots@ietf.org Subject: Virtual Interim Meeting in February 2017 Scheduling Poll Hello WG! Authors have been working hard among themselves to complete the actions fro= m our Seoul meeting, but limited on-list discussion has occurred. It is ti= me for us to synchronize with a virtual interim meeting. Help suggest the = best day during the week of February 20th by completing a Doodle poll -- ht= tp://doodle.com/poll/beht9kftmee7inbe. Your input would be appreciated by Wednesday, February 8, 2017. Regards, Roman --_000_359EC4B99E040048A7131E0F4E113AFC0104EFB9D8marathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello WG!

 

As a reminder, the pol= l on scheduling the interim meeting this month closes tomorrow.  If yo= u haven’t shared your availability yet please go to the poll -- http://doodle.co= m/poll/beht9kftmee7inbe.

 

Also, if you’d l= ike time on the agenda, please send a request to the chairs.

 

Regards,

Roman

 

From: Roman D. Danyliw
Sent: Thursday, February 02, 2017 4:22 PM
To: dots@ietf.org
Subject: Virtual Interim Meeting in February 2017 Scheduling Poll

 

Hello WG!

 

Authors have been working hard among themselves to c= omplete the actions from our Seoul meeting, but limited on-list discussion = has occurred.  It is time for us to synchronize with a virtual interim= meeting.  Help suggest the best day during the week of February 20th by completing a Doodle poll -- http://doodle.com/poll/beht9kftmee7inbe. 

 

Your input would be appreciated by Wednesday, Februa= ry 8, 2017.

 

Regards,

Roman

--_000_359EC4B99E040048A7131E0F4E113AFC0104EFB9D8marathon_-- From nobody Wed Feb 8 05:51:19 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4326B129A59 for ; Wed, 8 Feb 2017 05:51:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 LaoqMfOMY0Tk for ; Wed, 8 Feb 2017 05:51:16 -0800 (PST) Received: from mailout1.radware.com (mailout1.radware.com [192.115.180.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0761293D6 for ; Wed, 8 Feb 2017 05:51:14 -0800 (PST) Received: from ILMB1.corp.radware.com ([169.254.1.252]) by ILCAS2.corp.radware.com ([176.200.120.122]) with mapi id 14.03.0319.002; Wed, 8 Feb 2017 15:51:12 +0200 From: Ehud Doron To: 'dots' Thread-Topic: Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . Thread-Index: AdKCER/slEaaT/pbTQCa8ffUgEh/Yg== Date: Wed, 8 Feb 2017 13:51:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [176.200.121.205] x-tm-as-product-ver: SMEX-11.0.0.4179-8.100.1062-22872.006 x-tm-as-result: No--14.660500-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E58182C4A35A8E498E553AD3D33FA001011717E1DFILMB1corpradw_" MIME-Version: 1.0 Archived-At: Cc: David Aviv Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 08 Feb 2017 13:51:18 -0000 --_000_E58182C4A35A8E498E553AD3D33FA001011717E1DFILMB1corpradw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tiru and authors Hi Attached please find my comments and feedbacks to draft-reddy-dots-signal-c= hannel-07 and draft-reddy-dots-data-channel-03 . Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel = draft-reddy-dots-signal-channel-07 1. General comment: For all signals in the draft, need to add means t= o allow vendor specific attributes as part of all signals transactions 2. General comment: Just for clarity, need to explicitly mention on e= ach figure when it is an example or the actual API 3. Page 3 second paragraph : DOTS should not be limited to "enterpris= e network" only . 4. Page 4 chapter 4: The overall context of the "happy eyeballs" and = its relations (or coexistence) to CoAP is not clear. 5. Page 7 chapter 5.2.1: The need for YANG model cannot be understood= from text. What are the needs for YANG models? What is the relation to the= JSONs in the other chapters in the draft 6. Page 14 figure 5: The mitigation request attributes are right but = not enough. Need to add more telemetry info about the actual attack that it= is required to mitigate, need to consider attributes in draft-doron-dots-t= elemetry-00 as part of the discussion in the WG. 7. Page 15 Life time attribute: More reasonable to have this attribut= e in minutes rather than seconds, bigger default can also suggested 8. Page 15 last paragraph: Not sure that target port or target protoc= ol can define a protected entity. IP, FQDN, URI are the only "stand alone" = attributes , port and protocol are companion attributes. See also figure 9 = . 9. Page 15 last paragraph: The mitigation request is not clear, to wh= ich identifier the text is related ? "policy ID" ? I think the best is ha= ve another attribute to define the priority of mitigation requests 10. Page 21 table: The return status are right but not enough. Need to ad= d more telemetry info about the actual mitigation going on (how much traffi= c was mitigated) and the attack that are mitigated, need to consider attrib= utes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. 11. Page 15 : Need to find the way to bind the target-ips with target-por= t-ranges and target-protocols, meaning that the server needs to understand = the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on = so forth. 12. Page 21 last paragraph: This is very strong point. 13. Page 25 : Regarding attack status, same point about telemetry. 14. Page 25 chapter 5.4: I believe it can valuable to add a short high le= vel description about the proposed API flow, same as you did for 5.3 . 15. Page 27: The necessity of policy_id here is not clear enough, are th= e "Signal Channel Session Configuration" define only "single" DOTS session = or the entire communication between Client and Server for several DOTS requ= est for mitigation? 16. Page 27: Not sure about the reason for "at least one of the attribute= s heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor = MUST be present." Also consider to change to "presented". 17. Page 30 chapter 5.5: Need to specify the overall scenario, in reactio= n to which signal (or API transaction POST of Mitigation Request , unidirec= tional notification from Server as describes in page 23 in page 21 ?) the = redirection occurred ? Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel dr= aft-reddy-dots-data-channel-03 1. General comment: For all signal in the draft, need to add means to= allow vendor specific attributes as part of all signals transactions 2. Page 5 second paragraph: Why it is required to configure the DOTS = signal channel session ? 3. Page 8 chapter 3.2.1 : Any reason for not including these identifi= ers in the DOTS signal channel draft ? 4. Page 9 figure 3 : Need to find the way to bind the target-ips with= target-port-ranges and target-protocols, meaning that the server needs to = understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53= and so on so forth. 5. Page 13 chapter 3.3 : Need to emphasize that filtering rules are r= elevant for both client server direct communication and through a DOTS gate= way. The chapter is a bit confusing. 6. Page 14 chapter 3.3 : I am missing the white-list installation, is= it by using the permit action ? 7. Page 15 figure 8: For DDoS it is highly valuable to have rate limi= t as an action. Consider adding such action (if already defined need to exp= lain where and how). 8. Page 15 figure 8: Need to consider adding priority to an ACL to su= pport cases when several filtering rules are conflicting. 9. Page 15 : The action field cannot be optional attribute. 10. Page 16 chapter 3.3.3: Need to add more telemetry info about the actu= al traffic that was blocked (bps, pps and so on), but as I believe this mig= ht be another issue... Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 --_000_E58182C4A35A8E498E553AD3D33FA001011717E1DFILMB1corpradw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tiru and authors Hi

 

Attached please find m= y comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-re= ddy-dots-data-channel-03 .

 

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy= -dots-signal-channel-07

 

1.     &= nbsp; General comment: For all s= ignals in the draft, need to add means to allow vendor specific attributes = as part of all signals transactions

 

2.&n= bsp;      General comment: Ju= st for clarity, need to explicitly mention on each figure when it is an exa= mple or the actual API

 

3.     &= nbsp; Page 3 second paragraph : = DOTS should not be limited to “enterprise network” only

.

4.     &= nbsp; Page 4 chapter 4: The over= all context of the “happy eyeballs” and its relations (or coexi= stence) to CoAP is not clear.  

 

5.     &= nbsp; Page 7 chapter 5.2.1: The = need for YANG model cannot be understood from text. What are the needs for = YANG models? What is the relation to the JSONs in the other chapters in the= draft

 

6.     &= nbsp; Page 14 figure 5: The miti= gation request attributes are right but not enough. Need to add more teleme= try info about the actual attack that it is required to mitigate, need to c= onsider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

7.     &= nbsp; Page 15 Life time attribut= e: More reasonable to have this attrib= ute in minutes rather than seconds, bigger default can also suggested

 

8.     &= nbsp; Page 15 last paragraph: Not sure that target port or target prot= ocol can define a protected entity. IP, FQDN, URI are the only “stand= alone” attributes , port and protocol are companion attributes. See also figure 9 .

 

9.     &= nbsp; Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is= related ?   “policy ID” ? I think the best is have a= nother attribute to define the priority of mitigation requests

 

10.&= nbsp;  Page 21 table: The = return status are right but not enough. Need to add more telemetry info abo= ut the actual mitigation going on (how much traffic was mitigated) and the = attack that are mitigated, need to consider attributes in draft-doron-dots-tele= metry-00 as part of the discussion in the WG.

 

11.   Page 15 : Need to find the= way to bind the target-ips with target-port-ranges and targe= t-protocols, meaning that the server needs to understand the exact s= cope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

12.   Page 21 last paragraph: Th= is is very strong point.

 

13.   Page 25 : Regarding attack= status, same point about telemetry.

 

14.   Page 25 chapter 5.4: I bel= ieve it can valuable to add a short high level description about the propos= ed API flow, same as you did for 5.3 .

 

15.   Page 27:  The necessi= ty of policy_id here is not clear enough, are the “Signal Channel Ses= sion Configuration” define only “single” DOTS session or = the entire communication between Client and Server for several DOTS request for mitigation?

 

16.   Page 27: Not sure about th= e reason for “at least one of the attributes heartbeat-interval or ma= x-retransmit or ack-timeout or ack-random-factor MUST be present.” Al= so consider to change to “presented”.

 

17.   Page 30 chapter 5.5: Need = to specify the overall scenario, in reaction to which signal (or API transa= ction POST of Mitigation Request , unidirectional notification from Server = as describes in page 23 in page 21 ?) the  redirection occurred ?

 

 

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-d= ots-data-channel-03

 

1.     &= nbsp; General comment: For all s= ignal in the draft, need to add means to allow vendor specific attributes a= s part of all signals transactions

 

2.     &= nbsp; Page 5 second paragraph: W= hy it is required to configure the DOTS signal channel session ?  

 

3.     &= nbsp; Page 8 chapter 3.2.1 : Any= reason for not including these identifiers in the DOTS signal channel draf= t ?

 

4.     &= nbsp; Page 9 figure 3 : Need to = find the way to bind the target-ips with target-port-ranges a= nd target-protocols, meaning that the server needs to understand the= exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

5.     &= nbsp; Page 13 chapter 3.3 : Need= to emphasize that filtering rules are relevant for both client server dire= ct communication and through a DOTS gateway. The chapter is a bit confusing= .

 

6.     &= nbsp; Page 14 chapter 3.3 : I am= missing the white-list installation, is it by using the permit action ?

 

7.     &= nbsp; Page 15 figure 8: For DDoS= it is highly valuable to have rate limit as an action. Consider adding suc= h action (if already defined need to explain where and how).

 

8.     &= nbsp; Page 15 figure 8: Need to = consider adding priority to an ACL to support cases when several filtering = rules are conflicting.

 

9.     &= nbsp; Page 15 : The action field= cannot be optional attribute.

 

10.   Page 16 chapter 3.3.3: Nee= d to add more telemetry info about the actual traffic that was blocked (bps= , pps and so on), but as I believe this might be another issue…

 

 

 

Thanks,

 

Ehud Doron <= span dir=3D"RTL">|  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

 

--_000_E58182C4A35A8E498E553AD3D33FA001011717E1DFILMB1corpradw_-- From nobody Thu Feb 9 09:03:42 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7696F129C06 for ; Thu, 9 Feb 2017 09:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 mx9M3UVWkPGc for ; Thu, 9 Feb 2017 09:03:39 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72FEC129BF6 for ; Thu, 9 Feb 2017 09:03:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=160; q=dns/txt; s=iport; t=1486659819; x=1487869419; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=uBg/mgxneb6DWS1XFqINB9Qul7PlWOjggHXBhgt9VkM=; b=gcNOF4FPeAFWsOfafHzd3zrKwbaijNcubgfdbyT/P4KhL3tPXAnwvLeQ 9dQV7wfD3to6MaaMIi6NRMABXIxxzyuwoUJF+enQ0Jz+mmGRcGexQj20h HrIuB2ofj0gruuy5Zmxb0LiHVHxVhdmwbjTAxkfmZ0nq1gKkT5Rklu38v w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAwCFn5xY/4QNJK1dHAEBBAEBCgEBg?= =?us-ascii?q?1FhAyeEOIoIkWqTRoIPggwqiGU/GAECAQEBAQEBAWIohRMVdgImAl8NCAEBiWM?= =?us-ascii?q?NDqAPkAGCJYtSAQEBBwEBAQEfBYELhUGCBQiKPIJfBZBBiy+GbYslgWMBiFuGR?= =?us-ascii?q?pMTHzg6RDIdFYccIokzAQEB?= X-IronPort-AV: E=Sophos;i="5.35,137,1484006400"; d="scan'208";a="381709788" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 17:03:38 +0000 Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v19H3cHJ016768 for ; Thu, 9 Feb 2017 17:03:38 GMT To: dots From: Flemming Andreasen Message-ID: Date: Thu, 9 Feb 2017 12:03:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Dots] DOTS Minutes from IETF97 ? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 09 Feb 2017 17:03:40 -0000 Hi I don't see the DOTS minutes from IETF 97 at https://datatracker.ietf.org/meeting/97/proceedings. Are they somewhere else ? Thanks -- Flemming From nobody Thu Feb 9 13:13:38 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7401294BC for ; Thu, 9 Feb 2017 13:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 69H2OEm-3s1o for ; Thu, 9 Feb 2017 13:13:35 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E12E1294CF for ; Thu, 9 Feb 2017 13:13:35 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v19LDYZq018638 for ; Thu, 9 Feb 2017 16:13:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1486674814; bh=LNFgT5lPVDi3RHuEaj/vK2e43qquZDYaTGvbOcmLbzs=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version:Sender: Reply-To:Cc:In-Reply-To:References; b=APk3Q3roK9r8Qn1FiUCKHnwmQ+CsXFIAH2yYSlBdVwOoPJD3RJOTFWWctwFTxGXsW 35kvKWCOR11t9Tw4by0SYo1Cp3ziM53Jln6xjN5rzynMKgQ0GJlW+vQIeMsh893QSh WMCF3hkA/RyBPKrbW1CMp12dvqrkjOzb8w4XUaeU= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v19LDXV4032554 for ; Thu, 9 Feb 2017 16:13:33 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 16:13:33 -0500 From: "Roman D. Danyliw" To: "dots@ietf.org" Thread-Topic: Virtual Interim Meeting: Wednesday, February 22, 2017 Thread-Index: AdKC/5H6tya1Ls5hRqqyc0QuxDPg/Q== Date: Thu, 9 Feb 2017 21:13:32 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104EFDFDA@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/mixed; boundary="_002_359EC4B99E040048A7131E0F4E113AFC0104EFDFDAmarathon_" MIME-Version: 1.0 Archived-At: Subject: [Dots] Virtual Interim Meeting: Wednesday, February 22, 2017 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 09 Feb 2017 21:13:37 -0000 --_002_359EC4B99E040048A7131E0F4E113AFC0104EFDFDAmarathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello WG! A DOTS virtual interim meeting has been scheduled for Wednesday, February 2= 2, 2017 from 15:00 - 1630 UTC. Thank you to all that responded to the scheduling poll. We recognize this = time was not able to accommodate everyone. =20 =09 Please send any requests for time on the agenda to the chairs. =3D=3D[ Date/Time ]=3D=3D Wednesday, February 22, 2017 3:00 - 4:30 PM UTC Start time in select local time zones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D San Francisco, USA Wed, February 22, 2017 at 7:00:00 am PST UTC-8 hours=20 New York, USA Wed, February 22, 2017 at 10:00:00 am EST UTC-5 hours=20 London, UK Wed, February 22, 2017 at 3:00:00 pm GMT UTC =20 UTC (GMT) Wed, February 22, 2017 at 3:00:00 pm =20 New Delhi, India Wed, February 22, 2017 at 8:30:00 pm IST UTC+5:30 hour= s=20 Berlin, Germany Wed, February 22, 2017 at 4:00:00 pm CET UTC+1 hour =20 Bangkok, Thailand Wed, February 22, 2017 at 10:00:00 pm ICT UTC+7 hours=20 Beijing, China Wed, February 22, 2017 at 11:00:00 pm CST UTC+8 hours=20 =3D=3D[ Working Agenda ]=3D=3D (Please send any requests for time on the agenda to the chairs) 1. Note well, logistics and introduction =20 2. Use Case Discussion 3. Requirements Discussion 4. Architecture Discussion 5. Data and Information Model(s) Discussion 6. Protocol Drafts 7. Open Mic 8. Closing =3D=3D[ WebEx Information ]=3D=3D Meeting URL: https://ietf.webex.com/ietf/j.php?MTID=3Dm16c3d7c775e02a7b3b8e12dc7753c778 Meeting number: 646 802 945 Meeting password: PVNMU3yM =20 Dial-in Numbers: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 646 802 945 =3D=3D=3D=3D Roman --_002_359EC4B99E040048A7131E0F4E113AFC0104EFDFDAmarathon_ Content-Type: text/calendar; name="WebEx_Meeting.ics" Content-Description: WebEx_Meeting.ics Content-Disposition: attachment; filename="WebEx_Meeting.ics"; size=3648; creation-date="Thu, 09 Feb 2017 21:07:46 GMT"; modification-date="Thu, 09 Feb 2017 21:07:08 GMT" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDE1MTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE1MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSJERG9TIE9wZW4gVGhy ZWF0IFNpZ25hbGluZyBXb3JraW5nIEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPUZB TFNFOk1BSUxUTzpkb3RzLWNoYWlyc0BpZXRmLm9yZwpPUkdBTklaRVI7Q049IndlYmV4IjpNQUlM VE86bWVzc2VuZ2VyQHdlYmV4LmNvbQpEVFNUQVJUO1RaSUQ9IkVhc3Rlcm4gVGltZSI6MjAxNzAy MjJUMTAwMDAwCkRURU5EO1RaSUQ9IkVhc3Rlcm4gVGltZSI6MjAxNzAyMjJUMTEzMDAwCkxPQ0FU SU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0ZgpUUkFOU1A6T1BBUVVFClNFUVVFTkNFOjE0 ODY2NzQyNTMKVUlEOmU5YjE1ZmU4LWIwODgtNGI5Ny05MDFjLWRlMDdiOGM0OGI5OQpEVFNUQU1Q OjIwMTcwMjIyVDE1MDAwMFoKREVTQ1JJUFRJT046XG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWYwZGIwNDA5ZDU2NTEyOTZmM2Nk MWUzZDdlMmU0NThhXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDYgODAyIDk0NVxu TWVldGluZyBwYXNzd29yZDogUFZOTVUzeU1cblxuXG5cbkpPSU4gQlkgUEhPTkVcbjEtODc3LTY2 OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKSBcbjEtNjUwLTQ3OS0z MjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblxuVG9sbC1mcmVlIGRpYWxpbmcg cmVzdHJpY3Rpb25zOiBcbmh0dHBzOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJp Y3Rpb25zLnBkZlxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0 IGhlcmU6XG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9U SUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5k IG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVk LCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBZb3Ugc2hvdWxk IGluZm9ybSBhbGwgbWVldGluZyBhdHRlbmRlZXMgcHJpb3IgdG8gcmVjb3JkaW5nIGlmIHlvdSBp bnRlbmQgdG8gcmVjb3JkIHRoZSBtZWV0aW5nLlxuClgtQUxULURFU0M7Rk1UVFlQRT10ZXh0L2h0 bWw6CTxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklB TCI+CQk8YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tZjBk YjA0MDlkNTY1MTI5NmYzY2QxZTNkN2UyZTQ1OGEiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjMDBB RkY5IiBGQUNFPSJBcmlhbCI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9GT05UPjwvYT4JCQk8dGFibGU+ CQkJCTx0cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0NiA4MDIgOTQ1PC9GT05U PgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxlPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRk PjwvdGQ+CQkJCTwvdHI+CQkJPC90YWJsZT4JCQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwv dGQ+PHRkPjxGT05UIFNJWkU9IjIiICBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPlBWTk1V M3lNPC9GT05UPjwvdGQ+PC90cj48L3RhYmxlPgkJPC9GT05UPjxicj48Rk9OVCBzaXplPSIyIiBD T0xPUj0iI0ZGMDAwMCI+PC9GT05UPjxicj48Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5i c3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05U IFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9O VD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+ PHN0cm9uZz4xLTg3Ny02NjgtNDQ5Mzwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51 bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4xLTY1MC00NzktMzIwODwvc3Ryb25nPiZuYnNw O0NhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48YSBocmVm PSJodHRwczovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYiPjxG T05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+VG9sbC1mcmVlIGNhbGxp bmcgcmVzdHJpY3Rpb25zPC9GT05UPjwvYT4gJm5ic3A7IDxCUj48L0ZPTlQ+PEJSPjxCUj4JJm5i c3A7PEJSPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPgkJCQlD YW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD4JPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4 LmNvbS9pZXRmL21jIj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFs Ij5Db250YWN0IHN1cHBvcnQuPC9GT05UPjwvYT4JJm5ic3A7PEJSPiZuYnNwOzxCUj48Rk9OVCBD T0xPUj0iI0EwQTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJpYWwiPklNUE9SVEFOVCBOT1RJQ0U6IFBs ZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIg aW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNo IG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIFlvdSBzaG91bGQgaW5mb3Jt IGFsbCBtZWV0aW5nIGF0dGVuZGVlcyBwcmlvciB0byByZWNvcmRpbmcgaWYgeW91IGludGVuZCB0 byByZWNvcmQgdGhlIG1lZXRpbmcuPC9GT05UPjwvRk9OVD4KU1VNTUFSWTpERG9TIE9wZW4gVGhy ZWF0IFNpZ25hbGluZyAoRE9UUykgV0cgVmlydHVhbCBJbnRlcmltIE1lZXRpbmcKUFJJT1JJVFk6 NQpDTEFTUzpQVUJMSUMKQkVHSU46VkFMQVJNClRSSUdHRVI6LVBUNU0KQUNUSU9OOkRJU1BMQVkK REVTQ1JJUFRJT046UmVtaW5kZXIKRU5EOlZBTEFSTQpFTkQ6VkVWRU5UCkVORDpWQ0FMRU5EQVIK --_002_359EC4B99E040048A7131E0F4E113AFC0104EFDFDAmarathon_-- From nobody Sun Feb 12 08:20:13 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F36129893 for ; Sun, 12 Feb 2017 08:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com 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 VMUkG0k5b9av for ; Sun, 12 Feb 2017 08:20:09 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0120.outbound.protection.outlook.com [104.47.38.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E66129A66 for ; Sun, 12 Feb 2017 08:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TquW7+vBCNxIkGVOI5T07nIkDmQl95ZjaRn9T3fGnMc=; b=asAONtKg4BeV4+wwH0jjH6yM+XpX0AqlA8clQcLyhWOQcb2YaWNfVXWa3H7XCZ3boBH/k+tZ3dBz20XLQMmlqaXo9JiZ2CPISLViAcV3bQo/+JwvGCUyykDE/MM6XxeHc0Ym0iBWKtrCDfLCWI4ifzkQpdYlqiUoAo7Tpdt5/rc= Received: from MWHPR0101MB3118.prod.exchangelabs.com (10.174.167.145) by MWHPR0101MB3118.prod.exchangelabs.com (10.174.167.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Sun, 12 Feb 2017 16:20:05 +0000 Received: from MWHPR0101MB3118.prod.exchangelabs.com ([10.174.167.145]) by MWHPR0101MB3118.prod.exchangelabs.com ([10.174.167.145]) with mapi id 15.01.0888.030; Sun, 12 Feb 2017 16:20:05 +0000 From: "Mortensen, Andrew" To: "dots@ietf.org" Thread-Topic: use of restconf for the data channel? Thread-Index: AQHShUvelq2Fax0X1U+DAQQ/dairhg== Date: Sun, 12 Feb 2017 16:20:05 +0000 Message-ID: <6AE56175-DBE7-4CD9-BA4E-5DCA88E901D8@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=amortensen@arbor.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [76.206.42.128] x-ms-office365-filtering-correlation-id: f4055848-4736-4c33-ee6d-08d45363016e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:MWHPR0101MB3118; x-microsoft-exchange-diagnostics: 1; MWHPR0101MB3118; 7:V8tHkeJ6/KDE8siqsrpeiEe+HuQDFAm1tAGHp/QKsmBXdB8RRsKCZBsSl0GPriJnxHW5HbtqG37Lm2ssoWiFMhiyJjY9OGwjXGDDHTo0qoELjQyXM9vDYRp+1+Fq6kMpJGrNBEM88ItBZiRFBIStB8NpJnGvYBMbgni5FuI1h5whpaCBvm0iWvwZYEbsu9rkP3kyXGJqfWVZ+No5EGyWSxoSGVZTub5PRQJYxlW+Auqy9srUK61ALhVTx2rp6363spkFGnwtz9Za37Z3XZWA0Jk7UDD3pjthTECVNOZwpCxRRDBjO4s1xyvCotiW1XJgQ16Hdb5uSmmprkimvJaklWWZcQa+5IE+X0tAiLx8mnQYMqHKRpWRBwr5wQK1DBahw0kcpLH/vNC8lXBmSU8D6oAbsvCpUHwC+5KWCkJtkf3A+Ns9qtGCmSW82MOIgng1rIy1hMvQqk78HNBEfpS4SaL5yi8RuV9bG8Pnvu4uohZ/tNRAyx2vDzCdP6s2cmdXa3VMgdgBtMOBknrOJWeL0Q== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123558025)(20161123560025)(20161123562025)(6072148); SRVR:MWHPR0101MB3118; BCL:0; PCL:0; RULEID:; SRVR:MWHPR0101MB3118; x-forefront-prvs: 021670B4D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(199003)(189002)(8936002)(105586002)(101416001)(66066001)(6116002)(102836003)(561944003)(33656002)(3846002)(2501003)(97736004)(1730700003)(81166006)(81156014)(8676002)(86362001)(575784001)(36756003)(7906003)(7736002)(6486002)(77096006)(6512007)(54896002)(6306002)(3660700001)(82746002)(6916009)(106356001)(99286003)(2900100001)(25786008)(236005)(606005)(450100001)(189998001)(68736007)(6436002)(5640700003)(6506006)(3280700002)(110136004)(38730400002)(2351001)(5660300001)(54356999)(50986999)(92566002)(106116001)(53936002)(83716003)(122556002)(2906002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR0101MB3118; H:MWHPR0101MB3118.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_6AE56175DBE74CD9BA4E5DCA88E901D8arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2017 16:20:05.5706 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0101MB3118 Archived-At: Subject: [Dots] use of restconf for the data channel? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 12 Feb 2017 16:20:11 -0000 --_000_6AE56175DBE74CD9BA4E5DCA88E901D8arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGRhdGEgY2hhbm5lbCBwcm9wb3NlZCBpbiBkcmFmdC1yZWRkeS1kb3RzLWRhdGEtY2hhbm5l bCAoYW5kIHByZXZpb3VzbHkgaW4gZHJhZnQtcmVkZHktZG90cy10cmFuc3BvcnQpIGhhcyBldm9s dmVkIG92ZXIgdGhlIHBhc3QgeWVhciBmcm9tIHVzaW5nIEhUVFAgYW5kIGEgbGltaXRlZCBSRVNU IEFQSSwgdG8gYSBDb0FQIGZvcm0gb2YgdGhlIHNhbWUsIHRvIHVzaW5nIFJFU1RDT05GIGluIHRo ZSBjdXJyZW50IHJldmlzaW9uLiBUaGF0IGV2b2x1dGlvbiBzZWVtcyBpbiBwYXJ0IGRyaXZlbiBi eSB0aGlzIHRocmVhZCBmcm9tIE5vdmVtYmVyOg0KDQo8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRm Lm9yZy9hcmNoL3NlYXJjaC8/ZW1haWxfbGlzdD1kb3RzJmluZGV4PWN2Qi1YRWtZLWdqRVdQUkJL bUltMGJ1XzZpdyZnYnQ9MT4NCg0KIEl0IHNlZW1zIHRvIG1lIGluIHBhcnRpY3VsYXIgdGhpcyBl eGNoYW5nZSBzZWVtcyB0byBiZSB0aGUgY2F0YWx5c3QgZm9yIHRoZSBjdXJyZW50IGNob2ljZSBv ZiBSRVNUQ09ORjoNCg0K4oCcU28sIGlmIHlvdXIgQ0JPUiB3YXMgZGVyaXZlZCBmcm9tIGEgWUFO RyBtb2RlbCwgeW914oCZZCBiZSBkb2luZyBleGFjdGx5IE5FVENPTkYsIGJ0dy4NCg0KPGh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvZG90cy9BZmhoRGRoQVB2a0d5VXVteDZT QjRUYnlpNGc+DQoNCkEgbnVtYmVyIG9mIGNvbnRyaWJ1dG9ycyB0byB0aGUgdGhyZWFkIHJhaXNl ZCBvYmplY3Rpb25zIHRvIHVzaW5nIE5FVENPTkYvUkVTVENPTkYuIFRoZSBjb25jZXJucywgYXMg SSByZWFkIHRoZW0sIGFyZSBtb3N0bHkgYWJvdXQgdXNpbmcgTkVUQ09ORi9SRVNUQ09ORiBhcyB0 aGUgcHJvdG9jb2wgZm9yIHRoZSBzaWduYWwgY2hhbm5lbCwgYnV0IHRoYXQgbWF5IGJlIGJlY2F1 c2UgSeKAmXZlIGFsc28gcHJvcG9zZWQgdXNpbmcgUkVTVENPTkYgZm9yIHRoZSBkYXRhIGNoYW5u ZWwgaW4gdGhlIHBhc3QuIFsxXQ0KDQpTaW5jZSBSRVNUQ09ORiBpcyBub3cgYSBjb25jcmV0ZSBw cm9wb3NhbCwgaXQgc2VlbXMgd29ydGh3aGlsZSBjb250aW51aW5nIHRoZSBkZWJhdGUgYWhlYWQg b2YgdGhlIGludGVyaW0gbWVldGluZy4gQXJlIHRoZXJlIHNwZWNpZmljIGNvbmNlcm5zIGluIHRo ZSBXRyByZWdhcmRpbmcgdGhlIHVzZSBvZiBSRVNUQ09ORiBmb3IgdGhlIGRhdGEgY2hhbm5lbD8g T25lIGNvbmNlcm4gYXBwYXJlbnQgaW4gdGhlIGRpc2N1c3Npb24gY29pbmNpZGluZyB3aXRoIHRo ZSBtZWV0aW5nIGluIFNlb3VsIHdhcyBhZGRlZCBjb21wbGV4aXR5LCBidXQgSeKAmW0gaGF2aW5n IGEgaGFyZCB0aW1lIGRpc2Nlcm5pbmcgd2hldGhlciB0aGF0IGNvbmNlcm4gYXBwbGllcyB0byB0 aGUgc2lnbmFsIGNoYW5uZWwsIGRhdGEgY2hhbm5lbCwgb3IgYm90aC4NCg0KYW5kcmV3DQo= --_000_6AE56175DBE74CD9BA4E5DCA88E901D8arbornet_ Content-Type: text/html; charset="utf-8" Content-ID: <4684B42A6EB867408FFAC379326A5751@prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhlIGRhdGEgY2hhbm5lbCBwcm9w b3NlZCBpbiBkcmFmdC1yZWRkeS1kb3RzLWRhdGEtY2hhbm5lbCAoYW5kIHByZXZpb3VzbHkgaW4g ZHJhZnQtcmVkZHktZG90cy10cmFuc3BvcnQpIGhhcyBldm9sdmVkIG92ZXIgdGhlIHBhc3QgeWVh ciBmcm9tIHVzaW5nIEhUVFAgYW5kIGEgbGltaXRlZCBSRVNUIEFQSSwgdG8gYSBDb0FQIGZvcm0g b2YgdGhlIHNhbWUsIHRvIHVzaW5nIFJFU1RDT05GIGluIHRoZSBjdXJyZW50IHJldmlzaW9uLiBU aGF0IGV2b2x1dGlvbg0KIHNlZW1zIGluIHBhcnQgZHJpdmVuIGJ5IHRoaXMgdGhyZWFkIGZyb20g Tm92ZW1iZXI6DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUi Pjwvc3Bhbj4mbHQ7PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL3Nl YXJjaC8/ZW1haWxfbGlzdD1kb3RzJmFtcDtpbmRleD1jdkItWEVrWS1nakVXUFJCS21JbTBidV82 aXcmYW1wO2didD0xIiBjbGFzcz0iIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv c2VhcmNoLz9lbWFpbF9saXN0PWRvdHMmYW1wO2luZGV4PWN2Qi1YRWtZLWdqRVdQUkJLbUltMGJ1 XzZpdyZhbXA7Z2J0PTE8L2E+Jmd0OzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7SXQgc2VlbXMgdG8gbWUgaW4gcGFydGljdWxh ciB0aGlzIGV4Y2hhbmdlIHNlZW1zIHRvIGJlIHRoZSBjYXRhbHlzdCBmb3IgdGhlIGN1cnJlbnQg Y2hvaWNlIG9mIFJFU1RDT05GOg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUt c3BhY2U6cHJlIj48L3NwYW4+4oCcU28sIGlmIHlvdXIgQ0JPUiB3YXMgZGVyaXZlZCBmcm9tIGEg WUFORyBtb2RlbCwgeW914oCZZCBiZSBkb2luZyBleGFjdGx5IE5FVENPTkYsIGJ0dy48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFu IGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPiZs dDs8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2RvdHMvQWZo aERkaEFQdmtHeVV1bXg2U0I0VGJ5aTRnIiBjbGFzcz0iIj5odHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL2RvdHMvQWZoaERkaEFQdmtHeVV1bXg2U0I0VGJ5aTRnPC9hPiZndDs8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkEgbnVtYmVyIG9mIGNvbnRyaWJ1dG9ycyB0byB0aGUgdGhyZWFkIHJhaXNlZCBvYmplY3Rpb25z IHRvIHVzaW5nIE5FVENPTkYvUkVTVENPTkYuIFRoZSBjb25jZXJucywgYXMgSSByZWFkIHRoZW0s IGFyZSBtb3N0bHkgYWJvdXQgdXNpbmcgTkVUQ09ORi9SRVNUQ09ORiBhcyB0aGUgcHJvdG9jb2wg Zm9yIHRoZSBzaWduYWwgY2hhbm5lbCwgYnV0IHRoYXQgbWF5IGJlIGJlY2F1c2UgSeKAmXZlIGFs c28gcHJvcG9zZWQgdXNpbmcNCiBSRVNUQ09ORiBmb3IgdGhlIGRhdGEgY2hhbm5lbCBpbiB0aGUg cGFzdC4gWzFdPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPlNpbmNlIFJFU1RDT05GIGlzIG5vdyBhIGNvbmNyZXRlIHByb3Bv c2FsLCBpdCBzZWVtcyB3b3J0aHdoaWxlIGNvbnRpbnVpbmcgdGhlIGRlYmF0ZSBhaGVhZCBvZiB0 aGUgaW50ZXJpbSBtZWV0aW5nLiBBcmUgdGhlcmUgc3BlY2lmaWMgY29uY2VybnMgaW4gdGhlIFdH IHJlZ2FyZGluZyB0aGUgdXNlIG9mIFJFU1RDT05GIGZvciB0aGUgZGF0YSBjaGFubmVsPyBPbmUg Y29uY2VybiBhcHBhcmVudCBpbiB0aGUgZGlzY3Vzc2lvbg0KIGNvaW5jaWRpbmcgd2l0aCB0aGUg bWVldGluZyBpbiBTZW91bCB3YXMgYWRkZWQgY29tcGxleGl0eSwgYnV0IEnigJltIGhhdmluZyBh IGhhcmQgdGltZSBkaXNjZXJuaW5nIHdoZXRoZXIgdGhhdCBjb25jZXJuIGFwcGxpZXMgdG8gdGhl IHNpZ25hbCBjaGFubmVsLCBkYXRhIGNoYW5uZWwsIG9yIGJvdGguPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5hbmRyZXc8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_6AE56175DBE74CD9BA4E5DCA88E901D8arbornet_-- From nobody Mon Feb 13 06:09:00 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A373F12966D for ; Mon, 13 Feb 2017 06:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 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_MED=-2.3, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 zkvXe6UIIaHh for ; Mon, 13 Feb 2017 06:08:55 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A619129582 for ; Mon, 13 Feb 2017 06:08:54 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v1DE8pqH027983; Mon, 13 Feb 2017 09:08:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1486994931; bh=Fz6EhFehSP6Q5LJAj402DMD6aj7/FfR05ee4hWAmEmM=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=SvREjUqLUnsVfl4ffnvUldRfnMfcf0kfvh/UD+e7AoZBBJRhZG4KnAnFqlNiGFof4 8ziIjHGQGtDVXzCl0iyx1YyaPKPVAwTmD21IjYeUdcUwUifVKhom90QWMbrXuNCFjy MzisieJXu7gODXCojJau99qGOKuK/ccbG+AueHn0= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v1DE8lIL002723; Mon, 13 Feb 2017 09:08:47 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0319.002; Mon, 13 Feb 2017 09:08:47 -0500 From: "Roman D. Danyliw" To: Flemming Andreasen , dots Thread-Topic: [Dots] DOTS Minutes from IETF97 ? Thread-Index: AQHSgvZ8NdcIppXDlEuvAhqj+8F6xaFm/Tbw Date: Mon, 13 Feb 2017 14:08:46 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104EFFB6A@marathon> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS Minutes from IETF97 ? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 13 Feb 2017 14:08:56 -0000 Hi Flemming, > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Flemming Andreasen > Sent: Thursday, February 09, 2017 12:04 PM > To: dots > Subject: [Dots] DOTS Minutes from IETF97 ? > > Hi > > I don't see the DOTS minutes from IETF 97 at=20 > https://datatracker.ietf.org/meeting/97/proceedings.=20 > Are they somewhere else ? They are in Etherpad (thanks for the pointer Frank): http://etherpad.tools.ietf.org:9000/p/notes-ietf-97-dots?useMonospaceFont= =3Dtrue I'll find out why they didn't make it to the official proceedings. Roman From nobody Mon Feb 13 20:05:05 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CE71295A4 for ; Mon, 13 Feb 2017 20:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 fUOE-FAWnZxG for ; Mon, 13 Feb 2017 20:05:02 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF15012959F for ; Mon, 13 Feb 2017 20:05:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6036; q=dns/txt; s=iport; t=1487045102; x=1488254702; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=yuvREQWmktyeW5O4zpCA0Dn0ONNO4BK45qrjMFSkX5o=; b=jgM2BhYnFmK9L7ZGBkNn//Wp7Slv20eYV8oo0MeMUXQezPTcNTAkYW9D hdmGdnTPgN8yX85X+kNP2UX0WmMBBW+AaD+AVH9VWbK5uGiGHKzobB2rJ jK7oBTgNdy+ptVWOfxNGvmcACZuFnF+uoL6xp9OWmbFILCIouhj+8YNxm w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbBQBTgaJY/4ENJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1JhAydfn26QCoUsggwfAQyFdgKBbkAXAQIBAQEBAQEBYiiEaQE?= =?us-ascii?q?BAQMBAQFsEAsLGC4nMAYBDAYCAQGJWQUIDgKxIiuLLgEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEaBYZMggWCaoMXgRmGCQWQQYsxhm+LJYF7iEQjhiOTFSEBNYEANB0VPYZ?= =?us-ascii?q?hIjWHZII8AQEB?= X-IronPort-AV: E=Sophos;i="5.35,159,1484006400"; d="scan'208,217";a="385227236" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Feb 2017 04:05:01 +0000 Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v1E450l8029078; Tue, 14 Feb 2017 04:05:00 GMT To: "Mortensen, Andrew" , "dots@ietf.org" References: <6AE56175-DBE7-4CD9-BA4E-5DCA88E901D8@arbor.net> From: Flemming Andreasen Message-ID: <1d81f0e1-602d-60d4-73e3-19c7fad5556d@cisco.com> Date: Mon, 13 Feb 2017 23:05:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <6AE56175-DBE7-4CD9-BA4E-5DCA88E901D8@arbor.net> Content-Type: multipart/alternative; boundary="------------DAD976385EC8092E0A36C69C" Archived-At: Subject: Re: [Dots] use of restconf for the data channel? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 14 Feb 2017 04:05:04 -0000 This is a multi-part message in MIME format. --------------DAD976385EC8092E0A36C69C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 2/12/17 11:20 AM, Mortensen, Andrew wrote: > The data channel proposed in draft-reddy-dots-data-channel (and > previously in draft-reddy-dots-transport) has evolved over the past > year from using HTTP and a limited REST API, to a CoAP form of the > same, to using RESTCONF in the current revision. That evolution seems > in part driven by this thread from November: > > > > It seems to me in particular this exchange seems to be the catalyst > for the current choice of RESTCONF: > > “So, if your CBOR was derived from a YANG model, you’d be doing > exactly NETCONF, btw. > > > > A number of contributors to the thread raised objections to using > NETCONF/RESTCONF. The concerns, as I read them, are mostly about using > NETCONF/RESTCONF as the protocol for the signal channel, but that may > be because I’ve also proposed using RESTCONF for the data channel in > the past. [1] > > Since RESTCONF is now a concrete proposal, it seems worthwhile > continuing the debate ahead of the interim meeting. Are there specific > concerns in the WG regarding the use of RESTCONF for the data channel? > One concern apparent in the discussion coinciding with the meeting in > Seoul was added complexity, but I’m having a hard time discerning > whether that concern applies to the signal channel, data channel, or both. > Me too, however I suggest we focus the RESTCONF discussion on the data channel for now. Thanks -- Flemming > andrew > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------DAD976385EC8092E0A36C69C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 2/12/17 11:20 AM, Mortensen, Andrew wrote:
The data channel proposed in draft-reddy-dots-data-channel (and previously in draft-reddy-dots-transport) has evolved over the past year from using HTTP and a limited REST API, to a CoAP form of the same, to using RESTCONF in the current revision. That evolution seems in part driven by this thread from November:


 It seems to me in particular this exchange seems to be the catalyst for the current choice of RESTCONF:

“So, if your CBOR was derived from a YANG model, you’d be doing exactly NETCONF, btw.


A number of contributors to the thread raised objections to using NETCONF/RESTCONF. The concerns, as I read them, are mostly about using NETCONF/RESTCONF as the protocol for the signal channel, but that may be because I’ve also proposed using RESTCONF for the data channel in the past. [1]

Since RESTCONF is now a concrete proposal, it seems worthwhile continuing the debate ahead of the interim meeting. Are there specific concerns in the WG regarding the use of RESTCONF for the data channel? One concern apparent in the discussion coinciding with the meeting in Seoul was added complexity, but I’m having a hard time discerning whether that concern applies to the signal channel, data channel, or both.

Me too, however I suggest we focus the RESTCONF discussion on the data channel for now.

Thanks

-- Flemming

andrew


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

--------------DAD976385EC8092E0A36C69C-- From nobody Tue Feb 14 06:53:28 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3EF129569 for ; Tue, 14 Feb 2017 06:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 XOiwlM-q9MLL for ; Tue, 14 Feb 2017 06:53:24 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13ED51289C4 for ; Tue, 14 Feb 2017 06:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36524; q=dns/txt; s=iport; t=1487084003; x=1488293603; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=p48CZJkDScsgHJk+e+cSRQJ5VLbFsaLuAHsTzHbxIZ0=; b=EKRMLS8PuPhiz8wrrRIGcTHs3XW+cePUkt89HnEh/5M3vVjg3m2Eveza eBkXD8/I5eqCvgFLebE6NIEUOgxiJQNh1Q1lIBlPdRD3/g3rqj4P+BYOc xhx3PMR8TocRNOYhPgN9jFOoYql3xGQY7ZI7qv97GDa2gCsx5GOJ+5Ydc 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAQBuGaNY/4gNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9jYYEJB41akhCVNoIMhiICgXs/GAECAQEBAQEBAWIohGkBAQE?= =?us-ascii?q?ELUUHEAIBCBEEAQEhAQIEBzIUCQgBAQQBDQUIEYlSsTWLXAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2GTIRvhDABBgEBBSQohS8Fm3IBig6HfIIEhReJc4gsimgBHzi?= =?us-ascii?q?BAFEVPYRCAx0ZgUh1h2QBDheBCoEMAQEB?= X-IronPort-AV: E=Sophos;i="5.35,161,1484006400"; d="scan'208,217";a="208475627" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Feb 2017 14:53:21 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v1EErLMR021750 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Feb 2017 14:53:21 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 14 Feb 2017 08:53:21 -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.1210.000; Tue, 14 Feb 2017 08:53:21 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Ehud Doron , "'dots'" Thread-Topic: Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . Thread-Index: AdKCER/slEaaT/pbTQCa8ffUgEh/YgEvK4mg Date: Tue, 14 Feb 2017 14:53:20 +0000 Message-ID: <331a77a5ec074db69cf2bc2715a7645e@XCH-RCD-017.cisco.com> References: 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.65.50.47] Content-Type: multipart/alternative; boundary="_000_331a77a5ec074db69cf2bc2715a7645eXCHRCD017ciscocom_" MIME-Version: 1.0 Archived-At: Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 14 Feb 2017 14:53:26 -0000 --_000_331a77a5ec074db69cf2bc2715a7645eXCHRCD017ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ehud, Thanks for the detailed review, Please see inline (I will respond to data c= hannel comments in a separate mail) From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron Sent: Wednesday, February 8, 2017 7:21 PM To: 'dots' Cc: David Aviv Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-0= 7 and draft-reddy-dots-data-channel-03 . Tiru and authors Hi Attached please find my comments and feedbacks to draft-reddy-dots-signal-c= hannel-07 and draft-reddy-dots-data-channel-03 . Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel = draft-reddy-dots-signal-channel-07 1. General comment: For all signals in the draft, need to add means t= o allow vendor specific attributes as part of all signals transactions [TR] Yes, will update draft. 2. General comment: Just for clarity, need to explicitly mention on e= ach figure when it is an example or the actual API [TR] Done. 3. Page 3 second paragraph : DOTS should not be limited to "enterpris= e network" only [TR] Agreed, fixed. 4. Page 4 chapter 4: The overall context of the "happy eyeballs" and = its relations (or coexistence) to CoAP is not clear. [TR] Happy eyeballs mechanism is used to reduce connection delay to setup (= D)TLS session with the DOTS server. Happy eyeballs mechanism is not related= to CoAP. 5. Page 7 chapter 5.2.1: The need for YANG model cannot be understood= from text. What are the needs for YANG models? What is the relation to the= JSONs in the other chapters in the draft [TR] YANG is a data modeling language used to model configuration and state= data; The configuration and state data defined using YANG can be represen= ted in JSON or CBOR or XML. Since CBOR is binary, JSON is used in the draft= but only for illustrative purpose. 6. Page 14 figure 5: The mitigation request attributes are right but = not enough. Need to add more telemetry info about the actual attack that it= is required to mitigate, need to consider attributes in draft-doron-dots-t= elemetry-00 as part of the discussion in the WG. [TR] Yes, I plan to update the draft with telemetry info based on outcome o= f draft-doron-dots-telemetry-00. 7. Page 15 Life time attribute: More reasonable to have this attribut= e in minutes rather than seconds, bigger default can also suggested [TR] Changed to minutes 8. Page 15 last paragraph: Not sure that target port or target protoc= ol can define a protected entity. IP, FQDN, URI are the only "stand alone" = attributes , port and protocol are companion attributes. See also figure 9 = . [TR] Good point, fixed. 9. Page 15 last paragraph: The mitigation request is not clear, to wh= ich identifier the text is related ? "policy ID" ? I think the best is ha= ve another attribute to define the priority of mitigation requests [TR] policy-id is specific to a DOTS client, DOTS server need not compare t= he policy-id of one customer with the policy-id of another customer. Policy= -ids are only compared b/w multiple mitigation requests from the same DOTS = client to determine the priority. DOTS signaling channel runs over UDP, and= packets may arrive out-of-order; this was also one of the reasons to intro= duce policy-id. 10. Page 21 table: The return status are right but not enough. Need to ad= d more telemetry info about the actual mitigation going on (how much traffi= c was mitigated) and the attack that are mitigated, need to consider attrib= utes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. [TR] Same response as 6; for now will update the draft to convey the follow= ing telemetry info from the DOTS server : total dropped byte count, average= dropped bytes per second, total dropped packet count and average dropped p= ackets per second. The list is not complete, what kind of telemetry info is= required for L7 attacks (e.g. attack at TLS, partial HTTP request, garbage= request etc.) and how do we deal with new type of DDOS attacks (Do we keep= updating the spec as and when a new DDOS attack is discovered) ? 11. Page 15 : Need to find the way to bind the target-ips with target-por= t-ranges and target-protocols, meaning that the server needs to understand = the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on = so forth. [TR] Yes, it's possible; create different aliases for IP1 TCP port 80 and I= P 2 UDP port 53 using DOTS data channel and convey the aliases in DOTS sign= al channel. 12. Page 21 last paragraph: This is very strong point. [TR] Thanks. 13. Page 25 : Regarding attack status, same point about telemetry. [TR] Same response as above. 14. Page 25 chapter 5.4: I believe it can valuable to add a short high le= vel description about the proposed API flow, same as you did for 5.3 . [TR] 5.3 gives background how GET, POST, DELETE and PUT will be used, hence= did not see a need to add a high level description in Section 5.4. 15. Page 27: The necessity of policy_id here is not clear enough, are th= e "Signal Channel Session Configuration" define only "single" DOTS session = or the entire communication between Client and Server for several DOTS requ= est for mitigation? [TR] It's for a single DOTS session between DOTS client and server, a sing= le DOTS session can be used for several DOTS requests and responses. 16. Page 27: Not sure about the reason for "at least one of the attribute= s heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor = MUST be present." Also consider to change to "presented". [TR] what is the point in conveying a POST request without any configuratio= n parameters/attributes ? 17. Page 30 chapter 5.5: Need to specify the overall scenario, in reactio= n to which signal (or API transaction POST of Mitigation Request , unidirec= tional notification from Server as describes in page 23 in page 21 ?) the = redirection occurred ? [TR] Both, updated draft. -Tiru Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel dr= aft-reddy-dots-data-channel-03 1. General comment: For all signal in the draft, need to add means to= allow vendor specific attributes as part of all signals transactions 2. Page 5 second paragraph: Why it is required to configure the DOTS = signal channel session ? 3. Page 8 chapter 3.2.1 : Any reason for not including these identifi= ers in the DOTS signal channel draft ? 4. Page 9 figure 3 : Need to find the way to bind the target-ips with= target-port-ranges and target-protocols, meaning that the server needs to = understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53= and so on so forth. 5. Page 13 chapter 3.3 : Need to emphasize that filtering rules are r= elevant for both client server direct communication and through a DOTS gate= way. The chapter is a bit confusing. 6. Page 14 chapter 3.3 : I am missing the white-list installation, is= it by using the permit action ? 7. Page 15 figure 8: For DDoS it is highly valuable to have rate limi= t as an action. Consider adding such action (if already defined need to exp= lain where and how). 8. Page 15 figure 8: Need to consider adding priority to an ACL to su= pport cases when several filtering rules are conflicting. 9. Page 15 : The action field cannot be optional attribute. 10. Page 16 chapter 3.3.3: Need to add more telemetry info about the actu= al traffic that was blocked (bps, pps and so on), but as I believe this mig= ht be another issue... Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 --_000_331a77a5ec074db69cf2bc2715a7645eXCHRCD017ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ehud,

 

Thanks for the detaile= d review, Please see inline (I will respond to data channel comments in a s= eparate mail)

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-ch= annel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru and authors Hi

 

Attached please find m= y comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-re= ddy-dots-data-channel-03 .

 

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy= -dots-signal-channel-07

 

1.     &= nbsp; General comment: For all signals in the draft, need= to add means to allow vendor specific attributes as part of all signals tr= ansactions

 

[TR] Yes, will update draft.

 

2.&n= bsp;      General comment: Just for clarity, need to e= xplicitly mention on each figure when it is an example or the actual API

 

[TR] Done.

 

3.     &= nbsp; Page 3 second paragraph : DOTS should not be limite= d to “enterprise network” only

 

[TR] Agreed, fixed.

 

4.     &= nbsp; Page 4 chapter 4: The overall context of the “= ;happy eyeballs” and its relations (or coexistence) to CoAP is not cl= ear.  

 

[TR] Happy eyeballs me= chanism is used to reduce connection delay to setup (D)TLS session with the= DOTS server. Happy eyeballs mechanism is not related to CoAP.<= /o:p>

 

5.     &= nbsp; Page 7 chapter 5.2.1: The need for YANG model canno= t be understood from text. What are the needs for YANG models? What is the = relation to the JSONs in the other chapters in the draft

 

[TR] YANG is a data mo= deling language used to model configuration and state data;  The confi= guration and state data defined using YANG can be represented in JSON or CB= OR or XML. Since CBOR is binary, JSON is used in the draft but only for illustrative purpose.

 

6.     &= nbsp; Page 14 figure 5: The mitigation request attributes= are right but not enough. Need to add more telemetry info about the actual= attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

[TR] Yes, I plan to up= date the draft with telemetry info based on outcome of draft-doron-dots-tel= emetry-00.

 

7.     &= nbsp; Page 15 Life time attribute: More reasonable to have this attribute in minutes rather tha= n seconds, bigger default can also suggested

 

[TR] Changed to minute= s

 

8.     &= nbsp; Page 15 last paragraph: Not sure that target port or target protocol can define a protect= ed entity. IP, FQDN, URI are the only “stand alone” attributes = , port and protocol are companion attributes. See also figure 9 .

 

[TR] Good point, fixed= .

 

9.     &= nbsp; Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is relate= d ?   “policy ID” ? I think the best is have another = attribute to define the priority of mitigation requests

[TR] policy-id is spec= ific to a DOTS client, DOTS server need not compare the policy-id of one cu= stomer with the policy-id of another customer. Policy-ids are only compared= b/w multiple mitigation requests from the same DOTS client to determine the priority. DOTS signaling channel run= s over UDP, and packets may arrive out-of-order; this was also one of the r= easons to introduce policy-id.

 

10.&= nbsp;  Page 21 table: The return status are right b= ut not enough. Need to add more telemetry info about the actual mitigation = going on (how much traffic was mitigated) and the attack that are mitigated= , need to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

[TR] Same response as 6; for now will update the draft to convey the following telemetry info fro= m the DOTS server : total dropped byte count, average dropped byt= es per second, total dropped packet count and average dropped packets per s= econd. The list is not complete, what kind of telemetry info is required fo= r L7 attacks (e.g. attack at TLS, partial HTTP request, garbage request etc.) and how do we deal with new ty= pe of DDOS attacks (Do we keep updating the spec as and when a new DDOS att= ack is discovered) ?

 

11.   Page 15 : Need to find the way to bind the target-i= ps with target-port-ranges and target-protocols, meani= ng that the server needs to understand the exact scope of attack, e.g. IP1 = TCP port 80, IP2 UDP port 53 and so on so forth.

 

[TR] Yes, it’s p= ossible; create different aliases for IP1 TCP port 80 and IP 2 UDP port 53 = using DOTS data channel and convey the aliases in DOTS signal channel.=

 

12.   Page 21 last paragraph: This is very strong point.<= o:p>

 

[TR] Thanks.

 

13.   Page 25 : Regarding attack status, same point about= telemetry.

 

[TR] Same response as above.

14.   Page 25 chapter 5.4: I believe it can valuable to a= dd a short high level description about the proposed API flow, same as you = did for 5.3 .

 

[TR] 5.3 gives backgro= und how GET, POST, DELETE and PUT will be used, hence did not see a need to= add a high level description in Section 5.4.

 

 

15.   Page 27:  The necessity of policy_id here is n= ot clear enough, are the “Signal Channel Session Configuration”= define only “single” DOTS session or the entire communication = between Client and Server for several DOTS request for mitigation?

 

[TR]  It’s = for a single DOTS session between DOTS client and server, a single DOTS ses= sion can be used for several DOTS requests and responses.=

 

16.   Page 27: Not sure about the reason for “at le= ast one of the attributes heartbeat-interval or max-retransmit or ack-timeo= ut or ack-random-factor MUST be present.” Also consider to change to = “presented”.

 

[TR] what is the point in conveying a POST request with=
out any configuration parameters/attributes ?

 

 

17.   Page 30 chapter 5.5: Need to specify the overall sc= enario, in reaction to which signal (or API transaction POST of Mitigation = Request , unidirectional notification from Server as describes in page 23 i= n page 21 ?) the  redirection occurred ?

 

[TR] Both, updated dra= ft.

 

-Tiru

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-d= ots-data-channel-03

 

1.     &= nbsp; General comment: For all signal in the draft, need = to add means to allow vendor specific attributes as part of all signals tra= nsactions

 

2.     &= nbsp; Page 5 second paragraph: Why it is required to conf= igure the DOTS signal channel session ?  

 

3.     &= nbsp; Page 8 chapter 3.2.1 : Any reason for not including= these identifiers in the DOTS signal channel draft ?

 

4.     &= nbsp; Page 9 figure 3 : Need to find the way to bind the = target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e= .g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

5.     &= nbsp; Page 13 chapter 3.3 : Need to emphasize that filter= ing rules are relevant for both client server direct communication and thro= ugh a DOTS gateway. The chapter is a bit confusing.

 

6.     &= nbsp; Page 14 chapter 3.3 : I am missing the white-list i= nstallation, is it by using the permit action ?

 

7.     &= nbsp; Page 15 figure 8: For DDoS it is highly valuable to= have rate limit as an action. Consider adding such action (if already defi= ned need to explain where and how).

 

8.     &= nbsp; Page 15 figure 8: Need to consider adding priority = to an ACL to support cases when several filtering rules are conflicting.

 

9.     &= nbsp; Page 15 : The action field cannot be optional attri= bute.

 

10.   Page 16 chapter 3.3.3: Need to add more telemetry i= nfo about the actual traffic that was blocked (bps, pps and so on), but as = I believe this might be another issue…

 

 

 

Thanks,

 

Ehud Doron |=  Senior Architect, Radware CTO office | M:<= span style=3D"font-size:10.0pt;font-family:"Tahoma",sans-serif;co= lor:#999999"> +972-54-7575503 | T: +972-72-3917120

 

 

 

 

--_000_331a77a5ec074db69cf2bc2715a7645eXCHRCD017ciscocom_-- From nobody Tue Feb 14 06:58:42 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24FDA129503 for ; Tue, 14 Feb 2017 06:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 3XXp8Cb5RS0a for ; Tue, 14 Feb 2017 06:58:37 -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 2926412962C for ; Tue, 14 Feb 2017 06:58:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33856; q=dns/txt; s=iport; t=1487084317; x=1488293917; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xWlw3Zcp1XpeySsYxknnFP0uaasOcK4ieWtSYR9Px6k=; b=QKdZbt1fyuJrP6pdJlbZPgMS5lLUyQHdKhOxH39R+1G0kaJtIMoUrT14 NiKQZHAnSxWSi7O0FlPXZnOV9feFzrkvSE4CUzQAH0tJ9KAZ1KadRyJ2S 565r9SGPGmm8maNEnIx5klirFOH2fW4mxJptnsoxoYdo4qs4L9WIrDGdJ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAQAgGqNY/4MNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9jYYEJB41akhCVNoIMKoV4AoF7PxgBAgEBAQEBAQFiKIRpAQE?= =?us-ascii?q?BBC1FBxACAQgRBAEBIQECBAcyFAkIAQEEAQ0FCBGJUg6xKotcAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWGTIRvhDABDR0HKIUvBZtyAYZuixyCBIUXiXOTFAEfOIE?= =?us-ascii?q?AURU9hEUdGYFIdQGHYwElgQqBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,161,1484006400"; d="scan'208,217";a="180410845" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Feb 2017 14:58:35 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v1EEwZBu021426 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Feb 2017 14:58:35 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.1210.3; Tue, 14 Feb 2017 08:58:34 -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.1210.000; Tue, 14 Feb 2017 08:58:34 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Ehud Doron , "'dots'" Thread-Topic: Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . Thread-Index: AdKCER/slEaaT/pbTQCa8ffUgEh/YgEwQ2SQ Date: Tue, 14 Feb 2017 14:58:34 +0000 Message-ID: References: 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.65.50.47] Content-Type: multipart/alternative; boundary="_000_bfa74e5a63d2430c80bdfd6b0da0c3b8XCHRCD017ciscocom_" MIME-Version: 1.0 Archived-At: Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 14 Feb 2017 14:58:40 -0000 --_000_bfa74e5a63d2430c80bdfd6b0da0c3b8XCHRCD017ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ehud, Please see inline for responses to comments on draft-reddy-dots-data-channe= l-03 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron Sent: Wednesday, February 8, 2017 7:21 PM To: 'dots' Cc: David Aviv Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-0= 7 and draft-reddy-dots-data-channel-03 . Tiru and authors Hi Attached please find my comments and feedbacks to draft-reddy-dots-signal-c= hannel-07 and draft-reddy-dots-data-channel-03 . Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel = draft-reddy-dots-signal-channel-07 1. General comment: For all signals in the draft, need to add means t= o allow vendor specific attributes as part of all signals transactions 2. General comment: Just for clarity, need to explicitly mention on e= ach figure when it is an example or the actual API 3. Page 3 second paragraph : DOTS should not be limited to "enterpris= e network" only . 4. Page 4 chapter 4: The overall context of the "happy eyeballs" and = its relations (or coexistence) to CoAP is not clear. 5. Page 7 chapter 5.2.1: The need for YANG model cannot be understood= from text. What are the needs for YANG models? What is the relation to the= JSONs in the other chapters in the draft 6. Page 14 figure 5: The mitigation request attributes are right but = not enough. Need to add more telemetry info about the actual attack that it= is required to mitigate, need to consider attributes in draft-doron-dots-t= elemetry-00 as part of the discussion in the WG. 7. Page 15 Life time attribute: More reasonable to have this attribut= e in minutes rather than seconds, bigger default can also suggested 8. Page 15 last paragraph: Not sure that target port or target protoc= ol can define a protected entity. IP, FQDN, URI are the only "stand alone" = attributes , port and protocol are companion attributes. See also figure 9 = . 9. Page 15 last paragraph: The mitigation request is not clear, to wh= ich identifier the text is related ? "policy ID" ? I think the best is ha= ve another attribute to define the priority of mitigation requests 10. Page 21 table: The return status are right but not enough. Need to ad= d more telemetry info about the actual mitigation going on (how much traffi= c was mitigated) and the attack that are mitigated, need to consider attrib= utes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. 11. Page 15 : Need to find the way to bind the target-ips with target-por= t-ranges and target-protocols, meaning that the server needs to understand = the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on = so forth. 12. Page 21 last paragraph: This is very strong point. 13. Page 25 : Regarding attack status, same point about telemetry. 14. Page 25 chapter 5.4: I believe it can valuable to add a short high le= vel description about the proposed API flow, same as you did for 5.3 . 15. Page 27: The necessity of policy_id here is not clear enough, are th= e "Signal Channel Session Configuration" define only "single" DOTS session = or the entire communication between Client and Server for several DOTS requ= est for mitigation? 16. Page 27: Not sure about the reason for "at least one of the attribute= s heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor = MUST be present." Also consider to change to "presented". 17. Page 30 chapter 5.5: Need to specify the overall scenario, in reactio= n to which signal (or API transaction POST of Mitigation Request , unidirec= tional notification from Server as describes in page 23 in page 21 ?) the = redirection occurred ? Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel dr= aft-reddy-dots-data-channel-03 1. General comment: For all signal in the draft, need to add means to= allow vendor specific attributes as part of all signals transactions [TR] Agreed, updated draft. 2. Page 5 second paragraph: Why it is required to configure the DOTS = signal channel session ? [TR] No need to configure DOTS signal channel session, fixed second paragra= ph. 3. Page 8 chapter 3.2.1 : Any reason for not including these identifi= ers in the DOTS signal channel draft ? [TR] Identifiers created for resources in DOTS data channel are used in DOT= S signal channel to request DDOS mitigation. It's the responsibility of DOT= S data channel to create aliases for resources (see https://tools.ietf.org/= html/draft-ietf-dots-requirements-03#section-2.3). The main reason for DOTS= signal channel not creating identifiers is the message size may exceed Pat= h MTU. 4. Page 9 figure 3 : Need to find the way to bind the target-ips with= target-port-ranges and target-protocols, meaning that the server needs to = understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53= and so on so forth. [TR] Yes, it is possible; create different aliases for IP1 TCP port 80 and = IP2 UDP port 53. 5. Page 13 chapter 3.3 : Need to emphasize that filtering rules are r= elevant for both client server direct communication and through a DOTS gate= way. The chapter is a bit confusing. [TR] Thanks, fixed chapter 3.3. 6. Page 14 chapter 3.3 : I am missing the white-list installation, is= it by using the permit action ? [TR] Yes, "permit" action is used for white-list installation; it's define= d in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 7. Page 15 figure 8: For DDoS it is highly valuable to have rate limi= t as an action. Consider adding such action (if already defined need to exp= lain where and how). [TR] Done, updated draft. 8. Page 15 figure 8: Need to consider adding priority to an ACL to su= pport cases when several filtering rules are conflicting. [TR] We are not doing anything new to ACL, ACL an ordered list of Access L= ist Entries (ACE) based on priority. 9. Page 15 : The action field cannot be optional attribute. [TR] As per https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 if t= he action field not specified then "deny" is the default action. 10. Page 16 chapter 3.3.3: Need to add more telemetry info about the actu= al traffic that was blocked (bps, pps and so on), but as I believe this mig= ht be another issue... [TR] Chapter 3.3.3 only discusses telemetry details of number of matches fo= r the installed filtering rules. -Tiru Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 --_000_bfa74e5a63d2430c80bdfd6b0da0c3b8XCHRCD017ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ehud,

 

Please see inline for = responses to comments on draft-reddy-dots-data-channel-03=

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-ch= annel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru and authors Hi

 

Attached please find m= y comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-re= ddy-dots-data-channel-03 .

 

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy= -dots-signal-channel-07

 

1.     &= nbsp; General comment: For all signals in the draft, need= to add means to allow vendor specific attributes as part of all signals tr= ansactions

 

2.&n= bsp;      General comment: Just for clarity, need to e= xplicitly mention on each figure when it is an example or the actual API

 

3.     &= nbsp; Page 3 second paragraph : DOTS should not be limite= d to “enterprise network” only

.

4.     &= nbsp; Page 4 chapter 4: The overall context of the “= ;happy eyeballs” and its relations (or coexistence) to CoAP is not cl= ear.  

 

5.     &= nbsp; Page 7 chapter 5.2.1: The need for YANG model canno= t be understood from text. What are the needs for YANG models? What is the = relation to the JSONs in the other chapters in the draft

 

6.     &= nbsp; Page 14 figure 5: The mitigation request attributes= are right but not enough. Need to add more telemetry info about the actual= attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

7.     &= nbsp; Page 15 Life time attribute: More reasonable to have this attribute in minutes rather tha= n seconds, bigger default can also suggested

 

8.     &= nbsp; Page 15 last paragraph: Not sure that target port or target protocol can define a protect= ed entity. IP, FQDN, URI are the only “stand alone” attributes = , port and protocol are companion attributes. See also figure 9 .

 

9.     &= nbsp; Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is relate= d ?   “policy ID” ? I think the best is have another = attribute to define the priority of mitigation requests

 

10.&= nbsp;  Page 21 table: The return status are right b= ut not enough. Need to add more telemetry info about the actual mitigation = going on (how much traffic was mitigated) and the attack that are mitigated= , need to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

11.   Page 15 : Need to find the way to bind the target-i= ps with target-port-ranges and target-protocols, meani= ng that the server needs to understand the exact scope of attack, e.g. IP1 = TCP port 80, IP2 UDP port 53 and so on so forth.

 

12.   Page 21 last paragraph: This is very strong point.<= o:p>

 

13.   Page 25 : Regarding attack status, same point about= telemetry.

 

14.   Page 25 chapter 5.4: I believe it can valuable to a= dd a short high level description about the proposed API flow, same as you = did for 5.3 .

 

15.   Page 27:  The necessity of policy_id here is n= ot clear enough, are the “Signal Channel Session Configuration”= define only “single” DOTS session or the entire communication = between Client and Server for several DOTS request for mitigation?

 

16.   Page 27: Not sure about the reason for “at le= ast one of the attributes heartbeat-interval or max-retransmit or ack-timeo= ut or ack-random-factor MUST be present.” Also consider to change to = “presented”.

 

17.   Page 30 chapter 5.5: Need to specify the overall sc= enario, in reaction to which signal (or API transaction POST of Mitigation = Request , unidirectional notification from Server as describes in page 23 i= n page 21 ?) the  redirection occurred ?

 

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-d= ots-data-channel-03

 

1.     &= nbsp; General comment: For all signal in the draft, need = to add means to allow vendor specific attributes as part of all signals tra= nsactions

 

[TR] Agreed, updated draft.

 

2.     &= nbsp; Page 5 second paragraph: Why it is required to conf= igure the DOTS signal channel session ?  

 

[TR] No need to config= ure DOTS signal channel session, fixed second paragraph.<= /p>

 

3.     &= nbsp; Page 8 chapter 3.2.1 : Any reason for not including= these identifiers in the DOTS signal channel draft ?

 

[TR] Identifiers creat= ed for resources in DOTS data channel are used in DOTS signal channel to re= quest DDOS mitigation. It’s the responsibility of DOTS data channel t= o create aliases for resources (see https://tools.ietf.org/html/draft-ietf-dots-requirements-03= #section-2.3). The main reason for DOTS s= ignal channel not creating identifiers is the message size may exceed Path MTU.

 

 

4.     &= nbsp; Page 9 figure 3 : Need to find the way to bind the = target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e= .g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

[TR] Yes, it is possib= le; create different aliases for IP1 TCP port 80 and IP2 UDP port 53.<= /o:p>

 

 

5.     &= nbsp; Page 13 chapter 3.3 : Need to emphasize that filter= ing rules are relevant for both client server direct communication and thro= ugh a DOTS gateway. The chapter is a bit confusing.

 

[TR] Thanks, fixed cha= pter 3.3.

 

 

6.     &= nbsp; Page 14 chapter 3.3 : I am missing the white-list i= nstallation, is it by using the permit action ?

 

[TR]  Yes, “= ;permit” action is used for white-list installation; it’s defin= ed in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09

 

 

7.     &= nbsp; Page 15 figure 8: For DDoS it is highly valuable to= have rate limit as an action. Consider adding such action (if already defi= ned need to explain where and how).

 

[TR] Done, updated draft.

 

8.     &= nbsp; Page 15 figure 8: Need to consider adding priority = to an ACL to support cases when several filtering rules are conflicting.

 

[TR]  We are not = doing anything new to ACL, ACL an ordered list of Access List Entries (ACE)= based on priority.

 

 

9.     &= nbsp; Page 15 : The action field cannot be optional attri= bute.

 

[TR] As per https:/= /tools.ietf.org/html/draft-ietf-netmod-acl-model-09 if the action field not specified then “deny” is the default action.

 

10.   Page 16 chapter 3.3.3: Need to add more telemetry i= nfo about the actual traffic that was blocked (bps, pps and so on), but as = I believe this might be another issue…

 

[TR] Chapter 3.3.3 onl= y discusses telemetry details of number of matches for the installed filter= ing rules.

 

-Tiru

 

Thanks,

 

Ehud Doron <= span dir=3D"RTL">|  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

 

--_000_bfa74e5a63d2430c80bdfd6b0da0c3b8XCHRCD017ciscocom_-- From nobody Tue Feb 14 21:57:02 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A581299FC for ; Tue, 14 Feb 2017 21:57:01 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 L2rO-l3gwv99 for ; Tue, 14 Feb 2017 21:56:57 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id 718B51299F9 for ; Tue, 14 Feb 2017 21:56:57 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id B58AA25F69F; Wed, 15 Feb 2017 14:56:55 +0900 (JST) Received: from DHCP-190.nttv6.jp (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 1A852759043; Wed, 15 Feb 2017 14:56:55 +0900 (JST) To: "Tirumaleswar Reddy (tireddy)" , Ehud Doron , 'dots' References: From: kaname nishizuka Message-ID: Date: Wed, 15 Feb 2017 14:57:05 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0617D8454367812A1AE6CDE3" Archived-At: Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 15 Feb 2017 05:57:01 -0000 This is a multi-part message in MIME format. --------------0617D8454367812A1AE6CDE3 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Tiru, I really appreciate your time and effort. Please see my comments on the drafts. # draft-reddy-dots-signal-channel-07 1. [General] I believe that DOTS request should not be another tool of blocking other one's traffic. Is there any validation mechanism of requested target-ips, target-ports and target-protocols? Even If it is out side of the DOTS specification, how about returning 4.xx codes when the requested target-* is not a property of the organization. 2. [page14] Does one DOTS client and DOTS server peer have only one signal channel and one data channel? (I'm thinking about a namespace of the "alias-name") If their are multiple data channels, "DOTS signal" in Fig.5 should specify according data channel when it refers to "alias-names" of the identifiers. 3. [Page21] How about adding status of "mitigation delete is in progress" like status:1. Here is a life cycle of a mitigation in our environment. Activating and deleting of mitigation could take several seconds (or minutes). POST. - activating(status=1) STATUS AFTER ACTIVATED - attack mitigated (status=2) - attack stopped (status=3) - attack exceeded capability(status=4) DELETE - deleting(status=5?) - deleted(RETURN 4.04) 4. [Page25] 5.4 b) I couldn't find "retransmission timeout value" attribute in the later figures. Is that equivalent to "ack-timeout"? 5. [Page27] "policy-id" in "signal-config" is different from "policy-id" in "mitigation-scole". How about using "session-id" in this case? # draft-reddy-dots-data-channel-03 1. [General] Data channel doesn't have heartbeat mechanism. I guess the reason is that there is heartbeat mechanism in the signal channel so it is enough, is that right? 2. [related to Ehud's question 8] I-D.ietf-netmod-acl-model says "ACL is an ordered list of Access List Entries (ACE)" but I couldn't find a text about how they are ordered. Should we have a operation of changing the order of ACEs installed in a DOTS server? thank you, Kaname On 2017/02/14 23:58, Tirumaleswar Reddy (tireddy) wrote: > > Hi Ehud, > > Please see inline for responses to comments on draft-reddy-dots-data-channel-03 > > *From:* Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Ehud Doron > *Sent:* Wednesday, February 8, 2017 7:21 PM > *To:* 'dots' > *Cc:* David Aviv > *Subject:* [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Tiru and authors Hi > > Attached please find my comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > *_Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel draft-reddy-dots-signal-channel-07_* > > 1.General comment: For all signals in the draft, need to add means to allow vendor specific attributes as part of all signals transactions > > 2.General comment: Just for clarity, need to explicitly mention on each figure when it is an example or the actual API > > 3.Page 3 second paragraph : DOTS should not be limited to “enterprise network” only > > . > > 4.Page 4 chapter 4: The overall context of the “happy eyeballs” and its relations (or coexistence) to CoAP is not clear. > > 5.Page 7 chapter 5.2.1: The need for YANG model cannot be understood from text. What are the needs for YANG models? What is the relation to the JSONs in the other chapters in the draft > > 6.Page 14 figure 5: The mitigation request attributes are right but not enough. Need to add more telemetry info about the actual attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. > > 7.Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested > > 8.Page 15 last paragraph: Not sure that target port or target protocol can define a protected entity. IP, FQDN, URI are the only “stand alone” attributes , port and protocol are companion attributes. See also figure 9 . > > 9.Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is related ? “policy ID” ? I think the best is have another attribute to define the priority of mitigation requests > > 10.Page 21 table: The return status are right but not enough. Need to add more telemetry info about the actual mitigation going on (how much traffic was mitigated) and the attack that are mitigated, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. > > 11.Page 15 : Need to find the way to bind the target-ip*s* with target-port-range*s* and target-protocol*s*, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth. > > 12.Page 21 last paragraph: This is very strong point. > > 13.Page 25 : Regarding attack status, same point about telemetry. > > 14.Page 25 chapter 5.4: I believe it can valuable to add a short high level description about the proposed API flow, same as you did for 5.3 . > > 15.Page 27: The necessity of policy_id here is not clear enough, are the “Signal Channel Session Configuration” define only “single” DOTS session or the entire communication between Client and Server for several DOTS request for mitigation? > > 16.Page 27: Not sure about the reason for “at least one of the attributes heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor MUST be present.” Also consider to change to “presented”. > > 17.Page 30 chapter 5.5: Need to specify the overall scenario, in reaction to which signal (or API transaction POST of Mitigation Request , unidirectional notification from Server as describes in page 23 in page 21 ?) the redirection occurred ? > > *_Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel draft-reddy-dots-data-channel-03_* > > 1.General comment: For all signal in the draft, need to add means to allow vendor specific attributes as part of all signals transactions > > [TR] Agreed, updated draft. > > 2.Page 5 second paragraph: Why it is required to configure the DOTS signal channel session ? > > [TR] No need to configure DOTS signal channel session, fixed second paragraph. > > 3.Page 8 chapter 3.2.1 : Any reason for not including these identifiers in the DOTS signal channel draft ? > > [TR] Identifiers created for resources in DOTS data channel are used in DOTS signal channel to request DDOS mitigation. It’s the responsibility of DOTS data channel to create aliases for resources (see https://tools.ietf.org/html/draft-ietf-dots-requirements-03#section-2.3). The main reason for DOTS signal channel not creating identifiers is the message size may exceed Path MTU. > > 4.Page 9 figure 3 : Need to find the way to bind the target-ip*s* with target-port-range*s* and target-protocol*s*, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth. > > [TR] Yes, it is possible; create different aliases for IP1 TCP port 80 and IP2 UDP port 53. > > 5.Page 13 chapter 3.3 : Need to emphasize that filtering rules are relevant for both client server direct communication and through a DOTS gateway. The chapter is a bit confusing. > > [TR] Thanks, fixed chapter 3.3. > > 6.Page 14 chapter 3.3 : I am missing the white-list installation, is it by using the permit action ? > > [TR] Yes, “permit” action is used for white-list installation; it’s defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 > > 7.Page 15 figure 8: For DDoS it is highly valuable to have rate limit as an action. Consider adding such action (if already defined need to explain where and how). > > [TR] Done, updated draft. > > 8.Page 15 figure 8: Need to consider adding priority to an ACL to support cases when several filtering rules are conflicting. > > [TR] We are not doing anything new to ACL, ACL an ordered list of Access List Entries (ACE) based on priority. > > 9.Page 15 : The action field cannot be optional attribute. > > [TR] As per https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09if the action field not specified then “deny” is the default action. > > 10.Page 16 chapter 3.3.3: Need to add more telemetry info about the actual traffic that was blocked (bps, pps and so on), but as I believe this might be another issue… > > [TR] Chapter 3.3.3 only discusses telemetry details of number of matches for the installed filtering rules. > > -Tiru > > Thanks, > > ** > > *Ehud Doron *| Senior Architect, *Radware* CTO office | *M:*+972-54-7575503 | *T:* +972-72-3917120 > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------0617D8454367812A1AE6CDE3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Tiru,

I really appreciate your time and effort.
Please see my comments on the drafts.

# draft-reddy-dots-signal-channel-07

1. [General] I believe that DOTS request should not be another tool of blocking other one's traffic. Is there any validation mechanism of requested target-ips, target-ports and target-protocols? Even If it is out side of the DOTS specification, how about returning 4.xx codes when the requested target-* is not a property of the organization.

2. [page14] Does one DOTS client and DOTS server peer have only one signal channel and one data channel? (I'm thinking about a namespace of the "alias-name")
If their are multiple data channels, "DOTS signal" in Fig.5 should specify according data channel when it refers to "alias-names" of the identifiers.

3. [Page21] How about adding status of "mitigation delete is in progress" like status:1.
    Here is a life cycle of a mitigation in our environment. Activating and deleting of mitigation could take several seconds (or minutes).
    POST.
     - activating(status=1)
    STATUS AFTER ACTIVATED
     - attack mitigated (status=2)
     - attack stopped (status=3)
     - attack exceeded capability(status=4)
    DELETE
     - deleting(status=5?)
     - deleted(RETURN 4.04)

4. [Page25] 5.4 b) I couldn't find "retransmission timeout value" attribute in the later figures. Is that equivalent to "ack-timeout"?

5. [Page27] "policy-id" in "signal-config" is different from "policy-id" in "mitigation-scole". How about using "session-id" in this case?

# draft-reddy-dots-data-channel-03

1. [General] Data channel doesn't have heartbeat mechanism. I guess the reason is that there is heartbeat mechanism in the signal channel so it is enough, is that right?

2. [related to Ehud's question 8] I-D.ietf-netmod-acl-model says "ACL is an ordered list of Access List Entries (ACE)" but I couldn't find a text about how they are ordered. Should we have a operation of changing the order of ACEs installed in a DOTS server?


thank you,
Kaname

On 2017/02/14 23:58, Tirumaleswar Reddy (tireddy) wrote:

Hi Ehud,

 

Please see inline for responses to comments on draft-reddy-dots-data-channel-03

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru and authors Hi

 

Attached please find my comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

 

Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy-dots-signal-channel-07

 

1.       General comment: For all signals in the draft, need to add means to allow vendor specific attributes as part of all signals transactions

 

2.       General comment: Just for clarity, need to explicitly mention on each figure when it is an example or the actual API

 

3.       Page 3 second paragraph : DOTS should not be limited to “enterprise network” only

.

4.       Page 4 chapter 4: The overall context of the “happy eyeballs” and its relations (or coexistence) to CoAP is not clear.  

 

5.       Page 7 chapter 5.2.1: The need for YANG model cannot be understood from text. What are the needs for YANG models? What is the relation to the JSONs in the other chapters in the draft

 

6.       Page 14 figure 5: The mitigation request attributes are right but not enough. Need to add more telemetry info about the actual attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG.

 

7.       Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested

 

8.       Page 15 last paragraph: Not sure that target port or target protocol can define a protected entity. IP, FQDN, URI are the only “stand alone” attributes , port and protocol are companion attributes. See also figure 9 .

 

9.       Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is related ?   “policy ID” ? I think the best is have another attribute to define the priority of mitigation requests

 

10.   Page 21 table: The return status are right but not enough. Need to add more telemetry info about the actual mitigation going on (how much traffic was mitigated) and the attack that are mitigated, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG.

 

11.   Page 15 : Need to find the way to bind the target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

12.   Page 21 last paragraph: This is very strong point.

 

13.   Page 25 : Regarding attack status, same point about telemetry.

 

14.   Page 25 chapter 5.4: I believe it can valuable to add a short high level description about the proposed API flow, same as you did for 5.3 .

 

15.   Page 27:  The necessity of policy_id here is not clear enough, are the “Signal Channel Session Configuration” define only “single” DOTS session or the entire communication between Client and Server for several DOTS request for mitigation?

 

16.   Page 27: Not sure about the reason for “at least one of the attributes heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor MUST be present.” Also consider to change to “presented”.

 

17.   Page 30 chapter 5.5: Need to specify the overall scenario, in reaction to which signal (or API transaction POST of Mitigation Request , unidirectional notification from Server as describes in page 23 in page 21 ?) the  redirection occurred ?

 

 

Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-dots-data-channel-03

 

1.       General comment: For all signal in the draft, need to add means to allow vendor specific attributes as part of all signals transactions

 

[TR] Agreed, updated draft.

 

2.       Page 5 second paragraph: Why it is required to configure the DOTS signal channel session ?  

 

[TR] No need to configure DOTS signal channel session, fixed second paragraph.

 

3.       Page 8 chapter 3.2.1 : Any reason for not including these identifiers in the DOTS signal channel draft ?

 

[TR] Identifiers created for resources in DOTS data channel are used in DOTS signal channel to request DDOS mitigation. It’s the responsibility of DOTS data channel to create aliases for resources (see https://tools.ietf.org/html/draft-ietf-dots-requirements-03#section-2.3). The main reason for DOTS signal channel not creating identifiers is the message size may exceed Path MTU.

 

 

4.       Page 9 figure 3 : Need to find the way to bind the target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

[TR] Yes, it is possible; create different aliases for IP1 TCP port 80 and IP2 UDP port 53.

 

 

5.       Page 13 chapter 3.3 : Need to emphasize that filtering rules are relevant for both client server direct communication and through a DOTS gateway. The chapter is a bit confusing.

 

[TR] Thanks, fixed chapter 3.3.

 

 

6.       Page 14 chapter 3.3 : I am missing the white-list installation, is it by using the permit action ?

 

[TR]  Yes, “permit” action is used for white-list installation; it’s defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09

 

 

7.       Page 15 figure 8: For DDoS it is highly valuable to have rate limit as an action. Consider adding such action (if already defined need to explain where and how).

 

[TR] Done, updated draft.

 

8.       Page 15 figure 8: Need to consider adding priority to an ACL to support cases when several filtering rules are conflicting.

 

[TR]  We are not doing anything new to ACL, ACL an ordered list of Access List Entries (ACE) based on priority.

 

 

9.       Page 15 : The action field cannot be optional attribute.

 

[TR] As per https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 if the action field not specified then “deny” is the default action.

 

10.   Page 16 chapter 3.3.3: Need to add more telemetry info about the actual traffic that was blocked (bps, pps and so on), but as I believe this might be another issue…

 

[TR] Chapter 3.3.3 only discusses telemetry details of number of matches for the installed filtering rules.

 

-Tiru

 

Thanks,

 

Ehud Doron |  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

 



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

--------------0617D8454367812A1AE6CDE3-- From nobody Wed Feb 15 06:51:34 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BB9129A5C for ; Wed, 15 Feb 2017 06:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 gik_ueHKKtRC for ; Wed, 15 Feb 2017 06:51:31 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69342129A5B for ; Wed, 15 Feb 2017 06:51:31 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v1FEpRTq022602; Wed, 15 Feb 2017 09:51:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1487170288; bh=R+NQTdLdHozoYCCOueEHt0DmPZA7XErpDyzFZxVE5nQ=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=N2QGLdhh9mdvfGdWd6SF8TmcqMLTDKkD4Tnl8rEo/las7owFmITHPiSMrm0z/uD8X JWdOYIE0Op3JkxkTV5Xcj40vtkb9EmAsqa+kZJO453Iq1G+ppkrX0e6BA2XmaFVU9d VsNo8QRMGQ0P+n0PDnC2T59RsEceRAfx2r2ePqGE= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v1FEpQcr030677; Wed, 15 Feb 2017 09:51:26 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0319.002; Wed, 15 Feb 2017 09:51:26 -0500 From: "Roman D. Danyliw" To: "Mortensen, Andrew" , "dots@ietf.org" Thread-Topic: use of restconf for the data channel? Thread-Index: AQHShUvelq2Fax0X1U+DAQQ/dairhqFqKpDA Date: Wed, 15 Feb 2017 14:51:25 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104F01D17@marathon> References: <6AE56175-DBE7-4CD9-BA4E-5DCA88E901D8@arbor.net> In-Reply-To: <6AE56175-DBE7-4CD9-BA4E-5DCA88E901D8@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] use of restconf for the data channel? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 15 Feb 2017 14:51:33 -0000 DQoNCj4gU3ViamVjdDogW0RvdHNdIHVzZSBvZiByZXN0Y29uZiBmb3IgdGhlIGRhdGEgY2hhbm5l bD8NCj4gW3NuaXBdDQo+IA0KPiBTaW5jZSBSRVNUQ09ORiBpcyBub3cgYSBjb25jcmV0ZSBwcm9w b3NhbCwgaXQgc2VlbXMgDQo+IHdvcnRod2hpbGUgY29udGludWluZyB0aGUgZGViYXRlIGFoZWFk IG9mIHRoZSBpbnRlcmltIA0KPiBtZWV0aW5nLiAgQXJlIHRoZXJlIHNwZWNpZmljIGNvbmNlcm5z IGluIHRoZSBXRyANCj4gcmVnYXJkaW5nIHRoZSB1c2UgLi4uDQoNClRoaXMgZGlzY3Vzc2lvbiB0 b3BpYyBpcyBvbmUgd2UgbmVlZCB0byByZXNvbHZlLiAgV2UgY2FuIHN0YXJ0IGhlcmUgb24gdGhl IGxpc3QgYnV0IEknbGwgYWxzbyBhZGQgYSBzbG90IHRvIHRoZSBpbnRlcmltIG1lZXRpbmcgdG8g Y29udGludWUgdGhlIGNvbnZlcnNhdGlvbi4NCg0KUm9tYW4gDQoNCg== From nobody Wed Feb 15 08:24:43 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0563D1298C1 for ; Wed, 15 Feb 2017 08:24:43 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com 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 9rnA7TptT4eo for ; Wed, 15 Feb 2017 08:24:41 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0096.outbound.protection.outlook.com [104.47.38.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659FD1294FE for ; Wed, 15 Feb 2017 08:18:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oizHa7P0Yx0BemGSxyQWYD6y75zkTr5PGcDkrt6lSUY=; b=ef6hB9me3vLrgB3zQP6I+IEbdXhE7HgPcmd40Nd0MtTEm3kSdKHLL0k1S5dLnIDtKIM+tEa3QYJjSr8WvCi8Pm8bIjEx08NpHjYCGjnrjernbGb04ntYCZ8mS9MrIMGecIoYi7hJue5SEk+7x64zYUggiiqmuxoyIOCTzY8PUTY= Received: from MWHPR0101MB3118.prod.exchangelabs.com (10.174.167.145) by MWHPR0101MB3117.prod.exchangelabs.com (10.174.166.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 15 Feb 2017 16:17:49 +0000 Received: from MWHPR0101MB3118.prod.exchangelabs.com ([10.174.167.145]) by MWHPR0101MB3118.prod.exchangelabs.com ([10.174.167.145]) with mapi id 15.01.0888.030; Wed, 15 Feb 2017 16:17:50 +0000 From: "Mortensen, Andrew" To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . Thread-Index: AdKCER/slEaaT/pbTQCa8ffUgEh/YgEvK4mgADZPhAA= Date: Wed, 15 Feb 2017 16:17:50 +0000 Message-ID: <6601F335-76C8-4DDA-8DAA-A88A9F7F2E3B@arbor.net> References: <331a77a5ec074db69cf2bc2715a7645e@XCH-RCD-017.cisco.com> In-Reply-To: <331a77a5ec074db69cf2bc2715a7645e@XCH-RCD-017.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=amortensen@arbor.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [216.130.192.4] x-ms-office365-filtering-correlation-id: 1a5324c5-4e3f-42c6-1e03-08d455be2fe8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:MWHPR0101MB3117; x-microsoft-exchange-diagnostics: 1; MWHPR0101MB3117; 7:wLc4PrTVrJ5HQBMg56FkU3gLNiu7RtuDAXAehPQcVQ0wEJ8C4as5jTBazGe9fzAFnIC1XVCQF3LvKHtsY4sGSYKTRy5LX1wWGcOwkk/CYV4ScNQA3rTt+4XBaaFXzXQlQX1sghwo+3r2ayvIVg9zXQ2rWW5X4BGMrHRCc6YIqB82KIousxpI9vhm08rTkFmlqcosegKeAmMd9VoXsdphaWkY0E+/TK6slO8YWjLZxoyeZutpfoCnF0EG3EVY8/qxzFClsB6yuSpFkS5Wl2Ldhz1SDCfd+Lzs4tihit6DdnXVG8LUSehs4eWdCV4ZwCeg1SZFWGNthaoY8zgCfjuP0XvVRQJmrymak6le47S4NN3T/47QcXQBwNynqQtjiRo47YIMxkl8813ziFy1ZD+Qqazv1a7zcn2prqCVPwVKiB1ZV10zktRnYEtaj/vxchJX+Pn/gBB618TGOOpISJy4p6s6lrsOHFV4I/YxFCGcu7iXhMftnn7YECLERlpj92KzIAcXXJMkWtjoLJzDHMCPyw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:MWHPR0101MB3117; BCL:0; PCL:0; RULEID:; SRVR:MWHPR0101MB3117; x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(51914003)(24454002)(199003)(189002)(377454003)(50986999)(92566002)(54356999)(76176999)(2900100001)(6246003)(54906002)(8676002)(66066001)(3846002)(81166006)(8936002)(81156014)(2906002)(99286003)(36756003)(6116002)(102836003)(110136004)(101416001)(86362001)(38730400002)(229853002)(53936002)(6512007)(5660300001)(83716003)(6436002)(25786008)(3660700001)(33656002)(82746002)(230783001)(106356001)(54896002)(97736004)(4326007)(122556002)(6916009)(3280700002)(6506006)(2950100002)(68736007)(77096006)(236005)(6486002)(7736002)(189998001)(389900002)(105586002)(132733001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR0101MB3117; H:MWHPR0101MB3118.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_6601F33576C84DDA8DAAA88A9F7F2E3Barbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 16:17:50.0880 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0101MB3117 Archived-At: Cc: David Aviv , dots , Ehud Doron Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 15 Feb 2017 16:24:43 -0000 --_000_6601F33576C84DDA8DAAA88A9F7F2E3Barbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBGZWIgMTQsIDIwMTcsIGF0IDk6NTMgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRk eSkgPHRpcmVkZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0K DQpIaSBFaHVkLA0KDQpUaGFua3MgZm9yIHRoZSBkZXRhaWxlZCByZXZpZXcsIFBsZWFzZSBzZWUg aW5saW5lIChJIHdpbGwgcmVzcG9uZCB0byBkYXRhIGNoYW5uZWwgY29tbWVudHMgaW4gYSBzZXBh cmF0ZSBtYWlsKQ0KDQpGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgRWh1ZCBEb3Jvbg0KIOKApiBzbmlwLi4uDQo2LiAgICAgICBQYWdlIDE0IGZp Z3VyZSA1OiBUaGUgbWl0aWdhdGlvbiByZXF1ZXN0IGF0dHJpYnV0ZXMgYXJlIHJpZ2h0IGJ1dCBu b3QgZW5vdWdoLiBOZWVkIHRvIGFkZCBtb3JlIHRlbGVtZXRyeSBpbmZvIGFib3V0IHRoZSBhY3R1 YWwgYXR0YWNrIHRoYXQgaXQgaXMgcmVxdWlyZWQgdG8gbWl0aWdhdGUsIG5lZWQgdG8gY29uc2lk ZXIgYXR0cmlidXRlcyBpbiBkcmFmdC1kb3Jvbi1kb3RzLXRlbGVtZXRyeS0wMCBhcyBwYXJ0IG9m IHRoZSBkaXNjdXNzaW9uIGluIHRoZSBXRy4NCg0KW1RSXSBZZXMsIEkgcGxhbiB0byB1cGRhdGUg dGhlIGRyYWZ0IHdpdGggdGVsZW1ldHJ5IGluZm8gYmFzZWQgb24gb3V0Y29tZSBvZiBkcmFmdC1k b3Jvbi1kb3RzLXRlbGVtZXRyeS0wMC4NCg0KSSB1bmRlcnN0YW5kIG5lZWQgZm9yIGFuZCBzdXBw b3J0IHRoZSBlZmZvcnQgdG8gZW5zdXJlIHRlbGVtZXRyeSBiZXR3ZWVuIERPVFMgYWdlbnRzLCBi dXQgSeKAmW0gc2tlcHRpY2FsIGFib3V0IHRoZSBzdWdnZXN0aW9uIHRoYXQgdGhlIHJpZ2h0IHBs YWNlIGZvciBpdCBpcyBpbiB0aGUgc2lnbmFsIGNoYW5uZWwuIFRoZSBzaWduYWwgY2hhbm5lbCBy ZXF1aXJlbWVudHMgYXJlIHJlc3RyaWN0aXZlIGJ5IGRlc2lnbiAoc3ViLU1UVSBtZXNzYWdlIHNp emUsIGV4cGVjdGF0aW9uIG9mIHBhY2tldCBsb3NzLCBldGMuKSwgc3VnZ2VzdGluZyBpbmNvbXBh dGliaWxpdHkgd2l0aCB0aGUgcHJvcG9zZWQgdGVsZW1ldHJ5IGF0dHJpYnV0ZXMgaW4gZHJhZnQt ZG9yb24tZG90cy10ZWxlbWV0cnktMDAuIEFtb25nIG90aGVyIHRoaW5ncywgdGhhdCBkcmFmdCBw cm9wb3NlcyBDRUYgZm9yIGF0dGFjayBkZXRhaWxzIGFuZCB0aGUgaW5jbHVzaW9uIG9mIGEgbGlz dCBvZiBhdXRoZW50aWNhdGVkIHNvdXJjZXMuIFRpcnXigJlzIHNpZ25hbCBjaGFubmVsIGRyYWZ0 IHN1Z2dlc3RzIGFzc3VtaW5nIGFuIE1UVSBvZiBubyBtb3JlIHRoYW4gMTI4MCBieXRlcyBpZiB0 aGUgUE1UVSBpcyBub3Qga25vd24sIGFuZCBjb25jbHVkZXMgdGhhdCBhIG1heGltdW0gZGF0YWdy YW0gc2l6ZSBvZiA1NzYgYnl0ZXMgd2l0aCBhIERPVFMgcGF5bG9hZCBzaXplIG9mIDUwMCBieXRl cyBpcyBiZXN0IHRvIGVuc3VyZSB0aGUgc2lnbmFsIGNoYW5uZWwgd2lsbCBub3QgYmUgZnJhZ21l bnRlZC4NCg0KQWxsIG9mIHRoYXQgaXMgdG8gc2F5IEkgZGlzYWdyZWUgd2l0aCB0aGUgc3VnZ2Vz dGlvbiB0aGF0IHRoZSBzaWduYWwgY2hhbm5lbCBzaG91bGQgYmUgdGhlIHByaW1hcnkgdmVoaWNs ZSBmb3IgdGVsZW1ldHJ5LiBGZWVkYmFjaywgeWVzOyB1bnNjb3BlZCB0ZWxlbWV0cnksIG5vLiBI b3cgZG8gd2UgZGV0ZXJtaW5lIGlmIHRoZXJl4oCZcyBlbm91Z2ggdGVsZW1ldHJ5PyBIb3cgbXVj aCB0ZWxlbWV0cnkgZG9lcyB2ZW5kb3IgQSByZXF1aXJlIHRvIGZ1bmN0aW9uIGFzIGEgRE9UUyBz ZXJ2ZXIgb3IgY2xpZW50PyBIb3cgbXVjaCB0ZWxlbWV0cnkgbG9zcyBjYW4gZWl0aGVyIGFnZW50 IChhbmQgdmVuZG9yIGltcGxlbWVudGF0aW9uKSB3aXRoc3RhbmQ/DQoNCkluIGNvbnRyYXN0LCB0 aGUgZGF0YSBjaGFubmVsIHNlZW1zIGxpa2UgdGhlIGlkZWFsIHBsYWNlIGZvciB0aGUgc29ydCBv ZiB0ZWxlbWV0cnkgZGVzY3JpYmVkIGluIGRyYWZ0LWRvcm9uLWRvdHMtdGVsZW1ldHJ5LTAwLiBU aGVyZSBhcmUgbm8gcmVzdHJpY3RpdmUgc2l6ZSBvciBwYWNrZXQgbG9zcyBoYW5kbGluZyByZXF1 aXJlbWVudHMsIGFuZCBSRVNUQ09ORiBzdXBwb3J0cyBldmVudCBzdHJlYW1zIHRoYXQgd291bGQg c2VlbSB0byBmaXQgdGhlIG5lZWQgcXVpdGUgd2VsbC4NCg0KYW5kcmV3DQo= --_000_6601F33576C84DDA8DAAA88A9F7F2E3Barbornet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBGZWIg MTQsIDIwMTcsIGF0IDk6NTMgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgJmx0Ozxh IGhyZWY9Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbSIgY2xhc3M9IiI+dGlyZWRkeUBjaXNjby5j b208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3 bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0i cGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIg Y2xhc3M9IiI+SGkgRWh1ZCw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPlRoYW5rcyBm b3IgdGhlIGRldGFpbGVkIHJldmlldywgUGxlYXNlIHNlZSBpbmxpbmUgKEkgd2lsbCByZXNwb25k IHRvIGRhdGEgY2hhbm5lbCBjb21tZW50cyBpbiBhIHNlcGFyYXRlIG1haWwpPG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIi PjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IGJsdWU7 IGJvcmRlci1sZWZ0LXdpZHRoOiAxLjVwdDsgcGFkZGluZzogMGluIDBpbiAwaW4gNHB0OyIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBzb2xpZCBu b25lIG5vbmU7IGJvcmRlci10b3AtY29sb3I6IHJnYigyMjUsIDIyNSwgMjI1KTsgYm9yZGVyLXRv cC13aWR0aDogMXB0OyBwYWRkaW5nOiAzcHQgMGluIDBpbjsiIGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Gcm9tOjwvYj48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RG90cyBbPGEg aHJlZj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiByZ2IoMTQ5 LCA3OSwgMTE0KTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5tYWlsdG86 ZG90cy1ib3VuY2VzQGlldGYub3JnPC9hPl08c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGIgY2xhc3M9IiI+T24NCiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkVodWQgRG9yb248bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDvigKYgc25pcC4uLjwv bzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0IDAuNWluOyBm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyB0ZXh0LWlu ZGVudDogLTAuMjVpbjsiIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+Ni48c3BhbiBzdHlsZT0i Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48L3NwYW4+UGFnZSAxNCBmaWd1cmUgNToNCiBUaGUgbWl0aWdhdGlvbiByZXF1 ZXN0IGF0dHJpYnV0ZXMgYXJlIHJpZ2h0IGJ1dCBub3QgZW5vdWdoLiBOZWVkIHRvIGFkZCBtb3Jl IHRlbGVtZXRyeSBpbmZvIGFib3V0IHRoZSBhY3R1YWwgYXR0YWNrIHRoYXQgaXQgaXMgcmVxdWly ZWQgdG8gbWl0aWdhdGUsIG5lZWQgdG8gY29uc2lkZXIgYXR0cmlidXRlcyBpbjxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5kcmFmdC1kb3Jvbi1kb3RzLXRlbGVtZXRyeS0w MDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+ YXMNCiBwYXJ0IG9mIHRoZSBkaXNjdXNzaW9uIGluIHRoZSBXRy48bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpw IGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBj bGFzcz0iIj5bVFJdIFllcywgSSBwbGFuIHRvIHVwZGF0ZSB0aGUgZHJhZnQgd2l0aCB0ZWxlbWV0 cnkgaW5mbyBiYXNlZCBvbiBvdXRjb21lIG9mIGRyYWZ0LWRvcm9uLWRvdHMtdGVsZW1ldHJ5LTAw Ljwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkkgdW5kZXJzdGFuZCBuZWVkIGZvciBhbmQg c3VwcG9ydCB0aGUgZWZmb3J0IHRvIGVuc3VyZSB0ZWxlbWV0cnkgYmV0d2VlbiBET1RTIGFnZW50 cywgYnV0IEnigJltIHNrZXB0aWNhbCBhYm91dCB0aGUgc3VnZ2VzdGlvbiB0aGF0IHRoZSByaWdo dCBwbGFjZSBmb3IgaXQgaXMgaW4gdGhlIHNpZ25hbCBjaGFubmVsLiBUaGUgc2lnbmFsIGNoYW5u ZWwgcmVxdWlyZW1lbnRzIGFyZSByZXN0cmljdGl2ZSBieSBkZXNpZ24gKHN1Yi1NVFUgbWVzc2Fn ZQ0KIHNpemUsIGV4cGVjdGF0aW9uIG9mIHBhY2tldCBsb3NzLCBldGMuKSwgc3VnZ2VzdGluZyBp bmNvbXBhdGliaWxpdHkgd2l0aCB0aGUgcHJvcG9zZWQgdGVsZW1ldHJ5IGF0dHJpYnV0ZXMgaW4g ZHJhZnQtZG9yb24tZG90cy10ZWxlbWV0cnktMDAuIEFtb25nIG90aGVyIHRoaW5ncywgdGhhdCBk cmFmdCBwcm9wb3NlcyBDRUYgZm9yIGF0dGFjayBkZXRhaWxzIGFuZCB0aGUgaW5jbHVzaW9uIG9m IGEgbGlzdCBvZiBhdXRoZW50aWNhdGVkIHNvdXJjZXMuDQogVGlydeKAmXMgc2lnbmFsIGNoYW5u ZWwgZHJhZnQgc3VnZ2VzdHMgYXNzdW1pbmcgYW4gTVRVIG9mIG5vIG1vcmUgdGhhbiAxMjgwIGJ5 dGVzIGlmIHRoZSBQTVRVIGlzIG5vdCBrbm93biwgYW5kIGNvbmNsdWRlcyB0aGF0IGEgbWF4aW11 bSBkYXRhZ3JhbSBzaXplIG9mIDU3NiBieXRlcyB3aXRoIGEgRE9UUyBwYXlsb2FkIHNpemUgb2Yg NTAwIGJ5dGVzIGlzIGJlc3QgdG8gZW5zdXJlIHRoZSBzaWduYWwgY2hhbm5lbCB3aWxsIG5vdCBi ZSBmcmFnbWVudGVkLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+QWxs IG9mIHRoYXQgaXMgdG8gc2F5IEkgZGlzYWdyZWUgd2l0aCB0aGUgc3VnZ2VzdGlvbiB0aGF0IHRo ZSBzaWduYWwgY2hhbm5lbCBzaG91bGQgYmUgdGhlIHByaW1hcnkgdmVoaWNsZSBmb3IgdGVsZW1l dHJ5LiBGZWVkYmFjaywgeWVzOyB1bnNjb3BlZCB0ZWxlbWV0cnksIG5vLiBIb3cgZG8gd2UgZGV0 ZXJtaW5lIGlmIHRoZXJl4oCZcyBlbm91Z2ggdGVsZW1ldHJ5PyBIb3cgbXVjaCB0ZWxlbWV0cnkg ZG9lcyB2ZW5kb3IgQSByZXF1aXJlIHRvDQogZnVuY3Rpb24gYXMgYSBET1RTIHNlcnZlciBvciBj bGllbnQ/IEhvdyBtdWNoIHRlbGVtZXRyeSBsb3NzIGNhbiBlaXRoZXIgYWdlbnQgKGFuZCB2ZW5k b3IgaW1wbGVtZW50YXRpb24pIHdpdGhzdGFuZD88L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2PkluIGNvbnRyYXN0LCB0aGUgZGF0YSBjaGFubmVsIHNlZW1zIGxpa2UgdGhl IGlkZWFsIHBsYWNlIGZvciB0aGUgc29ydCBvZiB0ZWxlbWV0cnkgZGVzY3JpYmVkIGluIGRyYWZ0 LWRvcm9uLWRvdHMtdGVsZW1ldHJ5LTAwLiBUaGVyZSBhcmUgbm8gcmVzdHJpY3RpdmUgc2l6ZSBv ciBwYWNrZXQgbG9zcyBoYW5kbGluZyByZXF1aXJlbWVudHMsIGFuZCBSRVNUQ09ORiBzdXBwb3J0 cyBldmVudCBzdHJlYW1zIHRoYXQgd291bGQgc2VlbSB0byBmaXQNCiB0aGUgbmVlZCBxdWl0ZSB3 ZWxsLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+YW5kcmV3PC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6601F33576C84DDA8DAAA88A9F7F2E3Barbornet_-- From nobody Wed Feb 15 10:53:38 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6AA129B09 for ; Wed, 15 Feb 2017 10:53:36 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com 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 z_KXgwk5X7k2 for ; Wed, 15 Feb 2017 10:53:34 -0800 (PST) Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC9A129565 for ; Wed, 15 Feb 2017 10:53:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=4074; q=dns/txt; s=VRSN; t=1487184815; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=quWHran/EfK/jwuOGXFfDqroT0Xd45ICG61EiIOTeTc=; b=fiI5a2v9jt3D5Nm2E1jF2yYnTbIY8gbj1rtUEXm7ojwJMtQVCEJK2i1c NpkAbFOQS3vETJFw0YzYJd8qngtGMDLzUPUqRN/y9vzXOmAChYPAo2DXS tM+Plu7yXgZH52wCAvBjh2qO7oLcX1XVLkEgW8koaI9lSsjLLMJS2NqTO aUrJIBq0u/Uotlefu12GA7WRkaThZkEcLcIn6dte436FXrbZPJX0VE+uV AwTesujOONbaQc0mnywdcCnPBk6PALSATI8D4KezyoF6DK2YTH6zROw5E xG86VIi7tRfBIE6fDfoWB7Jo1EKz2cmcynismfwKP2Qo6nbi7yaa7EO1h A==; X-IronPort-AV: E=Sophos;i="5.35,166,1484006400"; d="scan'208";a="1534279" IronPort-PHdr: =?us-ascii?q?9a23=3AUpWpJx80TI1/WP9uRHKM819IXTAuvvDOBiVQ1KB3?= =?us-ascii?q?0+wcTK2v8tzYMVDF4r011RmSDNids6gP0rOL+4nbGkU4qa6bt34DdJEeHzQksu?= =?us-ascii?q?4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1?= =?us-ascii?q?Ov71GonPhMiryuy+4ZPebgFIiTanfb9+Mhq6oRjMusQWnIBvNrs/xhzVr3VSZu?= =?us-ascii?q?9Y33loJVWdnxb94se/4ptu+DlOtvwi6sBNT7z0c7w3QrJEAjsmNXs15NDwuhnY?= =?us-ascii?q?UQSP/HocXX4InRdOHgPI8Qv1Xpb1siv9q+p9xCyXNtD4QLwoRTiv6bpgRRn1gy?= =?us-ascii?q?kFKjE56nnahMxugqxGvBKvqR9xzIDVYI6JO/RxcbjQfc8BSmpEQspdSzZMD4G6?= =?us-ascii?q?YoASD+QBJ+FYr4zlqlcAsxWxGxOjBOzyyjBWnnP9wLU00+UiEQ3IwQctGNQOsG?= =?us-ascii?q?jKo9rvO6cSTP66wbLWzTrddfNW2Cz96InHchAnu/2DQbVwcc/IxEQpCgjLgFKQ?= =?us-ascii?q?qYn/MDOU0OQAq2mb4PR8VeKhkWInrBtxojepy8wxiYfJnpoYxk3Y+Slj3Yo4J9?= =?us-ascii?q?O1RFRmbdOkHpZcrT+WOoR5T886Xm1kpDw2xqAEtJO1ZiQG1ZQqywDFZ/GIdYWD?= =?us-ascii?q?/wjtW/yLIThigXJoYLe/hxGv/ke+0uD8Tcy00EpSripCj9nMqmgB1xzN5ciDTf?= =?us-ascii?q?tw5lyu2SyJ1wzO7uFFLkU0mrDaK54lxb4wi4YTvVjeEiPshkX5krWWdkQ/+uip?= =?us-ascii?q?5OTnZK/qqYObN49xkg3+M6IuldKjAekgLwQCQ3KX9fm+2bDt50H1XbVHg/Msnq?= =?us-ascii?q?XHv53XKtwXpqujDA9U1oYj5Qy/DzCj0NkAm3kHMExKdwiIj4j0JV7DO+74Auml?= =?us-ascii?q?g1Stizdrxv/GPrv7DprRKXjDla/tfaxh5E5E1Aoz0ddf6opJBbEGPPLzQVT8tN?= =?us-ascii?q?3GAR8lPQy42eHnCM9y1tBWZWXaSKOeLLj6sFKU6KQoOebGLNsZvyrmA/ko+/Co?= =?us-ascii?q?imU2zwwzZ66siNErZXm3A/kia2OYYjCk1tEdHG4FowcWUuHwiUaDXjgVbHG3Cf?= =?us-ascii?q?FvrgonAZ6rWN+QDrumh6aMiX+2?= X-IPAS-Result: =?us-ascii?q?A2G0AgC0oqRY//SZrQpeHAEBBAEBCgEBFwEBBAEBCgEBhAi?= =?us-ascii?q?BCQeDUooIkXGVVYIDCR8LhXgcgjkYAQEBAQEBAQEBAQECfAuCMyAPJhcQAQEBA?= =?us-ascii?q?QEBJgEBAQEBASMCPi0GAQEhETodAQgNDQImAgQlCxUGAQYFBBMJiXCwIIIlizQ?= =?us-ascii?q?BAQEHAQEBAQEBAQEBH4ELhUOCBAiCYoMXgVSCNQwuLoIxBZt3AYZujSBThESJd?= =?us-ascii?q?IpZiD4fgTlRFRglEQGGMXUBiUSBDAEBAQ?= Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id v1FIrSkp028726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 15 Feb 2017 13:53:28 -0500 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Wed, 15 Feb 2017 13:53:28 -0500 From: "Teague, Nik" To: "dots@ietf.org" Thread-Topic: I-D Action: draft-teague-dots-protocol-02.txt Thread-Index: AQHSh7zLLQiatqw38Ey0Qq5axsllmA== Date: Wed, 15 Feb 2017 18:53:27 +0000 Message-ID: <88C6102C-4253-408A-BBF1-75ABBDE7C7E3@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.0.161115 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-ID: <2F2E1BF3F0432642B4BC066CABAA0BFD@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Dots] FW: I-D Action: draft-teague-dots-protocol-02.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 15 Feb 2017 18:53:36 -0000 RllJIOKAkyBhIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LXRlYWd1ZS1kb3RzLXByb3RvY29sIGhhcyBi ZWVuIHVwbG9hZC4gIFRoaXMgdmVyc2lvbiByZWZvY3VzZXMgb24gdGhlIHNpZ25hbCBjaGFubmVs IG9ubHkgYWZ0ZXIgZGlzY3Vzc2lvbnMgdG8gY29uc29saWRhdGUgZGF0YSBjaGFubmVsIGVmZm9y dHMuDQoNClRoYW5rcywgYW5kIGFzIGFsd2F5cyDigJMgY29tbWVudHMgYXJlIGFwcHJlY2lhdGVk IGFuZCBlbmNvdXJhZ2VkLg0KDQotTmlrDQoNCk9uIDE1LzAyLzIwMTcsIDE4OjQ5LCAiSS1ELUFu bm91bmNlIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxpLWQtYW5ub3Vu Y2UtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PiB3cm90ZToNCg0KICAgIA0KICAgIEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICANCiAgICAN CiAgICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEREb1MgT3BlbiBUaHJlYXQgU2lnbmFsaW5n IFByb3RvY29sDQogICAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBOaWsgVGVhZ3VlDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBBbmRyZXcgTW9ydGVuc2VuDQogICAgCUZpbGVuYW1l ICAgICAgICA6IGRyYWZ0LXRlYWd1ZS1kb3RzLXByb3RvY29sLTAyLnR4dA0KICAgIAlQYWdlcyAg ICAgICAgICAgOiAzMA0KICAgIAlEYXRlICAgICAgICAgICAgOiAyMDE3LTAyLTE1DQogICAgDQog ICAgQWJzdHJhY3Q6DQogICAgICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgRGlzdHJpYnV0ZWQt RGVuaWFsLW9mLVNlcnZpY2UgKEREb1MpIE9wZW4NCiAgICAgICBUaHJlYXQgU2lnbmFsaW5nIChE T1RTKSwgYSBwcm90b2NvbCBmb3IgcmVxdWVzdGluZyBhbmQgbWFuYWdpbmcNCiAgICAgICBtaXRp Z2F0aW9uIG9mIEREb1MgYXR0YWNrcy4NCiAgICANCiAgICAgICBET1RTIG1pdGlnYXRpb24gcmVx dWVzdHMgb3ZlciB0aGUgc2lnbmFsIGNoYW5uZWwgcGVybWl0IGRvbWFpbnMgdG8NCiAgICAgICBz aWduYWwgdGhlIG5lZWQgZm9yIGhlbHAgZmVuZGluZyBvZmYgRERvUyBhdHRhY2tzLCBzZXR0aW5n IHRoZSBzY29wZQ0KICAgICAgIGFuZCBkdXJhdGlvbiBvZiB0aGUgcmVxdWVzdGVkIG1pdGlnYXRp b24uICBFbGVtZW50cyBjYWxsZWQgRE9UUw0KICAgICAgIHNlcnZlcnMgZmllbGQgdGhlIHNpZ25h bHMgZm9yIGhlbHAsIGFuZCBlbmFibGUgZGVmZW5zaXZlDQogICAgICAgY291bnRlcm1lYXN1cmVz IHRvIGRlZmVuZCBhZ2FpbnN0IHRoZSBhdHRhY2sgcmVwb3J0ZWQgYnkgdGhlIGNsaWVudHMsDQog ICAgICAgcmVwb3J0aW5nIHRoZSBzdGF0dXMgb2YgdGhlIGRlbGVnYXRlZCBkZWZlbnNlIHRvIHRo ZSByZXF1ZXN0aW5nDQogICAgICAgY2xpZW50cy4gIERPVFMgY2xpZW50cyBhZGRpdGlvbmFsbHkg bWF5IHVzZSBhIHJlbGlhYmxlIGRhdGEgY2hhbm5lbA0KICAgICAgIHRvIG1hbmFnZSBmaWx0ZXJz IGFuZCBibGFjay0gYW5kIHdoaXRlLWxpc3RzIHRvIHJlc3RyaWN0IG9yIGFsbG93DQogICAgICAg dHJhZmZpYyB0byB0aGUgY2xpZW50cycgZG9tYWlucyBhcmJpdHJhcmlseS4gIFRoZSBET1RTIHNp Z25hbCBjaGFubmVsDQogICAgICAgbWF5IG9wZXJhdGUgb3ZlciBVRFAgW1JGQzA3NjhdIGFuZCBp ZiBuZWNlc3NhcnkgVENQIFtSRkMwNzkzXS4gIFRoaXMNCiAgICAgICByZXZpc2lvbiBkaXNjdXNz ZXMgYSB0cmFuc3BvcnQtYWdub3N0aWMgYXBwcm9hY2ggdG8gdGhpcyBjaGFubmVsLA0KICAgICAg IGZvY3VzaW5nIG9uIHRoZSBtZXNzYWdlIGV4Y2hhbmdlcyBhbmQgZGVsZWdhdGluZyB0cmFuc3Bv cnQgc3BlY2lmaWNzDQogICAgICAgdG8gb3RoZXIgZG9jdW1lbnRzLiAgRGlzY3Vzc2lvbiBvZiB0 aGUgcmVsaWFibGUgZGF0YSBjaGFubmVsIG1heSBiZQ0KICAgICAgIGZvdW5kIGluIFtJLUQucmVk ZHktZG90cy1kYXRhLWNoYW5uZWxdLg0KICAgIA0KICAgIA0KICAgIFRoZSBJRVRGIGRhdGF0cmFj a2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRlYWd1ZS1kb3RzLXByb3RvY29sLw0KICAgIA0KICAgIFRo ZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KICAgIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10ZWFndWUtZG90cy1wcm90b2NvbC0wMg0KICAgIA0K ICAgIEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCiAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtdGVhZ3VlLWRvdHMtcHJv dG9jb2wtMDINCiAgICANCiAgICANCiAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICAgdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCiAgICANCiAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu b255bW91cyBGVFAgYXQ6DQogICAgZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8N CiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KICAgIEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCiAgICBJLUQtQW5ub3VuY2VAaWV0Zi5v cmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5j ZQ0KICAgIEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3No YWRvdy5odG1sDQogICAgb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50 eHQNCiAgICANCg0K From nobody Wed Feb 15 16:04:20 2017 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 8C117129C0B; Wed, 15 Feb 2017 16:04:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148720345553.31523.5616766500805936690.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 16:04:15 -0800 Archived-At: Cc: dots@ietf.org Subject: [Dots] DDoS Open Threat Signaling (dots) WG Virtual Meeting: 2017-02-22 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 16 Feb 2017 00:04:15 -0000 The DDoS Open Threat Signaling (dots) Working Group will hold a virtual interim meeting on 2017-02-22 from 10:00 to 11:30 US/Eastern. Agenda: ==[ Agenda ]== 1. Note well, logistics and introduction (chairs, 5 min) 2. Use Case Discussion (15 min) - draft-ietf-dots-use-cases-03 (Roland Dobbins) 3. Requirements Discussion (10 min) - draft-ietf-dots-requirements-03 (Andrew Mortensen, 5 min) - Additional requirements discussion (5 min) 4. Architecture Discussion (10 min) - draft-ietf-dots-architecture-01 (Andrew Mortensen, 5 min) - Additional architecture discussion (5 min) 5. Protocol Drafts (40 min) - draft-reddy-dots-data-channel-03 (Tiru Reddy, 10 min) - draft-reddy-dots-signal-channel-07 (Tiru Reddy, 10 min) - Discussion: Use of RESTCONF (15 min) - Additional Discussion (5 min) 6. Open Mic (5 min) 7. Closing (chairs, 5 min) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m16c3d7c775e02a7b3b8e12dc7753c778 From nobody Wed Feb 15 20:18:56 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176EB12947E for ; Wed, 15 Feb 2017 20:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.512 X-Spam-Level: X-Spam-Status: No, score=-14.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 AzknYSYNEjit for ; Wed, 15 Feb 2017 20:18:51 -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 446751293FF for ; Wed, 15 Feb 2017 20:18:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45956; q=dns/txt; s=iport; t=1487218731; x=1488428331; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=skoz5W1/RD5URhsCazSTu11uLsmQgHeFLjTbFk7ohFQ=; b=DDXHjFHR7KOpUJzixa1cjChAjt9dFNYk3JSw1K9CN3C5VUwSFTZ8BOtz NcyD55U7wpZYPagDCI2oOuFw9WeZlHNewncFnMMo96kapY6V38wpID5ly sPgQcvU+fsKNcvCaSH5y0CbcSMdYvZalBFAps0EgUTNZoKh7hOCjXOFI7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAQDbJ6VY/5ldJa1VCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvYmGBCQeNWpIQlTaCCQMfAQqFeAKCFT8YAQIBAQEBAQEBYii?= =?us-ascii?q?EcAEBAQQBAStBBAcQAgEIEQQBASEBAgQHJwsUCQgBAQQBDQUIEYlQDrJVK4sQA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGTYRvhCcGAwENHQcohS8Fj0SMNQGGboM?= =?us-ascii?q?gh3yCBIUXiXSILYppAR84gQBRFT2ERR0ZgUh1AYgUAQEkB4EDgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,167,1484006400"; d="scan'208,217";a="207352858" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 04:18:48 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v1G4ImT9015158 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 04:18:48 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.1210.3; Wed, 15 Feb 2017 22:18:47 -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.1210.000; Wed, 15 Feb 2017 22:18:47 -0600 From: "Tirumaleswar Reddy (tireddy)" To: kaname nishizuka , Ehud Doron , "'dots'" Thread-Topic: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . Thread-Index: AdKCER/slEaaT/pbTQCa8ffUgEh/YgEwQ2SQACwcrIAAG9DI0A== Date: Thu, 16 Feb 2017 04:18:47 +0000 Message-ID: <73716c67d08b4de5b8e6df1394da199f@XCH-RCD-017.cisco.com> References: 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.65.84.157] Content-Type: multipart/alternative; boundary="_000_73716c67d08b4de5b8e6df1394da199fXCHRCD017ciscocom_" MIME-Version: 1.0 Archived-At: Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 16 Feb 2017 04:18:55 -0000 --_000_73716c67d08b4de5b8e6df1394da199fXCHRCD017ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kaname, Please see inline [TR] for responses From: kaname nishizuka [mailto:kaname@nttv6.jp] Sent: Wednesday, February 15, 2017 11:27 AM To: Tirumaleswar Reddy (tireddy) ; Ehud Doron ; 'dots' Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 . Hi Tiru, I really appreciate your time and effort. Please see my comments on the drafts. # draft-reddy-dots-signal-channel-07 1. [General] I believe that DOTS request should not be another tool of bloc= king other one's traffic. Is there any validation mechanism of requested ta= rget-ips, target-ports and target-protocols? Even If it is out side of the = DOTS specification, how about returning 4.xx codes when the requested targe= t-* is not a property of the organization. [TR] The validation scope is outside the scope of this draft, 4.xx error co= de is already used in the draft to identity invalid requests. 2. [page14] Does one DOTS client and DOTS server peer have only one signal = channel and one data channel? (I'm thinking about a namespace of the "alias= -name") [TR] No, DOTS peers can have more than one signal and data channel but the = recommendation is to use only signal and data channel to reduce connection = setup delay. If their are multiple data channels, "DOTS signal" in Fig.5 should specify = according data channel when it refers to "alias-names" of the identifiers. [TR] I did not get the comment. 3. [Page21] How about adding status of "mitigation delete is in progress" l= ike status:1. Here is a life cycle of a mitigation in our environment. Activating and= deleting of mitigation could take several seconds (or minutes). POST. - activating(status=3D1) STATUS AFTER ACTIVATED - attack mitigated (status=3D2) - attack stopped (status=3D3) - attack exceeded capability(status=3D4) DELETE - deleting(status=3D5?) - deleted(RETURN 4.04) [TR] Delete is a confirmable message, DOTS server will send an ACK to ackno= wledge the receipt of the message to avoid retransmissions from the DOTS cl= ient. After the mitigation request is successfully deleted, DOTS server ret= urns 2.02 (Deleted) response code, thus conveying the transient status in t= his case is not necessary. 4. [Page25] 5.4 b) I couldn't find "retransmission timeout value" attribute= in the later figures. Is that equivalent to "ack-timeout"? [TR] The initial retransmission timeout value is based on the ack-timeout (= see https://tools.ietf.org/html/rfc7252#section-4.2). 5. [Page27] "policy-id" in "signal-config" is different from "policy-id" in= "mitigation-scole". How about using "session-id" in this case? [TR] Policy-id is a unique identifier identifying the signal channel sessio= n configuration request. # draft-reddy-dots-data-channel-03 1. [General] Data channel doesn't have heartbeat mechanism. I guess the rea= son is that there is heartbeat mechanism in the signal channel so it is eno= ugh, is that right? [TR] No, the heartbeat mechanism in signal channel cannot be used for data = channel. DOTS signal channel is using the "CoAP ping mechanism". For data c= hannel, TLS heartbeat can be used. I have updated draft. 2. [related to Ehud's question 8] I-D.ietf-netmod-acl-model says "ACL is an= ordered list of Access List Entries (ACE)" but I couldn't find a text abou= t how they are ordered. Should we have a operation of changing the order of= ACEs installed in a DOTS server? [TR] PUT can be used by the DOTS client to re-order/update/modify the list = of ACE conveyed to the DOTS server. Updated draft to discuss about PUT. -Tiru thank you, Kaname On 2017/02/14 23:58, Tirumaleswar Reddy (tireddy) wrote: Hi Ehud, Please see inline for responses to comments on draft-reddy-dots-data-channe= l-03 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron Sent: Wednesday, February 8, 2017 7:21 PM To: 'dots' Cc: David Aviv Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-0= 7 and draft-reddy-dots-data-channel-03 . Tiru and authors Hi Attached please find my comments and feedbacks to draft-reddy-dots-signal-c= hannel-07 and draft-reddy-dots-data-channel-03 . Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel = draft-reddy-dots-signal-channel-07 1. General comment: For all signals in the draft, need to add means t= o allow vendor specific attributes as part of all signals transactions 2. General comment: Just for clarity, need to explicitly mention on e= ach figure when it is an example or the actual API 3. Page 3 second paragraph : DOTS should not be limited to "enterpris= e network" only . 4. Page 4 chapter 4: The overall context of the "happy eyeballs" and = its relations (or coexistence) to CoAP is not clear. 5. Page 7 chapter 5.2.1: The need for YANG model cannot be understood= from text. What are the needs for YANG models? What is the relation to the= JSONs in the other chapters in the draft 6. Page 14 figure 5: The mitigation request attributes are right but = not enough. Need to add more telemetry info about the actual attack that it= is required to mitigate, need to consider attributes in draft-doron-dots-t= elemetry-00 as part of the discussion in the WG. 7. Page 15 Life time attribute: More reasonable to have this attribut= e in minutes rather than seconds, bigger default can also suggested 8. Page 15 last paragraph: Not sure that target port or target protoc= ol can define a protected entity. IP, FQDN, URI are the only "stand alone" = attributes , port and protocol are companion attributes. See also figure 9 = . 9. Page 15 last paragraph: The mitigation request is not clear, to wh= ich identifier the text is related ? "policy ID" ? I think the best is ha= ve another attribute to define the priority of mitigation requests 10. Page 21 table: The return status are right but not enough. Need to ad= d more telemetry info about the actual mitigation going on (how much traffi= c was mitigated) and the attack that are mitigated, need to consider attrib= utes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. 11. Page 15 : Need to find the way to bind the target-ips with target-por= t-ranges and target-protocols, meaning that the server needs to understand = the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on = so forth. 12. Page 21 last paragraph: This is very strong point. 13. Page 25 : Regarding attack status, same point about telemetry. 14. Page 25 chapter 5.4: I believe it can valuable to add a short high le= vel description about the proposed API flow, same as you did for 5.3 . 15. Page 27: The necessity of policy_id here is not clear enough, are th= e "Signal Channel Session Configuration" define only "single" DOTS session = or the entire communication between Client and Server for several DOTS requ= est for mitigation? 16. Page 27: Not sure about the reason for "at least one of the attribute= s heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor = MUST be present." Also consider to change to "presented". 17. Page 30 chapter 5.5: Need to specify the overall scenario, in reactio= n to which signal (or API transaction POST of Mitigation Request , unidirec= tional notification from Server as describes in page 23 in page 21 ?) the = redirection occurred ? Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel dr= aft-reddy-dots-data-channel-03 1. General comment: For all signal in the draft, need to add means to= allow vendor specific attributes as part of all signals transactions [TR] Agreed, updated draft. 2. Page 5 second paragraph: Why it is required to configure the DOTS = signal channel session ? [TR] No need to configure DOTS signal channel session, fixed second paragra= ph. 3. Page 8 chapter 3.2.1 : Any reason for not including these identifi= ers in the DOTS signal channel draft ? [TR] Identifiers created for resources in DOTS data channel are used in DOT= S signal channel to request DDOS mitigation. It's the responsibility of DOT= S data channel to create aliases for resources (see https://tools.ietf.org/= html/draft-ietf-dots-requirements-03#section-2.3). The main reason for DOTS= signal channel not creating identifiers is the message size may exceed Pat= h MTU. 4. Page 9 figure 3 : Need to find the way to bind the target-ips with= target-port-ranges and target-protocols, meaning that the server needs to = understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53= and so on so forth. [TR] Yes, it is possible; create different aliases for IP1 TCP port 80 and = IP2 UDP port 53. 5. Page 13 chapter 3.3 : Need to emphasize that filtering rules are r= elevant for both client server direct communication and through a DOTS gate= way. The chapter is a bit confusing. [TR] Thanks, fixed chapter 3.3. 6. Page 14 chapter 3.3 : I am missing the white-list installation, is= it by using the permit action ? [TR] Yes, "permit" action is used for white-list installation; it's define= d in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 7. Page 15 figure 8: For DDoS it is highly valuable to have rate limi= t as an action. Consider adding such action (if already defined need to exp= lain where and how). [TR] Done, updated draft. 8. Page 15 figure 8: Need to consider adding priority to an ACL to su= pport cases when several filtering rules are conflicting. [TR] We are not doing anything new to ACL, ACL an ordered list of Access L= ist Entries (ACE) based on priority. 9. Page 15 : The action field cannot be optional attribute. [TR] As per https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 if t= he action field not specified then "deny" is the default action. 10. Page 16 chapter 3.3.3: Need to add more telemetry info about the actu= al traffic that was blocked (bps, pps and so on), but as I believe this mig= ht be another issue... [TR] Chapter 3.3.3 only discusses telemetry details of number of matches fo= r the installed filtering rules. -Tiru Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_73716c67d08b4de5b8e6df1394da199fXCHRCD017ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kaname,<= /span>

 

Please see inline [TR]= for responses

 

From:= kaname nishizuka [mailto:kaname@nttv6.jp]
Sent: Wednesday, February 15, 2017 11:27 AM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; Ehud Dor= on <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signa= l-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru,

I really appreciate your time and effort.
Please see my comments on the drafts.

# draft-reddy-dots-signal-channel-07

1. [General] I believe that DOTS request should not be another tool of bloc= king other one's traffic. Is there any validation mechanism of requested ta= rget-ips, target-ports and target-protocols? Even If it is out side of the = DOTS specification, how about returning 4.xx codes when the requested target-* is not a property of the organizati= on.

[TR] The validation scope is outside the scope of this draft, 4.xx= error code is already used in the draft to identity invalid requests.=

2. [page14] Does one = DOTS client and DOTS server peer have only one signal channel and one data = channel? (I'm thinking about a namespace of the "alias-name")

[TR] No, DOTS peers can have more than one signal and data channel= but the recommendation is to use only signal and data channel to reduce co= nnection setup delay.

If their are multiple= data channels, "DOTS signal" in Fig.5 should specify according d= ata channel when it refers to "alias-names" of the identifiers.

[TR] I did not get the comment.

3. [Page21] How about= adding status of "mitigation delete is in progress" like status:= 1.
    Here is a life cycle of a mitigation in our environment.= Activating and deleting of mitigation could take several seconds (or minut= es).
    POST.
     - activating(status=3D1)
    STATUS AFTER ACTIVATED
     - attack mitigated (status=3D2)
     - attack stopped (status=3D3)
     - attack exceeded capability(status=3D4)
    DELETE
     - deleting(status=3D5?)
     - deleted(RETURN 4.04)

[TR] Delete is a confirmable message, DOTS server will send an ACK= to acknowledge the receipt of the message to avoid retransmissions from th= e DOTS client. After the mitigation request is successfully deleted, DOTS server returns 2.02 (Deleted) response code,= thus conveying the transient status in this case is not necessary.

4. [Page25] 5.4 b) I = couldn't find "retransmission timeout value" attribute in the lat= er figures. Is that equivalent to "ack-timeout"?

[TR] The initial retransmission timeout val= ue is based on the ack-timeout (see https://tools.ietf.org/html/rfc7252#sec= tion-4.2).

5. [Page27] "policy-id" in "signal-config" is different= from "policy-id" in "mitigation-scole". How about usin= g "session-id" in this case?

[TR] Policy-id is a unique identifier identifying the signal chann= el session configuration request.

# draft-reddy-dots-da= ta-channel-03

1. [General] Data channel doesn't have heartbeat mechanism. I guess the rea= son is that there is heartbeat mechanism in the signal channel so it is eno= ugh, is that right?

[TR] No, the heartbeat mechanism in signal channel cannot be used = for data channel. DOTS signal channel is using the “CoAP ping mechani= sm”. For data channel, TLS heartbeat can be used. I have updated draft.

2. [related to Ehud's= question 8] I-D.ietf-netmod-acl-model says "ACL is an ordered list of= Access List Entries (ACE)" but I couldn't find a text about how they = are ordered. Should we have a operation of changing the order of ACEs installed in a DOTS server?

[TR] PUT can be used by the DOTS client to re-order/update/modify = the list of ACE conveyed to the DOTS server. Updated draft to discuss about= PUT.

-Tiru


thank you,
Kaname

On 2017/02/14 23:58, Tirumaleswar Reddy (tireddy) wr= ote:

Hi Ehud,

 

Please see inline for = responses to comments on draft-reddy-dots-data-channel-03=

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radw= are.com>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-ch= annel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru and authors Hi

 

Attached please find m= y comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-re= ddy-dots-data-channel-03 .

 

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy= -dots-signal-channel-07

 

1.     &= nbsp; General comment: For all signals in the draft, need= to add means to allow vendor specific attributes as part of all signals tr= ansactions

 

2.     &= nbsp; General comment: Just for clarity, need to explicit= ly mention on each figure when it is an example or the actual API

 

3.     &= nbsp; Page 3 second paragraph : DOTS should not be limite= d to “enterprise network” only

.

4.     &= nbsp; Page 4 chapter 4: The overall context of the “= ;happy eyeballs” and its relations (or coexistence) to CoAP is not cl= ear.  

 

5.     &= nbsp; Page 7 chapter 5.2.1: The need for YANG model canno= t be understood from text. What are the needs for YANG models? What is the = relation to the JSONs in the other chapters in the draft

 

6.     &= nbsp; Page 14 figure 5: The mitigation request attributes= are right but not enough. Need to add more telemetry info about the actual= attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

7.     &= nbsp; Page 15 Life time attribute: More reasonable to have this attribute in minutes rather tha= n seconds, bigger default can also suggested

 

8.     &= nbsp; Page 15 last paragraph: Not sure that target port or target protocol can define a protect= ed entity. IP, FQDN, URI are the only “stand alone” attributes = , port and protocol are companion attributes. See also figure 9 .

 

9.     &= nbsp; Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is relate= d ?   “policy ID” ? I think the best is have another = attribute to define the priority of mitigation requests

 

10.   Page 21 table: The return status are right but not = enough. Need to add more telemetry info about the actual mitigation going o= n (how much traffic was mitigated) and the attack that are mitigated, need = to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

11.   Page 15 : Need to find the way to bind the target-i= ps with target-port-ranges and target-protocols, meani= ng that the server needs to understand the exact scope of attack, e.g. IP1 = TCP port 80, IP2 UDP port 53 and so on so forth.

 

12.   Page 21 last paragraph: This is very strong point.<= o:p>

 

13.   Page 25 : Regarding attack status, same point about= telemetry.

 

14.   Page 25 chapter 5.4: I believe it can valuable to a= dd a short high level description about the proposed API flow, same as you = did for 5.3 .

 

15.   Page 27:  The necessity of policy_id here is n= ot clear enough, are the “Signal Channel Session Configuration”= define only “single” DOTS session or the entire communication = between Client and Server for several DOTS request for mitigation?

 

16.   Page 27: Not sure about the reason for “at le= ast one of the attributes heartbeat-interval or max-retransmit or ack-timeo= ut or ack-random-factor MUST be present.” Also consider to change to = “presented”.

 

17.   Page 30 chapter 5.5: Need to specify the overall sc= enario, in reaction to which signal (or API transaction POST of Mitigation = Request , unidirectional notification from Server as describes in page 23 i= n page 21 ?) the  redirection occurred ?

 

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-d= ots-data-channel-03

 

1.     &= nbsp; General comment: For all signal in the draft, need = to add means to allow vendor specific attributes as part of all signals tra= nsactions

 

[TR] Agreed, updated draft.

 

2.     &= nbsp; Page 5 second paragraph: Why it is required to conf= igure the DOTS signal channel session ?  

 

[TR] No need to config= ure DOTS signal channel session, fixed second paragraph.<= /p>

 

3.     &= nbsp; Page 8 chapter 3.2.1 : Any reason for not including= these identifiers in the DOTS signal channel draft ?

 

[TR] Identifiers creat= ed for resources in DOTS data channel are used in DOTS signal channel to re= quest DDOS mitigation. It’s the responsibility of DOTS data channel t= o create aliases for resources (see https://tools.ietf.org/html/draft-ietf-dots-requirements-03= #section-2.3). The main reason for DOTS s= ignal channel not creating identifiers is the message size may exceed Path MTU.

 

 

4.     &= nbsp; Page 9 figure 3 : Need to find the way to bind the = target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e= .g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

[TR] Yes, it is possib= le; create different aliases for IP1 TCP port 80 and IP2 UDP port 53.

 

 

5.     &= nbsp; Page 13 chapter 3.3 : Need to emphasize that filter= ing rules are relevant for both client server direct communication and thro= ugh a DOTS gateway. The chapter is a bit confusing.

 

[TR] Thanks, fixed cha= pter 3.3.

 

 

6.     &= nbsp; Page 14 chapter 3.3 : I am missing the white-list i= nstallation, is it by using the permit action ?

 

[TR]  Yes, “= ;permit” action is used for white-list installation; it’s defin= ed in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09

 

 

7.     &= nbsp; Page 15 figure 8: For DDoS it is highly valuable to= have rate limit as an action. Consider adding such action (if already defi= ned need to explain where and how).

 

[TR] Done, updated draft.

 

8.     &= nbsp; Page 15 figure 8: Need to consider adding priority = to an ACL to support cases when several filtering rules are conflicting.

 

[TR]  We are not = doing anything new to ACL, ACL an ordered list of Access List Entries (ACE)= based on priority.

 

 

9.     &= nbsp; Page 15 : The action field cannot be optional attri= bute.

 

[TR] As per https:/= /tools.ietf.org/html/draft-ietf-netmod-acl-model-09 if the action field not specified then “deny” is the default action.

 

10.   Page 16 chapter 3.3.3: Need to add more telemetry i= nfo about the actual traffic that was blocked (bps, pps and so on), but as = I believe this might be another issue…

 

[TR] Chapter 3.3.3 onl= y discusses telemetry details of number of matches for the installed filter= ing rules.

 

-Tiru

 

Thanks,

 

Ehud Doron |=  Senior Architect, Radware CTO office | M:<= span style=3D"font-size:10.0pt;font-family:"Tahoma",sans-serif;co= lor:#999999"> +972-54-7575503 | T: +972-72-3917120

 

 

 

 




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

 

--_000_73716c67d08b4de5b8e6df1394da199fXCHRCD017ciscocom_-- From nobody Wed Feb 15 20:29:00 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35BF12945A for ; Wed, 15 Feb 2017 20:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 yxWryFTiapqh for ; Wed, 15 Feb 2017 20:28:58 -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 20F0C1293F3 for ; Wed, 15 Feb 2017 20:28:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2686; q=dns/txt; s=iport; t=1487219338; x=1488428938; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+eT98tmCU2c7kd7fiVq9bqf8bLi7glv2FSxwjs38hXM=; b=MUJhygSi66IonzO2bzpIPfoe/Mft6eW/kbAmsxoUSIezPNkRGcKN6rfy ueqFo+612pNdoMTncZnSdAo+e6pFi+fKPrv++SZnxpXuMq8kTNt8PUYlo 6iM8PQoS5o1ECt1PYB5pUh+Y48oXgRzGCELJ+ALkPxJe3gCVRzfiOzktl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAQA1KqVY/51dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHg1KKCJIQlTaCDCyFdgIagXs/GAECAQEBAQEBAWIdC4R?= =?us-ascii?q?wAQEBBCMRQw4EAgEIEQQBAQMCIwMCAgIwFAEGAQEFAwIEEwiJYQ6wMoIlizsBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdgQuFQoRvgxeEQ4JfBY9EjDUBhm6LHIIEU4R?= =?us-ascii?q?EiXSTFgEfOIEAURUYhmh1AYlEgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,167,1484006400"; d="scan'208";a="207354753" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 04:28:57 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v1G4SvIn024086 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Feb 2017 04:28:57 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Feb 2017 22:28: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.1210.000; Wed, 15 Feb 2017 22:28:56 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "dots@ietf.org" Thread-Topic: New Version Notification for draft-reddy-dots-data-channel-04.txt Thread-Index: AQHSiAxVD5BuOUr7X06GXgqH0vZcPaFrCLNw Date: Thu, 16 Feb 2017 04:28:56 +0000 Message-ID: <4a8d4e898bcd4907bde4cbd10f1b27bc@XCH-RCD-017.cisco.com> References: <148721896874.31395.428385694160707671.idtracker@ietfa.amsl.com> In-Reply-To: <148721896874.31395.428385694160707671.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.84.157] 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-data-channel-04.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 16 Feb 2017 04:29:00 -0000 VGhpcyByZXZpc2lvbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVkZHktZG90 cy1kYXRhLWNoYW5uZWwtMDQgYWRkcmVzc2VzIGNvbW1lbnRzIGZyb20gRWh1ZC4gQ29tbWVudHMg YW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KDQotVGlydQ0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxNyA5 OjUzIEFNDQpUbzogQW5kcmV3IE1vcnRlbnNlbiA8YW1vcnRlbnNlbkBhcmJvci5uZXQ+OyBQcmFz aGFudGggUGF0aWwgKHByYXNwYXRpKSA8cHJhc3BhdGlAY2lzY28uY29tPjsgTmlrIFRlYWd1ZSA8 bnRlYWd1ZUB2ZXJpc2lnbi5jb20+OyBMaWFuZyBYaWEgPGZyYW5rLnhpYWxpYW5nQGh1YXdlaS5j b20+OyBLYW5hbWUgTmlzaGl6dWthIDxrYW5hbWVAbnR0djYuanA+OyBNb2hhbWVkIEJvdWNhZGFp ciA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IFRpcnVtYWxlc3dhciBSZWRkeSAodGly ZWRkeSkgPHRpcmVkZHlAY2lzY28uY29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1yZWRkeS1kb3RzLWRhdGEtY2hhbm5lbC0wNC50eHQNCg0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtcmVkZHktZG90cy1kYXRhLWNoYW5uZWwtMDQudHh0DQpoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1yZWRkeS1kb3RzLWRh dGEtY2hhbm5lbA0KUmV2aXNpb246CTA0DQpUaXRsZToJCURpc3RyaWJ1dGVkIERlbmlhbC1vZi1T ZXJ2aWNlIE9wZW4gVGhyZWF0IFNpZ25hbGluZyAoRE9UUykgRGF0YSBDaGFubmVsDQpEb2N1bWVu dCBkYXRlOgkyMDE3LTAyLTE1DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6 CQkyMQ0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1yZWRkeS1kb3RzLWRhdGEtY2hhbm5lbC0wNC50eHQNClN0YXR1czogICAgICAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yZWRkeS1kb3RzLWRhdGEtY2hh bm5lbC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt cmVkZHktZG90cy1kYXRhLWNoYW5uZWwtMDQNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcmVkZHktZG90cy1kYXRhLWNoYW5uZWwtMDQNCg0K QWJzdHJhY3Q6DQogICBUaGUgZG9jdW1lbnQgc3BlY2lmaWVzIGEgRGlzdHJpYnV0ZWQgRGVuaWFs LW9mLVNlcnZpY2UgT3BlbiBUaHJlYXQNCiAgIFNpZ25hbGluZyAoRE9UUykgZGF0YSBjaGFubmVs IHVzZWQgZm9yIGJ1bGsgZXhjaGFuZ2Ugb2YgZGF0YSBub3QNCiAgIGVhc2lseSBvciBhcHByb3By aWF0ZWx5IGNvbW11bmljYXRlZCB0aHJvdWdoIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsDQogICB1 bmRlciBhdHRhY2sgY29uZGl0aW9ucy4gIFRoaXMgaXMgYSBjb21wYW5pb24gZG9jdW1lbnQgdG8g dGhlIERPVFMNCiAgIHNpZ25hbCBjaGFubmVsIHNwZWNpZmljYXRpb24uDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Wed Feb 15 21:59:26 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4453B1295B6 for ; Wed, 15 Feb 2017 21:59:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com 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 wPxv-dQK3A4O for ; Wed, 15 Feb 2017 21:59:23 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0090.outbound.protection.outlook.com [104.47.37.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE8F1295B9 for ; Wed, 15 Feb 2017 21:59:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CNR2akco7e0tWVlhaS0Q/4MBtO3Hf7EsxFKaRZFFCDg=; b=Rnuy7oOmGmVXaHhZOSSeOAum56hIoNVe5S39JKZTYWwJOtzU7H+Pz6SAmw8Xw+Sh/ugO7XXVJ/sR/TGb1nd2C2K5qwpNrHb5nw9UsqMg2NKu06hOrdSMOAqCtVFVid3W/gOYbwDp/g/0k8KAKEsLpCuZOSmgv7UurNqzDmQXnGM= Received: from MWHPR0101MB3118.prod.exchangelabs.com (10.174.167.145) by MWHPR0101MB3117.prod.exchangelabs.com (10.174.166.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 16 Feb 2017 05:59:20 +0000 Received: from MWHPR0101MB3118.prod.exchangelabs.com ([10.174.167.145]) by MWHPR0101MB3118.prod.exchangelabs.com ([10.174.167.145]) with mapi id 15.01.0888.030; Thu, 16 Feb 2017 05:59:20 +0000 From: "Mortensen, Andrew" To: "dots@ietf.org" Thread-Topic: [Dots] DDoS Open Threat Signaling (dots) WG Virtual Meeting: 2017-02-22 Thread-Index: AQHSh+hBFX9T+YM4+kiVQP1SWTD/Ew== Date: Thu, 16 Feb 2017 05:59:20 +0000 Message-ID: References: <148720345553.31523.5616766500805936690.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=amortensen@arbor.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [68.49.167.203] x-ms-office365-filtering-correlation-id: aa69a94b-0328-498a-2b4f-08d45630f363 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:MWHPR0101MB3117; x-microsoft-exchange-diagnostics: 1; MWHPR0101MB3117; 7:Yqi9Mc1Ia4Viaf1iklnRuWepu3RvuP2FmQPNTUx3m7WRJGRRWnhjN19jJTys+dW4V7nvVhfWktHUG/6LVsxi6Y9zMZ1aigXFjZijxnE3m4jPaGbiKguwJlGjpMyW+3tgI9v5Vv37bGyTPPa2pZISgCKLjysd0uM2iPuvQsxNCf+5kZGZATb05zExmNfbfarHC0nma9bWAwDkE44g0z5KELA0Q3swgFHRg8HRpDF1UmDjktRQp7khUKel7UNk/uzUuhvMocs2zAeEkhldC9FYJ0a8spYMZ1ZPTsvYDuc42dmvwLn9Gh17KWtBIeh/1mVMvt+oO1HOPYu9v/srgds1Dw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558025)(20161123560025)(6072148); SRVR:MWHPR0101MB3117; BCL:0; PCL:0; RULEID:; SRVR:MWHPR0101MB3117; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(189002)(199003)(377454003)(5423002)(377424004)(50986999)(92566002)(54356999)(2900100001)(8936002)(1730700003)(66066001)(81166006)(3846002)(99286003)(81156014)(2906002)(36756003)(76176999)(6116002)(229853002)(110136004)(86362001)(102836003)(2473003)(38730400002)(53936002)(101416001)(2351001)(6512007)(5660300001)(83716003)(6436002)(3660700001)(25786008)(82746002)(33656002)(106116001)(106356001)(97736004)(54896002)(450100001)(230783001)(122556002)(3280700002)(6916009)(68736007)(5640700003)(2501003)(6486002)(236005)(77096006)(6506006)(189998001)(105586002)(389900002)(7736002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR0101MB3117; H:MWHPR0101MB3118.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E0763144AC3840C4B661F39C1AF0264Carbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2017 05:59:20.4682 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0101MB3117 Archived-At: Subject: [Dots] Fwd: DDoS Open Threat Signaling (dots) WG Virtual Meeting: 2017-02-22 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 16 Feb 2017 05:59:25 -0000 --_000_E0763144AC3840C4B661F39C1AF0264Carbornet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does 15 minutes on RESTCONF seem excessive to anyone else? Begin forwarded message: From: IESG Secretary > Subject: [Dots] DDoS Open Threat Signaling (dots) WG Virtual Meeting: 2017-= 02-22 Date: February 15, 2017 at 7:04:15 PM EST To: "IETF-Announce" > Cc: dots@ietf.org ... - Discussion: Use of RESTCONF (15 min) --_000_E0763144AC3840C4B661F39C1AF0264Carbornet_ Content-Type: text/html; charset="us-ascii" Content-ID: <4122F396DC76864DA4EF6108623D1DCE@prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable Does 15 minutes on RESTCONF seem excessive to anyone else?

Begin forwarded message:

From: IESG Secretary <iesg-secretary@ietf.org>
Subject: [Dots] DDoS Open Threat S= ignaling (dots) WG Virtual Meeting: 2017-02-22
Date: February 15, 2017 at 7:04:15 PM EST
To: "IETF-Announce" <ietf-announce@ietf.org>= ;
Cc: dots@ietf.org

...
  - Discussion: Use of RESTCONF (15 min)

--_000_E0763144AC3840C4B661F39C1AF0264Carbornet_-- From nobody Wed Feb 15 23:52:12 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E251299CE for ; Wed, 15 Feb 2017 23:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 fZqeHXVS-3kC for ; Wed, 15 Feb 2017 23:52:06 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4DD1299C2 for ; Wed, 15 Feb 2017 23:52:05 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 6C4BA25F69F; Thu, 16 Feb 2017 16:52:04 +0900 (JST) Received: from DHCP-190.nttv6.jp (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 40A82759011; Thu, 16 Feb 2017 16:52:04 +0900 (JST) To: "Tirumaleswar Reddy (tireddy)" , Ehud Doron , 'dots' References: <73716c67d08b4de5b8e6df1394da199f@XCH-RCD-017.cisco.com> From: kaname nishizuka Message-ID: Date: Thu, 16 Feb 2017 16:52:03 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <73716c67d08b4de5b8e6df1394da199f@XCH-RCD-017.cisco.com> Content-Type: multipart/alternative; boundary="------------96B4222B695AA87C2CB7F039" Archived-At: Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 16 Feb 2017 07:52:10 -0000 This is a multi-part message in MIME format. --------------96B4222B695AA87C2CB7F039 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Tiru, please see inline. On 2017/02/16 13:18, Tirumaleswar Reddy (tireddy) wrote: > > Hi Kaname, > > Please see inline [TR] for responses > > *From:*kaname nishizuka [mailto:kaname@nttv6.jp] > *Sent:* Wednesday, February 15, 2017 11:27 AM > *To:* Tirumaleswar Reddy (tireddy) ; Ehud Doron ; 'dots' > *Cc:* David Aviv > *Subject:* Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Hi Tiru, > > I really appreciate your time and effort. > Please see my comments on the drafts. > > # draft-reddy-dots-signal-channel-07 > > 1. [General] I believe that DOTS request should not be another tool of blocking other one's traffic. Is there any validation mechanism of requested target-ips, target-ports and target-protocols? Even If it is out side of the DOTS specification, how about returning 4.xx codes when the requested target-* is not a property of the organization. > > [TR] The validation scope is outside the scope of this draft, 4.xx error code is already used in the draft to identity invalid requests. > [kaname]OK, understood. > 2. [page14] Does one DOTS client and DOTS server peer have only one signal channel and one data channel? (I'm thinking about a namespace of the "alias-name") > > [TR] No, DOTS peers can have more than one signal and data channel but the recommendation is to use only signal and data channel to reduce connection setup delay. > [kaname] If there are more than one signal and data channel, how can they coupled? One DOTS server will accommodate more than one DOTS client, so is there any way to know which data channel is belong to which signal channel? Source IP? I recommend to use only one signal and data channel per one DOTS peer, too. > If their are multiple data channels, "DOTS signal" in Fig.5 should specify according data channel when it refers to "alias-names" of the identifiers. > > [TR] I did not get the comment. > [kaname] Different DOTS clients will be belonging to different customers(organizations). So I think there is a chance of requesting the same "alias-names" from different customers. Then, will the DOTS server reject conflicted "alias-names" between different customers? or keep them with prefixes like customerA: and customerB: internally? Also, customerA should not use an alias-name of customerB. How can the DOTS server check that. > 3. [Page21] How about adding status of "mitigation delete is in progress" like status:1. > Here is a life cycle of a mitigation in our environment. Activating and deleting of mitigation could take several seconds (or minutes). > POST. > - activating(status=1) > STATUS AFTER ACTIVATED > - attack mitigated (status=2) > - attack stopped (status=3) > - attack exceeded capability(status=4) > DELETE > - deleting(status=5?) > - deleted(RETURN 4.04) > > [TR] Delete is a confirmable message, DOTS server will send an ACK to acknowledge the receipt of the message to avoid retransmissions from the DOTS client. After the mitigation request is successfully deleted, DOTS server returns 2.02 (Deleted) response code, thus conveying the transient status in this case is not necessary. > [kaname] As I noted, deleting of mitigation could take several seconds (or minutes) in real-life. If the DOTS client retrieve the status while that time, getting "deleting status", not "2.02 status", will help operators. > 4. [Page25] 5.4 b) I couldn't find "retransmission timeout value" attribute in the later figures. Is that equivalent to "ack-timeout"? > > [TR] The initial retransmission timeout value is based on the ack-timeout (see https://tools.ietf.org/html/rfc7252#section-4.2). > [kaname] Thank you, I found the reference. > > 5. [Page27] "policy-id" in "signal-config" is different from "policy-id" in "mitigation-scole". How about using "session-id" in this case? > > [TR] Policy-id is a unique identifier identifying the signal channel session configuration request. > [kaname] "policy-id" in Fig.9 and Fig.15 are totally different. I've got confused when reading the draft because they have the same name. > # draft-reddy-dots-data-channel-03 > > 1. [General] Data channel doesn't have heartbeat mechanism. I guess the reason is that there is heartbeat mechanism in the signal channel so it is enough, is that right? > > [TR] No, the heartbeat mechanism in signal channel cannot be used for data channel. DOTS signal channel is using the “CoAP ping mechanism”. For data channel, TLS heartbeat can be used. I have updated draft. > [kaname] OK. I'll see updated draft. > 2. [related to Ehud's question 8] I-D.ietf-netmod-acl-model says "ACL is an ordered list of Access List Entries (ACE)" but I couldn't find a text about how they are ordered. Should we have a operation of changing the order of ACEs installed in a DOTS server? > > [TR] PUT can be used by the DOTS client to re-order/update/modify the list of ACE conveyed to the DOTS server. Updated draft to discuss about PUT. > [kaname] OK. I'll see updated draft. thank you, kaname > > -Tiru > > > thank you, > Kaname > > On 2017/02/14 23:58, Tirumaleswar Reddy (tireddy) wrote: > > Hi Ehud, > > Please see inline for responses to comments on draft-reddy-dots-data-channel-03 > > *From:* Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Ehud Doron > *Sent:* Wednesday, February 8, 2017 7:21 PM > *To:* 'dots' > *Cc:* David Aviv > *Subject:* [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Tiru and authors Hi > > Attached please find my comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > *_Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel draft-reddy-dots-signal-channel-07_* > > 1.General comment: For all signals in the draft, need to add means to allow vendor specific attributes as part of all signals transactions > > 2.General comment: Just for clarity, need to explicitly mention on each figure when it is an example or the actual API > > 3.Page 3 second paragraph : DOTS should not be limited to “enterprise network” only > > . > > 4.Page 4 chapter 4: The overall context of the “happy eyeballs” and its relations (or coexistence) to CoAP is not clear. > > 5.Page 7 chapter 5.2.1: The need for YANG model cannot be understood from text. What are the needs for YANG models? What is the relation to the JSONs in the other chapters in the draft > > 6.Page 14 figure 5: The mitigation request attributes are right but not enough. Need to add more telemetry info about the actual attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. > > 7.Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested > > 8.Page 15 last paragraph: Not sure that target port or target protocol can define a protected entity. IP, FQDN, URI are the only “stand alone” attributes , port and protocol are companion attributes. See also figure 9 . > > 9.Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is related ? “policy ID” ? I think the best is have another attribute to define the priority of mitigation requests > > 10.Page 21 table: The return status are right but not enough. Need to add more telemetry info about the actual mitigation going on (how much traffic was mitigated) and the attack that are mitigated, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. > > 11.Page 15 : Need to find the way to bind the target-ip*s* with target-port-range*s* and target-protocol*s*, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth. > > 12.Page 21 last paragraph: This is very strong point. > > 13.Page 25 : Regarding attack status, same point about telemetry. > > 14.Page 25 chapter 5.4: I believe it can valuable to add a short high level description about the proposed API flow, same as you did for 5.3 . > > 15.Page 27: The necessity of policy_id here is not clear enough, are the “Signal Channel Session Configuration” define only “single” DOTS session or the entire communication between Client and Server for several DOTS request for mitigation? > > 16.Page 27: Not sure about the reason for “at least one of the attributes heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor MUST be present.” Also consider to change to “presented”. > > 17.Page 30 chapter 5.5: Need to specify the overall scenario, in reaction to which signal (or API transaction POST of Mitigation Request , unidirectional notification from Server as describes in page 23 in page 21 ?) the redirection occurred ? > > *_Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel draft-reddy-dots-data-channel-03_* > > 1.General comment: For all signal in the draft, need to add means to allow vendor specific attributes as part of all signals transactions > > [TR] Agreed, updated draft. > > 2.Page 5 second paragraph: Why it is required to configure the DOTS signal channel session ? > > [TR] No need to configure DOTS signal channel session, fixed second paragraph. > > 3.Page 8 chapter 3.2.1 : Any reason for not including these identifiers in the DOTS signal channel draft ? > > [TR] Identifiers created for resources in DOTS data channel are used in DOTS signal channel to request DDOS mitigation. It’s the responsibility of DOTS data channel to create aliases for resources (see https://tools.ietf.org/html/draft-ietf-dots-requirements-03#section-2.3). The main reason for DOTS signal channel not creating identifiers is the message size may exceed Path MTU. > > 4.Page 9 figure 3 : Need to find the way to bind the target-ip*s* with target-port-range*s* and target-protocol*s*, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth. > > [TR] Yes, it is possible; create different aliases for IP1 TCP port 80 and IP2 UDP port 53. > > 5.Page 13 chapter 3.3 : Need to emphasize that filtering rules are relevant for both client server direct communication and through a DOTS gateway. The chapter is a bit confusing. > > [TR] Thanks, fixed chapter 3.3. > > 6.Page 14 chapter 3.3 : I am missing the white-list installation, is it by using the permit action ? > > [TR] Yes, “permit” action is used for white-list installation; it’s defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 > > 7.Page 15 figure 8: For DDoS it is highly valuable to have rate limit as an action. Consider adding such action (if already defined need to explain where and how). > > [TR] Done, updated draft. > > 8.Page 15 figure 8: Need to consider adding priority to an ACL to support cases when several filtering rules are conflicting. > > [TR] We are not doing anything new to ACL, ACL an ordered list of Access List Entries (ACE) based on priority. > > 9.Page 15 : The action field cannot be optional attribute. > > [TR] As per https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09if the action field not specified then “deny” is the default action. > > 10.Page 16 chapter 3.3.3: Need to add more telemetry info about the actual traffic that was blocked (bps, pps and so on), but as I believe this might be another issue… > > [TR] Chapter 3.3.3 only discusses telemetry details of number of matches for the installed filtering rules. > > -Tiru > > Thanks, > > ** > > *Ehud Doron *| Senior Architect, *Radware* CTO office | *M:*+972-54-7575503 | *T:* +972-72-3917120 > > > > > _______________________________________________ > > 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 --------------96B4222B695AA87C2CB7F039 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Tiru,

please see inline.

On 2017/02/16 13:18, Tirumaleswar Reddy (tireddy) wrote:

Hi Kaname,

 

Please see inline [TR] for responses

 

From: kaname nishizuka [mailto:kaname@nttv6.jp]
Sent: Wednesday, February 15, 2017 11:27 AM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; Ehud Doron <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru,

I really appreciate your time and effort.
Please see my comments on the drafts.

# draft-reddy-dots-signal-channel-07

1. [General] I believe that DOTS request should not be another tool of blocking other one's traffic. Is there any validation mechanism of requested target-ips, target-ports and target-protocols? Even If it is out side of the DOTS specification, how about returning 4.xx codes when the requested target-* is not a property of the organization.

[TR] The validation scope is outside the scope of this draft, 4.xx error code is already used in the draft to identity invalid requests.

[kaname]OK, understood.

2. [page14] Does one DOTS client and DOTS server peer have only one signal channel and one data channel? (I'm thinking about a namespace of the "alias-name")

[TR] No, DOTS peers can have more than one signal and data channel but the recommendation is to use only signal and data channel to reduce connection setup delay.

[kaname] If there are more than one signal and data channel, how can they coupled?
One DOTS server will accommodate more than one DOTS client, so is there any way to know which data channel is belong to which signal channel? Source IP?
I recommend to use only one signal and data channel per one DOTS peer, too.

If their are multiple data channels, "DOTS signal" in Fig.5 should specify according data channel when it refers to "alias-names" of the identifiers.

[TR] I did not get the comment.

[kaname] Different DOTS clients will be belonging to different customers(organizations).
So I think there is a chance of requesting the same "alias-names" from different customers.
Then, will the DOTS server reject conflicted "alias-names" between different customers? or keep them with prefixes like customerA:<same-alias-name> and customerB:<same-alias-name> internally? Also, customerA should not use an alias-name of customerB. How can the DOTS server check that.

3. [Page21] How about adding status of "mitigation delete is in progress" like status:1.
    Here is a life cycle of a mitigation in our environment. Activating and deleting of mitigation could take several seconds (or minutes).
    POST.
     - activating(status=1)
    STATUS AFTER ACTIVATED
     - attack mitigated (status=2)
     - attack stopped (status=3)
     - attack exceeded capability(status=4)
    DELETE
     - deleting(status=5?)
     - deleted(RETURN 4.04)

[TR] Delete is a confirmable message, DOTS server will send an ACK to acknowledge the receipt of the message to avoid retransmissions from the DOTS client. After the mitigation request is successfully deleted, DOTS server returns 2.02 (Deleted) response code, thus conveying the transient status in this case is not necessary.

[kaname] As I noted, deleting of mitigation could take several seconds (or minutes) in real-life.
If the DOTS client retrieve the status while that time, getting "deleting status", not "2.02 status", will help operators.

4. [Page25] 5.4 b) I couldn't find "retransmission timeout value" attribute in the later figures. Is that equivalent to "ack-timeout"?

[TR] The initial retransmission timeout value is based on the ack-timeout (see https://tools.ietf.org/html/rfc7252#section-4.2).

[kaname] Thank you, I found the reference.

5. [Page27] "policy-id" in "signal-config" is different from "policy-id" in "mitigation-scole". How about using "session-id" in this case?

[TR] Policy-id is a unique identifier identifying the signal channel session configuration request.

[kaname] "policy-id" in Fig.9 and Fig.15 are totally different. I've got confused when reading the draft because they have the same name.

# draft-reddy-dots-data-channel-03

1. [General] Data channel doesn't have heartbeat mechanism. I guess the reason is that there is heartbeat mechanism in the signal channel so it is enough, is that right?

[TR] No, the heartbeat mechanism in signal channel cannot be used for data channel. DOTS signal channel is using the “CoAP ping mechanism”. For data channel, TLS heartbeat can be used. I have updated draft.

[kaname] OK. I'll see updated draft.

2. [related to Ehud's question 8] I-D.ietf-netmod-acl-model says "ACL is an ordered list of Access List Entries (ACE)" but I couldn't find a text about how they are ordered. Should we have a operation of changing the order of ACEs installed in a DOTS server?

[TR] PUT can be used by the DOTS client to re-order/update/modify the list of ACE conveyed to the DOTS server. Updated draft to discuss about PUT.

[kaname] OK. I'll see updated draft.


thank you,
kaname

-Tiru


thank you,
Kaname

On 2017/02/14 23:58, Tirumaleswar Reddy (tireddy) wrote:

Hi Ehud,

 

Please see inline for responses to comments on draft-reddy-dots-data-channel-03

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru and authors Hi

 

Attached please find my comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

 

Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy-dots-signal-channel-07

 

1.       General comment: For all signals in the draft, need to add means to allow vendor specific attributes as part of all signals transactions

 

2.       General comment: Just for clarity, need to explicitly mention on each figure when it is an example or the actual API

 

3.       Page 3 second paragraph : DOTS should not be limited to “enterprise network” only

.

4.       Page 4 chapter 4: The overall context of the “happy eyeballs” and its relations (or coexistence) to CoAP is not clear.  

 

5.       Page 7 chapter 5.2.1: The need for YANG model cannot be understood from text. What are the needs for YANG models? What is the relation to the JSONs in the other chapters in the draft

 

6.       Page 14 figure 5: The mitigation request attributes are right but not enough. Need to add more telemetry info about the actual attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG.

 

7.       Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested

 

8.       Page 15 last paragraph: Not sure that target port or target protocol can define a protected entity. IP, FQDN, URI are the only “stand alone” attributes , port and protocol are companion attributes. See also figure 9 .

 

9.       Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is related ?   “policy ID” ? I think the best is have another attribute to define the priority of mitigation requests

 

10.   Page 21 table: The return status are right but not enough. Need to add more telemetry info about the actual mitigation going on (how much traffic was mitigated) and the attack that are mitigated, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG.

 

11.   Page 15 : Need to find the way to bind the target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

12.   Page 21 last paragraph: This is very strong point.

 

13.   Page 25 : Regarding attack status, same point about telemetry.

 

14.   Page 25 chapter 5.4: I believe it can valuable to add a short high level description about the proposed API flow, same as you did for 5.3 .

 

15.   Page 27:  The necessity of policy_id here is not clear enough, are the “Signal Channel Session Configuration” define only “single” DOTS session or the entire communication between Client and Server for several DOTS request for mitigation?

 

16.   Page 27: Not sure about the reason for “at least one of the attributes heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor MUST be present.” Also consider to change to “presented”.

 

17.   Page 30 chapter 5.5: Need to specify the overall scenario, in reaction to which signal (or API transaction POST of Mitigation Request , unidirectional notification from Server as describes in page 23 in page 21 ?) the  redirection occurred ?

 

 

Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-dots-data-channel-03

 

1.       General comment: For all signal in the draft, need to add means to allow vendor specific attributes as part of all signals transactions

 

[TR] Agreed, updated draft.

 

2.       Page 5 second paragraph: Why it is required to configure the DOTS signal channel session ?  

 

[TR] No need to configure DOTS signal channel session, fixed second paragraph.

 

3.       Page 8 chapter 3.2.1 : Any reason for not including these identifiers in the DOTS signal channel draft ?

 

[TR] Identifiers created for resources in DOTS data channel are used in DOTS signal channel to request DDOS mitigation. It’s the responsibility of DOTS data channel to create aliases for resources (see https://tools.ietf.org/html/draft-ietf-dots-requirements-03#section-2.3). The main reason for DOTS signal channel not creating identifiers is the message size may exceed Path MTU.

 

 

4.       Page 9 figure 3 : Need to find the way to bind the target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

[TR] Yes, it is possible; create different aliases for IP1 TCP port 80 and IP2 UDP port 53.

 

 

5.       Page 13 chapter 3.3 : Need to emphasize that filtering rules are relevant for both client server direct communication and through a DOTS gateway. The chapter is a bit confusing.

 

[TR] Thanks, fixed chapter 3.3.

 

 

6.       Page 14 chapter 3.3 : I am missing the white-list installation, is it by using the permit action ?

 

[TR]  Yes, “permit” action is used for white-list installation; it’s defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09

 

 

7.       Page 15 figure 8: For DDoS it is highly valuable to have rate limit as an action. Consider adding such action (if already defined need to explain where and how).

 

[TR] Done, updated draft.

 

8.       Page 15 figure 8: Need to consider adding priority to an ACL to support cases when several filtering rules are conflicting.

 

[TR]  We are not doing anything new to ACL, ACL an ordered list of Access List Entries (ACE) based on priority.

 

 

9.       Page 15 : The action field cannot be optional attribute.

 

[TR] As per https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 if the action field not specified then “deny” is the default action.

 

10.   Page 16 chapter 3.3.3: Need to add more telemetry info about the actual traffic that was blocked (bps, pps and so on), but as I believe this might be another issue…

 

[TR] Chapter 3.3.3 only discusses telemetry details of number of matches for the installed filtering rules.

 

-Tiru

 

Thanks,

 

Ehud Doron |  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

 




_______________________________________________
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

--------------96B4222B695AA87C2CB7F039-- From nobody Thu Feb 16 04:09:21 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7341299E5 for ; Thu, 16 Feb 2017 04:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.512 X-Spam-Level: X-Spam-Status: No, score=-14.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 9iSWzDKRCZWE for ; Thu, 16 Feb 2017 04:09:17 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3201E1294FD for ; Thu, 16 Feb 2017 04:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58253; q=dns/txt; s=iport; t=1487246957; x=1488456557; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LblPs7iqtpv942EVcESdsHQlp4YR9w8q7rJnaR92RKk=; b=AF0F8TCqjSOBq1O6sNUrIREw7vH5lrDdJ/2KhGlw9RSd/DYqkMFg7Wk6 Nvovcv+wdi54dV5Kc2v19UtUEHiBRAYdfZbdb0wbvehWPF6M72htsROnD qnbUsjfJ8eY1xU9zgHm8p5jt/SC7JE6/aQXt/EdP5xzY29ynt5FNqA4Ga A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQDPlaVY/5NdJa1VCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvYmGBCQeNWpIQlTOCCQMfAQqFeAKCHT8YAQIBAQEBAQEBYii?= =?us-ascii?q?EcAEBAQQBARgTQQQHEAIBCBEEAQEhAQIEBycLFAkIAQEEAQ0FCBGJUw6yNSuLE?= =?us-ascii?q?AEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhkyEb4QnBgMBDR0HKIUvBY9EhhSGIwG?= =?us-ascii?q?Gb4Mhh3yCBIUXiXSILYppAR84gQBRFT2ERh0ZgUh1AYd5AQEkB4EDgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208,217";a="207468296" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 12:09:14 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v1GC9EeY006023 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 12:09:14 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.1210.3; Thu, 16 Feb 2017 06:09:13 -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.1210.000; Thu, 16 Feb 2017 06:09:13 -0600 From: "Tirumaleswar Reddy (tireddy)" To: kaname nishizuka , Ehud Doron , "'dots'" Thread-Topic: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . Thread-Index: AdKCER/slEaaT/pbTQCa8ffUgEh/YgEwQ2SQACwcrIAAG9DI0AAafbSAAAQXagA= Date: Thu, 16 Feb 2017 12:09:13 +0000 Message-ID: <0dd8cd77a95f45aabcc64e30ef0bcd06@XCH-RCD-017.cisco.com> References: <73716c67d08b4de5b8e6df1394da199f@XCH-RCD-017.cisco.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.21.15] Content-Type: multipart/alternative; boundary="_000_0dd8cd77a95f45aabcc64e30ef0bcd06XCHRCD017ciscocom_" MIME-Version: 1.0 Archived-At: Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 16 Feb 2017 12:09:20 -0000 --_000_0dd8cd77a95f45aabcc64e30ef0bcd06XCHRCD017ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kaname, Please see inline [TR2] From: kaname nishizuka [mailto:kaname@nttv6.jp] Sent: Thursday, February 16, 2017 1:22 PM To: Tirumaleswar Reddy (tireddy) ; Ehud Doron ; 'dots' Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 . Hi Tiru, please see inline. On 2017/02/16 13:18, Tirumaleswar Reddy (tireddy) wrote: Hi Kaname, Please see inline [TR] for responses From: kaname nishizuka [mailto:kaname@nttv6.jp] Sent: Wednesday, February 15, 2017 11:27 AM To: Tirumaleswar Reddy (tireddy) ; Ehud Doron ; 'dots' Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 . Hi Tiru, I really appreciate your time and effort. Please see my comments on the drafts. # draft-reddy-dots-signal-channel-07 1. [General] I believe that DOTS request should not be another tool of bloc= king other one's traffic. Is there any validation mechanism of requested ta= rget-ips, target-ports and target-protocols? Even If it is out side of the = DOTS specification, how about returning 4.xx codes when the requested targe= t-* is not a property of the organization. [TR] The validation scope is outside the scope of this draft, 4.xx error co= de is already used in the draft to identity invalid requests. [kaname]OK, understood. 2. [page14] Does one DOTS client and DOTS server peer have only one signal = channel and one data channel? (I'm thinking about a namespace of the "alias= -name") [TR] No, DOTS peers can have more than one signal and data channel but the = recommendation is to use only signal and data channel to reduce connection = setup delay. [kaname] If there are more than one signal and data channel, how can they c= oupled? [TR2] DOTS client authenticate to the DOTS server (see https://tools.ietf.o= rg/html/draft-reddy-dots-signal-channel-07#page-35), the DOTS server knows = the DOTS client identity to couple the signal and data channel sessions. One DOTS server will accommodate more than one DOTS client, so is there any= way to know which data channel is belong to which signal channel? Source I= P? I recommend to use only one signal and data channel per one DOTS peer, too. If their are multiple data channels, "DOTS signal" in Fig.5 should specify = according data channel when it refers to "alias-names" of the identifiers. [TR] I did not get the comment. [kaname] Different DOTS clients will be belonging to different customers(or= ganizations). So I think there is a chance of requesting the same "alias-names" from diff= erent customers. Then, will the DOTS server reject conflicted "alias-names" between differen= t customers? [TR] No. or keep them with prefixes like customerA: and customerB:<= same-alias-name> internally? Also, customerA should not use an alias-name o= f customerB. How can the DOTS server check that. [TR2] Same response as above. Aliases do not have global scope, they are sp= ecific to a DOTS client (DOTS server knows the DOTS client identity). 3. [Page21] How about adding status of "mitigation delete is in progress" l= ike status:1. Here is a life cycle of a mitigation in our environment. Activating and= deleting of mitigation could take several seconds (or minutes). POST. - activating(status=3D1) STATUS AFTER ACTIVATED - attack mitigated (status=3D2) - attack stopped (status=3D3) - attack exceeded capability(status=3D4) DELETE - deleting(status=3D5?) - deleted(RETURN 4.04) [TR] Delete is a confirmable message, DOTS server will send an ACK to ackno= wledge the receipt of the message to avoid retransmissions from the DOTS cl= ient. After the mitigation request is successfully deleted, DOTS server ret= urns 2.02 (Deleted) response code, thus conveying the transient status in t= his case is not necessary. [kaname] As I noted, deleting of mitigation could take several seconds (or = minutes) in real-life. [TR2] Yes, but the DOTS server immediately sends a ACK (acknowledging the r= eceipt of the DELETE message), thus the DOTS client knows the server has re= ceived the Delete request and is processing the request. After deleting the= mitigation (may take several seconds), server sends 2.02 (Delete) response= code. I don't see a problem. -Tiru If the DOTS client retrieve the status while that time, getting "deleting s= tatus", not "2.02 status", will help operators. 4. [Page25] 5.4 b) I couldn't find "retransmission timeout value" attribute= in the later figures. Is that equivalent to "ack-timeout"? [TR] The initial retransmission timeout value is based on the ack-timeout (= see https://tools.ietf.org/html/rfc7252#section-4.2). [kaname] Thank you, I found the reference. 5. [Page27] "policy-id" in "signal-config" is different from "policy-id" in= "mitigation-scole". How about using "session-id" in this case? [TR] Policy-id is a unique identifier identifying the signal channel sessio= n configuration request. [kaname] "policy-id" in Fig.9 and Fig.15 are totally different. I've got co= nfused when reading the draft because they have the same name. # draft-reddy-dots-data-channel-03 1. [General] Data channel doesn't have heartbeat mechanism. I guess the rea= son is that there is heartbeat mechanism in the signal channel so it is eno= ugh, is that right? [TR] No, the heartbeat mechanism in signal channel cannot be used for data = channel. DOTS signal channel is using the "CoAP ping mechanism". For data c= hannel, TLS heartbeat can be used. I have updated draft. [kaname] OK. I'll see updated draft. 2. [related to Ehud's question 8] I-D.ietf-netmod-acl-model says "ACL is an= ordered list of Access List Entries (ACE)" but I couldn't find a text abou= t how they are ordered. Should we have a operation of changing the order of= ACEs installed in a DOTS server? [TR] PUT can be used by the DOTS client to re-order/update/modify the list = of ACE conveyed to the DOTS server. Updated draft to discuss about PUT. [kaname] OK. I'll see updated draft. thank you, kaname -Tiru thank you, Kaname On 2017/02/14 23:58, Tirumaleswar Reddy (tireddy) wrote: Hi Ehud, Please see inline for responses to comments on draft-reddy-dots-data-channe= l-03 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron Sent: Wednesday, February 8, 2017 7:21 PM To: 'dots' Cc: David Aviv Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-0= 7 and draft-reddy-dots-data-channel-03 . Tiru and authors Hi Attached please find my comments and feedbacks to draft-reddy-dots-signal-c= hannel-07 and draft-reddy-dots-data-channel-03 . Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel = draft-reddy-dots-signal-channel-07 1. General comment: For all signals in the draft, need to add means t= o allow vendor specific attributes as part of all signals transactions 2. General comment: Just for clarity, need to explicitly mention on e= ach figure when it is an example or the actual API 3. Page 3 second paragraph : DOTS should not be limited to "enterpris= e network" only . 4. Page 4 chapter 4: The overall context of the "happy eyeballs" and = its relations (or coexistence) to CoAP is not clear. 5. Page 7 chapter 5.2.1: The need for YANG model cannot be understood= from text. What are the needs for YANG models? What is the relation to the= JSONs in the other chapters in the draft 6. Page 14 figure 5: The mitigation request attributes are right but = not enough. Need to add more telemetry info about the actual attack that it= is required to mitigate, need to consider attributes in draft-doron-dots-t= elemetry-00 as part of the discussion in the WG. 7. Page 15 Life time attribute: More reasonable to have this attribut= e in minutes rather than seconds, bigger default can also suggested 8. Page 15 last paragraph: Not sure that target port or target protoc= ol can define a protected entity. IP, FQDN, URI are the only "stand alone" = attributes , port and protocol are companion attributes. See also figure 9 = . 9. Page 15 last paragraph: The mitigation request is not clear, to wh= ich identifier the text is related ? "policy ID" ? I think the best is ha= ve another attribute to define the priority of mitigation requests 10. Page 21 table: The return status are right but not enough. Need to ad= d more telemetry info about the actual mitigation going on (how much traffi= c was mitigated) and the attack that are mitigated, need to consider attrib= utes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. 11. Page 15 : Need to find the way to bind the target-ips with target-por= t-ranges and target-protocols, meaning that the server needs to understand = the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on = so forth. 12. Page 21 last paragraph: This is very strong point. 13. Page 25 : Regarding attack status, same point about telemetry. 14. Page 25 chapter 5.4: I believe it can valuable to add a short high le= vel description about the proposed API flow, same as you did for 5.3 . 15. Page 27: The necessity of policy_id here is not clear enough, are th= e "Signal Channel Session Configuration" define only "single" DOTS session = or the entire communication between Client and Server for several DOTS requ= est for mitigation? 16. Page 27: Not sure about the reason for "at least one of the attribute= s heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor = MUST be present." Also consider to change to "presented". 17. Page 30 chapter 5.5: Need to specify the overall scenario, in reactio= n to which signal (or API transaction POST of Mitigation Request , unidirec= tional notification from Server as describes in page 23 in page 21 ?) the = redirection occurred ? Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel dr= aft-reddy-dots-data-channel-03 1. General comment: For all signal in the draft, need to add means to= allow vendor specific attributes as part of all signals transactions [TR] Agreed, updated draft. 2. Page 5 second paragraph: Why it is required to configure the DOTS = signal channel session ? [TR] No need to configure DOTS signal channel session, fixed second paragra= ph. 3. Page 8 chapter 3.2.1 : Any reason for not including these identifi= ers in the DOTS signal channel draft ? [TR] Identifiers created for resources in DOTS data channel are used in DOT= S signal channel to request DDOS mitigation. It's the responsibility of DOT= S data channel to create aliases for resources (see https://tools.ietf.org/= html/draft-ietf-dots-requirements-03#section-2.3). The main reason for DOTS= signal channel not creating identifiers is the message size may exceed Pat= h MTU. 4. Page 9 figure 3 : Need to find the way to bind the target-ips with= target-port-ranges and target-protocols, meaning that the server needs to = understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53= and so on so forth. [TR] Yes, it is possible; create different aliases for IP1 TCP port 80 and = IP2 UDP port 53. 5. Page 13 chapter 3.3 : Need to emphasize that filtering rules are r= elevant for both client server direct communication and through a DOTS gate= way. The chapter is a bit confusing. [TR] Thanks, fixed chapter 3.3. 6. Page 14 chapter 3.3 : I am missing the white-list installation, is= it by using the permit action ? [TR] Yes, "permit" action is used for white-list installation; it's define= d in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 7. Page 15 figure 8: For DDoS it is highly valuable to have rate limi= t as an action. Consider adding such action (if already defined need to exp= lain where and how). [TR] Done, updated draft. 8. Page 15 figure 8: Need to consider adding priority to an ACL to su= pport cases when several filtering rules are conflicting. [TR] We are not doing anything new to ACL, ACL an ordered list of Access L= ist Entries (ACE) based on priority. 9. Page 15 : The action field cannot be optional attribute. [TR] As per https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 if t= he action field not specified then "deny" is the default action. 10. Page 16 chapter 3.3.3: Need to add more telemetry info about the actu= al traffic that was blocked (bps, pps and so on), but as I believe this mig= ht be another issue... [TR] Chapter 3.3.3 only discusses telemetry details of number of matches fo= r the installed filtering rules. -Tiru Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 _______________________________________________ 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_0dd8cd77a95f45aabcc64e30ef0bcd06XCHRCD017ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kaname,<= /span>

 

Please see inline [TR2= ]

 

From:= kaname nishizuka [mailto:kaname@nttv6.jp]
Sent: Thursday, February 16, 2017 1:22 PM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; Ehud Dor= on <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signa= l-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru,

please see inline.

On 2017/02/16 13:18, Tirumaleswar Reddy (tireddy) wr= ote:

Hi Kaname,=

 

Please see inline [TR]= for responses

 

From:= kaname nishizuka [mailto:kaname@nttv6.jp]
Sent: Wednesday, February 15, 2017 11:27 AM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; Ehud Doron <EhudD@Radware.com>; 'dots' = <dots@ietf.org>
Cc: David Aviv <DavidA@Radw= are.com>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signa= l-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru,

I really appreciate your time and effort.
Please see my comments on the drafts.

# draft-reddy-dots-signal-channel-07

1. [General] I believe that DOTS request should not be another tool of bloc= king other one's traffic. Is there any validation mechanism of requested ta= rget-ips, target-ports and target-protocols? Even If it is out side of the = DOTS specification, how about returning 4.xx codes when the requested target-* is not a property of the organizati= on.

[TR] The validation scope is outside the scope of this draft, 4.xx= error code is already used in the draft to identity invalid requests.

[kaname]OK, understood.


2. [page14] Does one = DOTS client and DOTS server peer have only one signal channel and one data = channel? (I'm thinking about a namespace of the "alias-name")

[TR] No, DOTS peers can have more than one signal and data channel= but the recommendation is to use only signal and data channel to reduce co= nnection setup delay.

[kaname] If there are more than one signal and d= ata channel, how can they coupled?

 

[TR2] DOTS client auth= enticate to the DOTS server (see https://tools.ietf.org/html/draft-reddy-do= ts-signal-channel-07#page-35), the DOTS server knows the DOTS client identi= ty to couple the signal and data channel sessions.


One DOTS server will accommodate more than one DOTS client, so is there any= way to know which data channel is belong to which signal channel? Source I= P?
I recommend to use only one signal and data channel per one DOTS peer, too.=

 

 

If their are multiple= data channels, "DOTS signal" in Fig.5 should specify according d= ata channel when it refers to "alias-names" of the identifiers.

[TR] I did not get the comment.

[kaname] Different DOTS clients will be belongin= g to different customers(organizations).
So I think there is a chance of requesting the same "alias-names"= from different customers.
Then, will the DOTS server reject conflicted "alias-names" betwee= n different customers?

 

[TR] No.

 

or keep them with prefixes like customerA:<sa= me-alias-name> and customerB:<same-alias-name> internally? Also, c= ustomerA should not use an alias-name of customerB. How can the DOTS server check that.

 

[TR2] Same response as= above. Aliases do not have global scope, they are specific to a DOTS clien= t (DOTS server knows the DOTS client identity).


3. [Page21] How about adding status of "mitigation delete is in= progress" like status:1.
    Here is a life cycle of a mitigation in our environment.= Activating and deleting of mitigation could take several seconds (or minut= es).
    POST.
     - activating(status=3D1)
    STATUS AFTER ACTIVATED
     - attack mitigated (status=3D2)
     - attack stopped (status=3D3)
     - attack exceeded capability(status=3D4)
    DELETE
     - deleting(status=3D5?)
     - deleted(RETURN 4.04)


[TR] Delete is a confirmable message, DOTS server will send an ACK= to acknowledge the receipt of the message to avoid retransmissions from th= e DOTS client. After the mitigation request is successfully deleted, DOTS server returns 2.02 (Deleted) response code,= thus conveying the transient status in this case is not necessary.<= o:p>

[kaname] As I noted, deleting of mitigation coul= d take several seconds (or minutes) in real-life.<= o:p>

 

[TR2] Yes, but the DOT= S server immediately sends a ACK (acknowledging the receipt of the DELETE m= essage), thus the DOTS client knows the server has received the Delete requ= est and is processing the request. After deleting the mitigation (may take several seconds), server sends 2.02 (Del= ete) response code. I don’t see a problem.

 

-Tiru


If the DOTS client retrieve the status while that time, getting "delet= ing status", not "2.02 status", will help operators.

4. [Page25] 5.4 b) I = couldn't find "retransmission timeout value" attribute in the lat= er figures. Is that equivalent to "ack-timeout"?

[TR] The initial retransmission timeout value is based on the ack-= timeout (see https://tools.i= etf.org/html/rfc7252#section-4.2).

[kaname] Thank you, I found the reference.

5. [Page27] "pol= icy-id" in "signal-config" is different from "policy-id= " in "mitigation-scole". How about using "session-id&qu= ot; in this case?

[TR] Policy-id is a unique identifier identifying the signal chann= el session configuration request.

[kaname] "policy-id" in Fig.9 and Fig.= 15 are totally different. I've got confused when reading the draft because = they have the same name.

 

# draft-reddy-dots-da= ta-channel-03

1. [General] Data channel doesn't have heartbeat mechanism. I guess the rea= son is that there is heartbeat mechanism in the signal channel so it is eno= ugh, is that right?

[TR] No, the heartbeat mechanism in signal channel cannot be used = for data channel. DOTS signal channel is using the “CoAP ping mechani= sm”. For data channel, TLS heartbeat can be used. I have updated draft.

[kaname] OK. I'll see updated draft.


2. [related to Ehud's= question 8] I-D.ietf-netmod-acl-model says "ACL is an ordered list of= Access List Entries (ACE)" but I couldn't find a text about how they = are ordered. Should we have a operation of changing the order of ACEs installed in a DOTS server?

[TR] PUT can be used by the DOTS client to re-order/update/modify = the list of ACE conveyed to the DOTS server. Updated draft to discuss about= PUT.

[kaname] OK. I'll see updated draft.


thank you,
kaname

-Tiru


thank you,
Kaname

On 2017/02/14 23:58, Tirumaleswar Reddy (tireddy) wr= ote:

Hi Ehud,

 

Please see inline for = responses to comments on draft-reddy-dots-data-channel-03=

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radw= are.com>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-ch= annel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru and authors Hi

 

Attached please find m= y comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-re= ddy-dots-data-channel-03 .

 

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy= -dots-signal-channel-07

 

1.     &= nbsp; General comment: For all signals in the draft, need= to add means to allow vendor specific attributes as part of all signals tr= ansactions

 

2.     &= nbsp; General comment: Just for clarity, need to explicit= ly mention on each figure when it is an example or the actual API

 

3.     &= nbsp; Page 3 second paragraph : DOTS should not be limite= d to “enterprise network” only

.

4.     &= nbsp; Page 4 chapter 4: The overall context of the “= ;happy eyeballs” and its relations (or coexistence) to CoAP is not cl= ear.  

 

5.     &= nbsp; Page 7 chapter 5.2.1: The need for YANG model canno= t be understood from text. What are the needs for YANG models? What is the = relation to the JSONs in the other chapters in the draft

 

6.     &= nbsp; Page 14 figure 5: The mitigation request attributes= are right but not enough. Need to add more telemetry info about the actual= attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

7.     &= nbsp; Page 15 Life time attribute: More reasonable to have this attribute in minutes rather tha= n seconds, bigger default can also suggested

 

8.     &= nbsp; Page 15 last paragraph: Not sure that target port or target protocol can define a protect= ed entity. IP, FQDN, URI are the only “stand alone” attributes = , port and protocol are companion attributes. See also figure 9 .

 

9.     &= nbsp; Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is relate= d ?   “policy ID” ? I think the best is have another = attribute to define the priority of mitigation requests

 

10.   Page 21 table: The return status are right but not = enough. Need to add more telemetry info about the actual mitigation going o= n (how much traffic was mitigated) and the attack that are mitigated, need = to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

11.   Page 15 : Need to find the way to bind the target-i= ps with target-port-ranges and target-protocols, meani= ng that the server needs to understand the exact scope of attack, e.g. IP1 = TCP port 80, IP2 UDP port 53 and so on so forth.

 

12.   Page 21 last paragraph: This is very strong point.<= o:p>

 

13.   Page 25 : Regarding attack status, same point about= telemetry.

 

14.   Page 25 chapter 5.4: I believe it can valuable to a= dd a short high level description about the proposed API flow, same as you = did for 5.3 .

 

15.   Page 27:  The necessity of policy_id here is n= ot clear enough, are the “Signal Channel Session Configuration”= define only “single” DOTS session or the entire communication = between Client and Server for several DOTS request for mitigation?

 

16.   Page 27: Not sure about the reason for “at le= ast one of the attributes heartbeat-interval or max-retransmit or ack-timeo= ut or ack-random-factor MUST be present.” Also consider to change to = “presented”.

 

17.   Page 30 chapter 5.5: Need to specify the overall sc= enario, in reaction to which signal (or API transaction POST of Mitigation = Request , unidirectional notification from Server as describes in page 23 i= n page 21 ?) the  redirection occurred ?

 

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-d= ots-data-channel-03

 

1.     &= nbsp; General comment: For all signal in the draft, need = to add means to allow vendor specific attributes as part of all signals tra= nsactions

 

[TR] Agreed, updated draft.

 

2.     &= nbsp; Page 5 second paragraph: Why it is required to conf= igure the DOTS signal channel session ?  

 

[TR] No need to config= ure DOTS signal channel session, fixed second paragraph.<= /p>

 

3.     &= nbsp; Page 8 chapter 3.2.1 : Any reason for not including= these identifiers in the DOTS signal channel draft ?

 

[TR] Identifiers creat= ed for resources in DOTS data channel are used in DOTS signal channel to re= quest DDOS mitigation. It’s the responsibility of DOTS data channel t= o create aliases for resources (see https://tools.ietf.org/html/draft-ietf-dots-requirements-03= #section-2.3). The main reason for DOTS s= ignal channel not creating identifiers is the message size may exceed Path MTU.

 

 

4.     &= nbsp; Page 9 figure 3 : Need to find the way to bind the = target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e= .g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

[TR] Yes, it is possib= le; create different aliases for IP1 TCP port 80 and IP2 UDP port 53.

 

 

5.     &= nbsp; Page 13 chapter 3.3 : Need to emphasize that filter= ing rules are relevant for both client server direct communication and thro= ugh a DOTS gateway. The chapter is a bit confusing.

 

[TR] Thanks, fixed cha= pter 3.3.

 

 

6.     &= nbsp; Page 14 chapter 3.3 : I am missing the white-list i= nstallation, is it by using the permit action ?

 

[TR]  Yes, “= ;permit” action is used for white-list installation; it’s defin= ed in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09

 

 

7.     &= nbsp; Page 15 figure 8: For DDoS it is highly valuable to= have rate limit as an action. Consider adding such action (if already defi= ned need to explain where and how).

 

[TR] Done, updated draft.

 

8.     &= nbsp; Page 15 figure 8: Need to consider adding priority = to an ACL to support cases when several filtering rules are conflicting.

 

[TR]  We are not = doing anything new to ACL, ACL an ordered list of Access List Entries (ACE)= based on priority.

 

 

9.     &= nbsp; Page 15 : The action field cannot be optional attri= bute.

 

[TR] As per https:/= /tools.ietf.org/html/draft-ietf-netmod-acl-model-09 if the action field not specified then “deny” is the default action.

 

10.   Page 16 chapter 3.3.3: Need to add more telemetry i= nfo about the actual traffic that was blocked (bps, pps and so on), but as = I believe this might be another issue…

 

[TR] Chapter 3.3.3 onl= y discusses telemetry details of number of matches for the installed filter= ing rules.

 

-Tiru

 

Thanks,

 

Ehud Doron |=  Senior Architect, Radware CTO office | M:<= span style=3D"font-size:10.0pt;font-family:"Tahoma",sans-serif;co= lor:#999999"> +972-54-7575503 | T: +972-72-3917120

 

 

 

 





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

 




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

 

--_000_0dd8cd77a95f45aabcc64e30ef0bcd06XCHRCD017ciscocom_-- From nobody Thu Feb 16 05:12:59 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00AF129465 for ; Thu, 16 Feb 2017 05:12:58 -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_PASS=-0.001] autolearn=ham autolearn_force=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 Eww5cph2o40o for ; Thu, 16 Feb 2017 05:12:56 -0800 (PST) Received: from mailout1.radware.com (mailout1.radwarecloud.com [192.115.180.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDBF4129440 for ; Thu, 16 Feb 2017 05:12:54 -0800 (PST) Received: from ILMB1.corp.radware.com ([169.254.1.237]) by ILCAS2.corp.radware.com ([176.200.120.122]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 15:12:51 +0200 From: Ehud Doron To: "Tirumaleswar Reddy (tireddy)" , 'dots' Thread-Topic: Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . Thread-Index: AdKCER/slEaaT/pbTQCa8ffUgEh/YgEvK4mgADZ1NNA= Date: Thu, 16 Feb 2017 13:12:50 +0000 Message-ID: References: <331a77a5ec074db69cf2bc2715a7645e@XCH-RCD-017.cisco.com> In-Reply-To: <331a77a5ec074db69cf2bc2715a7645e@XCH-RCD-017.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [176.200.121.207] x-tm-as-product-ver: SMEX-11.0.0.4179-8.100.1062-22888.006 x-tm-as-result: No--11.143300-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E58182C4A35A8E498E553AD3D33FA001011718BF03ILMB1corpradw_" MIME-Version: 1.0 Archived-At: Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 16 Feb 2017 13:12:58 -0000 --_000_E58182C4A35A8E498E553AD3D33FA001011718BF03ILMB1corpradw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tiru Hi Thanks for your response and clarifications. Please see inline (Followed after [Ehud] ) Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Tuesday, February 14, 2017 4:53 PM To: Ehud Doron ; 'dots' Cc: David Aviv Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 a= nd draft-reddy-dots-data-channel-03 . Hi Ehud, Thanks for the detailed review, Please see inline (I will respond to data c= hannel comments in a separate mail) From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron Sent: Wednesday, February 8, 2017 7:21 PM To: 'dots' > Cc: David Aviv > Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-0= 7 and draft-reddy-dots-data-channel-03 . Tiru and authors Hi Attached please find my comments and feedbacks to draft-reddy-dots-signal-c= hannel-07 and draft-reddy-dots-data-channel-03 . Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel = draft-reddy-dots-signal-channel-07 1. General comment: For all signals in the draft, need to add means t= o allow vendor specific attributes as part of all signals transactions [TR] Yes, will update draft. 2. General comment: Just for clarity, need to explicitly mention on e= ach figure when it is an example or the actual API [TR] Done. 3. Page 3 second paragraph : DOTS should not be limited to "enterpris= e network" only [TR] Agreed, fixed. 4. Page 4 chapter 4: The overall context of the "happy eyeballs" and = its relations (or coexistence) to CoAP is not clear. [TR] Happy eyeballs mechanism is used to reduce connection delay to setup (= D)TLS session with the DOTS server. Happy eyeballs mechanism is not related= to CoAP. 5. Page 7 chapter 5.2.1: The need for YANG model cannot be understood= from text. What are the needs for YANG models? What is the relation to the= JSONs in the other chapters in the draft [TR] YANG is a data modeling language used to model configuration and state= data; The configuration and state data defined using YANG can be represen= ted in JSON or CBOR or XML. Since CBOR is binary, JSON is used in the draft= but only for illustrative purpose. 6. Page 14 figure 5: The mitigation request attributes are right but = not enough. Need to add more telemetry info about the actual attack that it= is required to mitigate, need to consider attributes in draft-doron-dots-t= elemetry-00 as part of the discussion in the WG. [TR] Yes, I plan to update the draft with telemetry info based on outcome o= f draft-doron-dots-telemetry-00. 7. Page 15 Life time attribute: More reasonable to have this attribut= e in minutes rather than seconds, bigger default can also suggested [TR] Changed to minutes 8. Page 15 last paragraph: Not sure that target port or target protoc= ol can define a protected entity. IP, FQDN, URI are the only "stand alone" = attributes , port and protocol are companion attributes. See also figure 9 = . [TR] Good point, fixed. 9. Page 15 last paragraph: The mitigation request is not clear, to wh= ich identifier the text is related ? "policy ID" ? I think the best is ha= ve another attribute to define the priority of mitigation requests [TR] policy-id is specific to a DOTS client, DOTS server need not compare t= he policy-id of one customer with the policy-id of another customer. Policy= -ids are only compared b/w multiple mitigation requests from the same DOTS = client to determine the priority. DOTS signaling channel runs over UDP, and= packets may arrive out-of-order; this was also one of the reasons to intro= duce policy-id. [Ehud] Consider to update the text in page 15 with your explanations here, = mainly regarding the "per customer uniqueness of DOTS". 10. Page 21 table: The return status are right but not enough. Need to ad= d more telemetry info about the actual mitigation going on (how much traffi= c was mitigated) and the attack that are mitigated, need to consider attrib= utes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. [TR] Same response as 6; for now will update the draft to convey the follow= ing telemetry info from the DOTS server : total dropped byte count, average= dropped bytes per second, total dropped packet count and average dropped p= ackets per second. The list is not complete, what kind of telemetry info is= required for L7 attacks (e.g. attack at TLS, partial HTTP request, garbage= request etc.) and how do we deal with new type of DDOS attacks (Do we keep= updating the spec as and when a new DDOS attack is discovered) ? [Ehud] Agreed with the bytes / packets count drop you proposed. For the Lay= er 7 telemetries and for DDoS attacks list , I think we should first get to= an agreement about the needs for this attributes and then figure out the b= est way to signal this information. Personally I don't believe we should up= date the spec for each attack, therefor we need to figure out an efficient = means to signal this information. 11. Page 15 : Need to find the way to bind the target-ips with target-por= t-ranges and target-protocols, meaning that the server needs to understand = the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on = so forth. [TR] Yes, it's possible; create different aliases for IP1 TCP port 80 and I= P 2 UDP port 53 using DOTS data channel and convey the aliases in DOTS sign= al channel. 12. Page 21 last paragraph: This is very strong point. [TR] Thanks. 13. Page 25 : Regarding attack status, same point about telemetry. [TR] Same response as above. 14. Page 25 chapter 5.4: I believe it can valuable to add a short high le= vel description about the proposed API flow, same as you did for 5.3 . [TR] 5.3 gives background how GET, POST, DELETE and PUT will be used, hence= did not see a need to add a high level description in Section 5.4. 15. Page 27: The necessity of policy_id here is not clear enough, are th= e "Signal Channel Session Configuration" define only "single" DOTS session = or the entire communication between Client and Server for several DOTS requ= est for mitigation? [TR] It's for a single DOTS session between DOTS client and server, a sing= le DOTS session can be used for several DOTS requests and responses. 16. Page 27: Not sure about the reason for "at least one of the attribute= s heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor = MUST be present." Also consider to change to "presented". [TR] what is the point in conveying a POST request without any configuratio= n parameters/attributes ? [Ehud] OK, understood. So I think you need to emphasize that in cases not a= ll attributes are defined, need to use default values. In page 26 you wrote= something about "need not be default". Consider to re-write. 17. Page 30 chapter 5.5: Need to specify the overall scenario, in reactio= n to which signal (or API transaction POST of Mitigation Request , unidirec= tional notification from Server as describes in page 23 in page 21 ?) the = redirection occurred ? [TR] Both, updated draft. -Tiru Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel dr= aft-reddy-dots-data-channel-03 1. General comment: For all signal in the draft, need to add means to= allow vendor specific attributes as part of all signals transactions 2. Page 5 second paragraph: Why it is required to configure the DOTS = signal channel session ? 3. Page 8 chapter 3.2.1 : Any reason for not including these identifi= ers in the DOTS signal channel draft ? 4. Page 9 figure 3 : Need to find the way to bind the target-ips with= target-port-ranges and target-protocols, meaning that the server needs to = understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53= and so on so forth. 5. Page 13 chapter 3.3 : Need to emphasize that filtering rules are r= elevant for both client server direct communication and through a DOTS gate= way. The chapter is a bit confusing. 6. Page 14 chapter 3.3 : I am missing the white-list installation, is= it by using the permit action ? 7. Page 15 figure 8: For DDoS it is highly valuable to have rate limi= t as an action. Consider adding such action (if already defined need to exp= lain where and how). 8. Page 15 figure 8: Need to consider adding priority to an ACL to su= pport cases when several filtering rules are conflicting. 9. Page 15 : The action field cannot be optional attribute. 10. Page 16 chapter 3.3.3: Need to add more telemetry info about the actu= al traffic that was blocked (bps, pps and so on), but as I believe this mig= ht be another issue... Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 --_000_E58182C4A35A8E498E553AD3D33FA001011718BF03ILMB1corpradw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tiru Hi

 

Thanks for your respon= se and clarifications.

Please see inline (Fol= lowed after [Ehud] )

 

Thanks,

 

Ehud Doron |=  Senior Architect, Radware CTO office | M:<= span style=3D"font-size:10.0pt;font-family:"Tahoma",sans-serif;co= lor:#999999"> +972-54-7575503 | T: +972-72-3917120

 

 

 

From: Tirumaleswar Reddy (tireddy) [mailto:ti= reddy@cisco.com]
Sent: Tuesday, February 14, 2017 4:53 PM
To: Ehud Doron <EhudD@Radware.com>; 'dots' <dots@ietf.org&g= t;
Cc: David Aviv <DavidA@Radware.com>
Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 .

 

Hi Ehud,

 

Thanks for the detaile= d review, Please see inline (I will respond to data channel comments in a s= eparate mail)

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <dots@ietf.org>= ;
Cc: David Aviv <DavidA@Radw= are.com>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-ch= annel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru and authors Hi

 

Attached please find m= y comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-re= ddy-dots-data-channel-03 .

 

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy= -dots-signal-channel-07

 

1.     &= nbsp; General comment: For all s= ignals in the draft, need to add means to allow vendor specific attributes = as part of all signals transactions

 

[TR] Yes, will update draft.

 

2.&n= bsp;      General comment: Ju= st for clarity, need to explicitly mention on each figure when it is an exa= mple or the actual API

 

[TR] Done.

 

3.     &= nbsp; Page 3 second paragraph : = DOTS should not be limited to “enterprise network” only

 

[TR] Agreed, fixed.

 

4.     &= nbsp; Page 4 chapter 4: The over= all context of the “happy eyeballs” and its relations (or coexi= stence) to CoAP is not clear.  

 

[TR] Happy eyeballs me= chanism is used to reduce connection delay to setup (D)TLS session with the= DOTS server. Happy eyeballs mechanism is not related to CoAP.<= /o:p>

 

5.     &= nbsp; Page 7 chapter 5.2.1: The = need for YANG model cannot be understood from text. What are the needs for = YANG models? What is the relation to the JSONs in the other chapters in the= draft

 

[TR] YANG is a data mo= deling language used to model configuration and state data;  The confi= guration and state data defined using YANG can be represented in JSON or CB= OR or XML. Since CBOR is binary, JSON is used in the draft but only for illustrative purpose.

 

6.     &= nbsp; Page 14 figure 5: The miti= gation request attributes are right but not enough. Need to add more teleme= try info about the actual attack that it is required to mitigate, need to c= onsider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

[TR] Yes, I plan to up= date the draft with telemetry info based on outcome of draft-doron-dots-tel= emetry-00.

 

7.     &= nbsp; Page 15 Life time attribut= e: More reasonable to have this attrib= ute in minutes rather than seconds, bigger default can also suggested

 

[TR] Changed to minute= s

 

8.     &= nbsp; Page 15 last paragraph: Not sure that target port or target prot= ocol can define a protected entity. IP, FQDN, URI are the only “stand= alone” attributes , port and protocol are companion attributes. See also figure 9 .

 

[TR] Good point, fixed= .

 

9.     &= nbsp; Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is= related ?   “policy ID” ? I think the best is have a= nother attribute to define the priority of mitigation requests

[TR] policy-id is spec= ific to a DOTS client, DOTS server need not compare the policy-id of one cu= stomer with the policy-id of another customer. Policy-ids are only compared= b/w multiple mitigation requests from the same DOTS client to determine the priority. DOTS signaling channel run= s over UDP, and packets may arrive out-of-order; this was also one of the r= easons to introduce policy-id.

[Ehud] Consider to upd= ate the text in page 15 with your explanations here, mainly regarding the &= #8220;per customer uniqueness of DOTS”.

 

10.&= nbsp;  Page 21 table: The = return status are right but not enough. Need to add more telemetry info abo= ut the actual mitigation going on (how much traffic was mitigated) and the = attack that are mitigated, need to consider attributes in draft-doron-dots-tele= metry-00 as part of the discussion in the WG.

 

[TR] Same response as 6; for now will update the draft to convey the following telemetry info fro= m the DOTS server : total dropped byte count, average dropped byt= es per second, total dropped packet count and average dropped packets per s= econd. The list is not complete, what kind of telemetry info is required fo= r L7 attacks (e.g. attack at TLS, partial HTTP request, garbage request etc.) and how do we deal with new ty= pe of DDOS attacks (Do we keep updating the spec as and when a new DDOS att= ack is discovered) ?

[Ehud] Agreed with the= bytes / packets count drop you proposed. For the Layer 7 telemetries and f= or DDoS attacks list , I think we should first get to an agreement about th= e needs for this attributes and then figure out the best way to signal this information. Personally I don’= ;t believe we should update the spec for each attack, therefor we need to f= igure out an efficient means to signal this information.  <= /span>

 

11.   Page 15 : Need to find the= way to bind the target-ips with target-port-ranges and targe= t-protocols, meaning that the server needs to understand the exact s= cope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

[TR] Yes, it’s p= ossible; create different aliases for IP1 TCP port 80 and IP 2 UDP port 53 = using DOTS data channel and convey the aliases in DOTS signal channel.=

 

12.   Page 21 last paragraph: Th= is is very strong point.

 

[TR] Thanks.

 

13.   Page 25 : Regarding attack= status, same point about telemetry.

 

[TR] Same response as above.

 

14.   Page 25 chapter 5.4: I bel= ieve it can valuable to add a short high level description about the propos= ed API flow, same as you did for 5.3 .

 

[TR] 5.3 gives backgro= und how GET, POST, DELETE and PUT will be used, hence did not see a need to= add a high level description in Section 5.4.

 

 

15.   Page 27:  The necessi= ty of policy_id here is not clear enough, are the “Signal Channel Ses= sion Configuration” define only “single” DOTS session or = the entire communication between Client and Server for several DOTS request for mitigation?

 

[TR]  It’s = for a single DOTS session between DOTS client and server, a single DOTS ses= sion can be used for several DOTS requests and responses.=

 

16.   Page 27: Not sure about th= e reason for “at least one of the attributes heartbeat-interval or ma= x-retransmit or ack-timeout or ack-random-factor MUST be present.” Al= so consider to change to “presented”.

 

[TR] what is the point in conveying a POST request with=
out any configuration parameters/attributes ?
[Ehud] OK, understood. So I think you need to emphasize=
 that in cases not all attributes are defined, need to use default values. =
In page 26 you wrote something about “need not be default”. Con=
sider to re-write. 
 

 

 

17.   Page 30 chapter 5.5: Need = to specify the overall scenario, in reaction to which signal (or API transa= ction POST of Mitigation Request , unidirectional notification from Server = as describes in page 23 in page 21 ?) the  redirection occurred ?

 

[TR] Both, updated dra= ft.

 

-Tiru

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-d= ots-data-channel-03

 

1.     &= nbsp; General comment: For all s= ignal in the draft, need to add means to allow vendor specific attributes a= s part of all signals transactions

 

2.     &= nbsp; Page 5 second paragraph: W= hy it is required to configure the DOTS signal channel session ?  

 

3.     &= nbsp; Page 8 chapter 3.2.1 : Any= reason for not including these identifiers in the DOTS signal channel draf= t ?

 

4.     &= nbsp; Page 9 figure 3 : Need to = find the way to bind the target-ips with target-port-ranges a= nd target-protocols, meaning that the server needs to understand the= exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

5.     &= nbsp; Page 13 chapter 3.3 : Need= to emphasize that filtering rules are relevant for both client server dire= ct communication and through a DOTS gateway. The chapter is a bit confusing= .

 

6.     &= nbsp; Page 14 chapter 3.3 : I am= missing the white-list installation, is it by using the permit action ?

 

7.     &= nbsp; Page 15 figure 8: For DDoS= it is highly valuable to have rate limit as an action. Consider adding suc= h action (if already defined need to explain where and how).

 

8.     &= nbsp; Page 15 figure 8: Need to = consider adding priority to an ACL to support cases when several filtering = rules are conflicting.

 

9.     &= nbsp; Page 15 : The action field= cannot be optional attribute.

 

10.   Page 16 chapter 3.3.3: Nee= d to add more telemetry info about the actual traffic that was blocked (bps= , pps and so on), but as I believe this might be another issue…

 

 

 

Thanks,

 

Ehud Doron |=  Senior Architect, Radware CTO office | M:<= span style=3D"font-size:10.0pt;font-family:"Tahoma",sans-serif;co= lor:#999999"> +972-54-7575503 | T: +972-72-3917120

 

 

 

 

--_000_E58182C4A35A8E498E553AD3D33FA001011718BF03ILMB1corpradw_-- From nobody Thu Feb 16 06:09:46 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351FD1295E4 for ; Thu, 16 Feb 2017 06:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.022 X-Spam-Level: X-Spam-Status: No, score=-14.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ExfTH5TENnCq for ; Thu, 16 Feb 2017 06:09:44 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513821294AD for ; Thu, 16 Feb 2017 06:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45369; q=dns/txt; s=iport; t=1487253660; x=1488463260; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qREvTCJcxNsOpwNiOPUDUMBG8dRDmRcLmyYrKLOEgOI=; b=DMRqrcQTXGjftypq+N1LbuLaJyl48ePdtLKtS6sA/s4VgQncCMb7BVMp 1AYQvIAXxcP6rT4jBqb+pMBnmsX1t3gMmduUeNMeM+85XrbwUX9znDXEK p9AUBdiJvYrLVtjUmUImeeoC3o82vMSR9DF2dWSvGhG9MrcpkShWmzOJY 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQBKr6VY/5FdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYYEJB41akhCVM4IMhiICggY/GAECAQEBAQEBAWIohHABAQE?= =?us-ascii?q?ELUUHEAIBCBEEAQEhAQIEBzIUCQgBAQQBDQUIEYlTsmWLPAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2GTIRvhDABBgEBBR0HHgoChS0FlVyGIwGKEId9ggSFF4l0iC2?= =?us-ascii?q?KagEfOIEAURU9hEMDHRmBSHWHegEOF4EKgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208,217";a="386460807" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 14:00:58 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v1GE0tEu015369 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 14:00:55 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.1210.3; Thu, 16 Feb 2017 08:00:54 -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.1210.000; Thu, 16 Feb 2017 08:00:54 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Ehud Doron , "'dots'" Thread-Topic: Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . Thread-Index: AdKCER/slEaaT/pbTQCa8ffUgEh/YgEvK4mgADZ1NNAALTMmUA== Date: Thu, 16 Feb 2017 14:00:54 +0000 Message-ID: <3bab57f083c346cfb491c29c7ff369dd@XCH-RCD-017.cisco.com> References: <331a77a5ec074db69cf2bc2715a7645e@XCH-RCD-017.cisco.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.65.38.50] Content-Type: multipart/alternative; boundary="_000_3bab57f083c346cfb491c29c7ff369ddXCHRCD017ciscocom_" MIME-Version: 1.0 Archived-At: Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 16 Feb 2017 14:09:46 -0000 --_000_3bab57f083c346cfb491c29c7ff369ddXCHRCD017ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ehud, Please see inline [TR2] From: Ehud Doron [mailto:EhudD@Radware.com] Sent: Thursday, February 16, 2017 6:43 PM To: Tirumaleswar Reddy (tireddy) ; 'dots' Cc: David Aviv Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 a= nd draft-reddy-dots-data-channel-03 . Tiru Hi Thanks for your response and clarifications. Please see inline (Followed after [Ehud] ) Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Tuesday, February 14, 2017 4:53 PM To: Ehud Doron >; 'dots' > Cc: David Aviv > Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 a= nd draft-reddy-dots-data-channel-03 . Hi Ehud, Thanks for the detailed review, Please see inline (I will respond to data c= hannel comments in a separate mail) From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron Sent: Wednesday, February 8, 2017 7:21 PM To: 'dots' > Cc: David Aviv > Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-0= 7 and draft-reddy-dots-data-channel-03 . Tiru and authors Hi Attached please find my comments and feedbacks to draft-reddy-dots-signal-c= hannel-07 and draft-reddy-dots-data-channel-03 . Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel = draft-reddy-dots-signal-channel-07 1. General comment: For all signals in the draft, need to add means t= o allow vendor specific attributes as part of all signals transactions [TR] Yes, will update draft. 2. General comment: Just for clarity, need to explicitly mention on e= ach figure when it is an example or the actual API [TR] Done. 3. Page 3 second paragraph : DOTS should not be limited to "enterpris= e network" only [TR] Agreed, fixed. 4. Page 4 chapter 4: The overall context of the "happy eyeballs" and = its relations (or coexistence) to CoAP is not clear. [TR] Happy eyeballs mechanism is used to reduce connection delay to setup (= D)TLS session with the DOTS server. Happy eyeballs mechanism is not related= to CoAP. 5. Page 7 chapter 5.2.1: The need for YANG model cannot be understood= from text. What are the needs for YANG models? What is the relation to the= JSONs in the other chapters in the draft [TR] YANG is a data modeling language used to model configuration and state= data; The configuration and state data defined using YANG can be represen= ted in JSON or CBOR or XML. Since CBOR is binary, JSON is used in the draft= but only for illustrative purpose. 6. Page 14 figure 5: The mitigation request attributes are right but = not enough. Need to add more telemetry info about the actual attack that it= is required to mitigate, need to consider attributes in draft-doron-dots-t= elemetry-00 as part of the discussion in the WG. [TR] Yes, I plan to update the draft with telemetry info based on outcome o= f draft-doron-dots-telemetry-00. 7. Page 15 Life time attribute: More reasonable to have this attribut= e in minutes rather than seconds, bigger default can also suggested [TR] Changed to minutes 8. Page 15 last paragraph: Not sure that target port or target protoc= ol can define a protected entity. IP, FQDN, URI are the only "stand alone" = attributes , port and protocol are companion attributes. See also figure 9 = . [TR] Good point, fixed. 9. Page 15 last paragraph: The mitigation request is not clear, to wh= ich identifier the text is related ? "policy ID" ? I think the best is ha= ve another attribute to define the priority of mitigation requests [TR] policy-id is specific to a DOTS client, DOTS server need not compare t= he policy-id of one customer with the policy-id of another customer. Policy= -ids are only compared b/w multiple mitigation requests from the same DOTS = client to determine the priority. DOTS signaling channel runs over UDP, and= packets may arrive out-of-order; this was also one of the reasons to intro= duce policy-id. [Ehud] Consider to update the text in page 15 with your explanations here, = mainly regarding the "per customer uniqueness of DOTS". [TR2] NEW: The relative order of two mitigation requests from a DOTS client is determi= ned by comparing their respective policy-id values. 10. Page 21 table: The return status are right but not enough. Need to ad= d more telemetry info about the actual mitigation going on (how much traffi= c was mitigated) and the attack that are mitigated, need to consider attrib= utes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. [TR] Same response as 6; for now will update the draft to convey the follow= ing telemetry info from the DOTS server : total dropped byte count, average= dropped bytes per second, total dropped packet count and average dropped p= ackets per second. The list is not complete, what kind of telemetry info is= required for L7 attacks (e.g. attack at TLS, partial HTTP request, garbage= request etc.) and how do we deal with new type of DDOS attacks (Do we keep= updating the spec as and when a new DDOS attack is discovered) ? [Ehud] Agreed with the bytes / packets count drop you proposed. For the Lay= er 7 telemetries and for DDoS attacks list , I think we should first get to= an agreement about the needs for this attributes and then figure out the b= est way to signal this information. Personally I don't believe we should up= date the spec for each attack, therefor we need to figure out an efficient = means to signal this information. [TR2] Agreed. 11. Page 15 : Need to find the way to bind the target-ips with target-por= t-ranges and target-protocols, meaning that the server needs to understand = the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on = so forth. [TR] Yes, it's possible; create different aliases for IP1 TCP port 80 and I= P 2 UDP port 53 using DOTS data channel and convey the aliases in DOTS sign= al channel. 12. Page 21 last paragraph: This is very strong point. [TR] Thanks. 13. Page 25 : Regarding attack status, same point about telemetry. [TR] Same response as above. 14. Page 25 chapter 5.4: I believe it can valuable to add a short high le= vel description about the proposed API flow, same as you did for 5.3 . [TR] 5.3 gives background how GET, POST, DELETE and PUT will be used, hence= did not see a need to add a high level description in Section 5.4. 15. Page 27: The necessity of policy_id here is not clear enough, are th= e "Signal Channel Session Configuration" define only "single" DOTS session = or the entire communication between Client and Server for several DOTS requ= est for mitigation? [TR] It's for a single DOTS session between DOTS client and server, a sing= le DOTS session can be used for several DOTS requests and responses. 16. Page 27: Not sure about the reason for "at least one of the attribute= s heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor = MUST be present." Also consider to change to "presented". [TR] what is the point in conveying a POST request without any configuratio= n parameters/attributes ? [Ehud] OK, understood. So I think you need to emphasize that in cases not a= ll attributes are defined, need to use default values. In page 26 you wrote= something about "need not be default". Consider to re-write. [TR2] NEW: The DOTS agents MUST use the negotiated values for message transmission parameters and default values for non-negotiated message transmission parameters. The signaling channel session configuration is applicable to a single DOTS signal channel session between the DOTS agents. -Tiru 17. Page 30 chapter 5.5: Need to specify the overall scenario, in reactio= n to which signal (or API transaction POST of Mitigation Request , unidirec= tional notification from Server as describes in page 23 in page 21 ?) the = redirection occurred ? [TR] Both, updated draft. -Tiru Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel dr= aft-reddy-dots-data-channel-03 1. General comment: For all signal in the draft, need to add means to= allow vendor specific attributes as part of all signals transactions 2. Page 5 second paragraph: Why it is required to configure the DOTS = signal channel session ? 3. Page 8 chapter 3.2.1 : Any reason for not including these identifi= ers in the DOTS signal channel draft ? 4. Page 9 figure 3 : Need to find the way to bind the target-ips with= target-port-ranges and target-protocols, meaning that the server needs to = understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53= and so on so forth. 5. Page 13 chapter 3.3 : Need to emphasize that filtering rules are r= elevant for both client server direct communication and through a DOTS gate= way. The chapter is a bit confusing. 6. Page 14 chapter 3.3 : I am missing the white-list installation, is= it by using the permit action ? 7. Page 15 figure 8: For DDoS it is highly valuable to have rate limi= t as an action. Consider adding such action (if already defined need to exp= lain where and how). 8. Page 15 figure 8: Need to consider adding priority to an ACL to su= pport cases when several filtering rules are conflicting. 9. Page 15 : The action field cannot be optional attribute. 10. Page 16 chapter 3.3.3: Need to add more telemetry info about the actu= al traffic that was blocked (bps, pps and so on), but as I believe this mig= ht be another issue... Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 --_000_3bab57f083c346cfb491c29c7ff369ddXCHRCD017ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ehud,

 

Please see inline [TR2= ]

 

From: Ehud Doron [mailto:EhudD@Radware.com] <= br> Sent: Thursday, February 16, 2017 6:43 PM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; 'dots' &= lt;dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 .

 

Tiru Hi

 

Thanks for your respon= se and clarifications.

Please see inline (Fol= lowed after [Ehud] )

 

Thanks,

 

Ehud Doron <= span dir=3D"RTL">|  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Tuesday, February 14, 2017 4:53 PM
To: Ehud Doron <EhudD@Radwar= e.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radw= are.com>
Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 .

 

Hi Ehud,

 

Thanks for the detaile= d review, Please see inline (I will respond to data channel comments in a s= eparate mail)

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <dots@ietf.org>= ;
Cc: David Aviv <DavidA@Radw= are.com>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-ch= annel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru and authors Hi

 

Attached please find m= y comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-re= ddy-dots-data-channel-03 .

 

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy= -dots-signal-channel-07

 

1.     &= nbsp; General comment: For all signals in the draft, need= to add means to allow vendor specific attributes as part of all signals tr= ansactions

 

[TR] Yes, will update draft.

 

2.&n= bsp;      General comment: Just for clarity, need to e= xplicitly mention on each figure when it is an example or the actual API

 

[TR] Done.

 

3.     &= nbsp; Page 3 second paragraph : DOTS should not be limite= d to “enterprise network” only

 

[TR] Agreed, fixed.

 

4.     &= nbsp; Page 4 chapter 4: The overall context of the “= ;happy eyeballs” and its relations (or coexistence) to CoAP is not cl= ear.  

 

[TR] Happy eyeballs me= chanism is used to reduce connection delay to setup (D)TLS session with the= DOTS server. Happy eyeballs mechanism is not related to CoAP.<= /o:p>

 

5.     &= nbsp; Page 7 chapter 5.2.1: The need for YANG model canno= t be understood from text. What are the needs for YANG models? What is the = relation to the JSONs in the other chapters in the draft

 

[TR] YANG is a data mo= deling language used to model configuration and state data;  The confi= guration and state data defined using YANG can be represented in JSON or CB= OR or XML. Since CBOR is binary, JSON is used in the draft but only for illustrative purpose.

 

6.     &= nbsp; Page 14 figure 5: The mitigation request attributes= are right but not enough. Need to add more telemetry info about the actual= attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

[TR] Yes, I plan to up= date the draft with telemetry info based on outcome of draft-doron-dots-tel= emetry-00.

 

7.     &= nbsp; Page 15 Life time attribute: More reasonable to have this attribute in minutes rather tha= n seconds, bigger default can also suggested

 

[TR] Changed to minute= s

 

8.     &= nbsp; Page 15 last paragraph: Not sure that target port or target protocol can define a protect= ed entity. IP, FQDN, URI are the only “stand alone” attributes = , port and protocol are companion attributes. See also figure 9 .

 

[TR] Good point, fixed= .

 

9.     &= nbsp; Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is relate= d ?   “policy ID” ? I think the best is have another = attribute to define the priority of mitigation requests

[TR] policy-id is spec= ific to a DOTS client, DOTS server need not compare the policy-id of one cu= stomer with the policy-id of another customer. Policy-ids are only compared= b/w multiple mitigation requests from the same DOTS client to determine the priority. DOTS signaling channel run= s over UDP, and packets may arrive out-of-order; this was also one of the r= easons to introduce policy-id.

[Ehud] Consider to upd= ate the text in page 15 with your explanations here, mainly regarding the &= #8220;per customer uniqueness of DOTS”.

 

[TR2] NEW:<= /span>

The relative order of = two mitigation requests from a DOTS client is determined by comparing their= respective policy-id values.

 

10.&= nbsp;  Page 21 table: The return status are right b= ut not enough. Need to add more telemetry info about the actual mitigation = going on (how much traffic was mitigated) and the attack that are mitigated= , need to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

[TR] Same response as 6; for now will update the draft to convey the following telemetry info fro= m the DOTS server : total dropped byte count, average dropped byt= es per second, total dropped packet count and average dropped packets per s= econd. The list is not complete, what kind of telemetry info is required fo= r L7 attacks (e.g. attack at TLS, partial HTTP request, garbage request etc.) and how do we deal with new ty= pe of DDOS attacks (Do we keep updating the spec as and when a new DDOS att= ack is discovered) ?

[Ehud] Agreed with the= bytes / packets count drop you proposed. For the Layer 7 telemetries and f= or DDoS attacks list , I think we should first get to an agreement about th= e needs for this attributes and then figure out the best way to signal this information. Personally I don’= ;t believe we should update the spec for each attack, therefor we need to f= igure out an efficient means to signal this information.  <= /span>

 

[TR2] Agreed.

 

11.   Page 15 : Need to find the way to bind the target-i= ps with target-port-ranges and target-protocols, meani= ng that the server needs to understand the exact scope of attack, e.g. IP1 = TCP port 80, IP2 UDP port 53 and so on so forth.

 

[TR] Yes, it’s p= ossible; create different aliases for IP1 TCP port 80 and IP 2 UDP port 53 = using DOTS data channel and convey the aliases in DOTS signal channel.=

 

12.   Page 21 last paragraph: This is very strong point.<= o:p>

 

[TR] Thanks.

 

13.   Page 25 : Regarding attack status, same point about= telemetry.

 

[TR] Same response as above.

 

14.   Page 25 chapter 5.4: I believe it can valuable to a= dd a short high level description about the proposed API flow, same as you = did for 5.3 .

 

[TR] 5.3 gives backgro= und how GET, POST, DELETE and PUT will be used, hence did not see a need to= add a high level description in Section 5.4.

 

 

15.   Page 27:  The necessity of policy_id here is n= ot clear enough, are the “Signal Channel Session Configuration”= define only “single” DOTS session or the entire communication = between Client and Server for several DOTS request for mitigation?

 

[TR]  It’s = for a single DOTS session between DOTS client and server, a single DOTS ses= sion can be used for several DOTS requests and responses.=

 

16.   Page 27: Not sure about the reason for “at le= ast one of the attributes heartbeat-interval or max-retransmit or ack-timeo= ut or ack-random-factor MUST be present.” Also consider to change to = “presented”.

 

[TR] what is the point in conveying a POST request with=
out any configuration parameters/attributes ?
[Ehud] OK, understood. So I think you need to emphasize=
 that in cases not all attributes are defined, need to use default values. =
In page 26 you wrote something about “need not be default”. Con=
sider to re-write. 
 
[TR2] NEW:
The DOTS agents MUST use the negotiated values for message transmissio=
n
parameters and default values for non-negotiated message transmission<=
o:p>
parameters.  The signaling channel session configuration is<=
/o:p>
applicable to a single DOTS signal channel session between the DOTS
agents. 

 

-Tiru

 

17.   Page 30 chapter 5.5: Need to specify the overall sc= enario, in reaction to which signal (or API transaction POST of Mitigation = Request , unidirectional notification from Server as describes in page 23 i= n page 21 ?) the  redirection occurred ?

 

[TR] Both, updated dra= ft.

 

-Tiru

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-d= ots-data-channel-03

 

1.     &= nbsp; General comment: For all signal in the draft, need = to add means to allow vendor specific attributes as part of all signals tra= nsactions

 

2.     &= nbsp; Page 5 second paragraph: Why it is required to conf= igure the DOTS signal channel session ?  

 

3.     &= nbsp; Page 8 chapter 3.2.1 : Any reason for not including= these identifiers in the DOTS signal channel draft ?

 

4.     &= nbsp; Page 9 figure 3 : Need to find the way to bind the = target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e= .g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

5.     &= nbsp; Page 13 chapter 3.3 : Need to emphasize that filter= ing rules are relevant for both client server direct communication and thro= ugh a DOTS gateway. The chapter is a bit confusing.

 

6.     &= nbsp; Page 14 chapter 3.3 : I am missing the white-list i= nstallation, is it by using the permit action ?

 

7.     &= nbsp; Page 15 figure 8: For DDoS it is highly valuable to= have rate limit as an action. Consider adding such action (if already defi= ned need to explain where and how).

 

8.     &= nbsp; Page 15 figure 8: Need to consider adding priority = to an ACL to support cases when several filtering rules are conflicting.

 

9.     &= nbsp; Page 15 : The action field cannot be optional attri= bute.

 

10.   Page 16 chapter 3.3.3: Need to add more telemetry i= nfo about the actual traffic that was blocked (bps, pps and so on), but as = I believe this might be another issue…

 

 

 

Thanks,

 

Ehud Doron <= span dir=3D"RTL">|  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

 

--_000_3bab57f083c346cfb491c29c7ff369ddXCHRCD017ciscocom_-- From nobody Thu Feb 16 06:44:03 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96B7129638 for ; Thu, 16 Feb 2017 06:44:01 -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_PASS=-0.001] autolearn=ham autolearn_force=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 vzbhEzs7XzPJ for ; Thu, 16 Feb 2017 06:43:58 -0800 (PST) Received: from mailout1.radware.com (mailout1.radwarecloud.com [192.115.180.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A31D129468 for ; Thu, 16 Feb 2017 06:43:58 -0800 (PST) Received: from ILMB1.corp.radware.com ([169.254.1.237]) by ILCAS2.corp.radware.com ([176.200.120.122]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 16:43:55 +0200 From: Ehud Doron To: 'dots' Thread-Topic: DOTS Telemetry Thread-Index: AdKIYTXgs9jnVMU+R1WnPYyVGJhdZA== Date: Thu, 16 Feb 2017 14:43:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [176.200.121.207] x-tm-as-product-ver: SMEX-11.0.0.4179-8.100.1062-22888.006 x-tm-as-result: No--16.323500-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E58182C4A35A8E498E553AD3D33FA001011718C22BILMB1corpradw_" MIME-Version: 1.0 Archived-At: Subject: [Dots] DOTS Telemetry X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 16 Feb 2017 14:44:02 -0000 --_000_E58182C4A35A8E498E553AD3D33FA001011718C22BILMB1corpradw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All Following the WG last F2F meeting in Seoul, we would like to elaborate the = discussion about the DOTS Telemetry, mainly its general aspects and directi= ves. Up to now, we have two declarations for DOTS Telemetry: 1. The DOTS Requirement draft draft-ietf-dots-requirements-03d define= s : "DDoS attack telemetry: Collected behavioral characteristics defining = the nature of a DDoS attack. " . 2. The DOTS Telemetry draft draft-doron-dots-telemetry-00 defines "= "DOTS Telemetry" is defined as the collection of attributes characterizing = the actual attacks that have been detected and mitigated. The DOTS Telemetr= y is an optional set of attributes that can be signaled in the various DOTS= protocol messages. The DOTS Telemetry can be optionally sent from the DOTS= Client to Server and vice versa. We are now figuring out the general view on the DOTS Telemetry theme and ha= ve mapped two main categorizes of telemetry we believe are most relevant to= DOTS: 1. Telemetry for Visibility - The main objectives of this category is= to allow SOC / NOC teams, on both DOTS Client and Server side, to gain vis= ibility on the overall service provided by facilitating the DOTS signaling.= As perceptible examples, we can suggest the Mitigation Status requirement = (OP-004 from DOTS Requirement draft), attack details, attack BW and PPS, pa= cket / bytes drops and so on. 2. Telemetry for Mitigation - The main objective of this category is = to allow mitigation facilities to improve their detection and mitigation pe= rformance. As perceptible examples, we can suggest the Mitigation Efficacy = requirement (OP-007 from DOTS Requirement draft), traffic baseline in certa= in levels and so on. As part of the WG effort to define the DOTS baseline features (the DOTS MVP= s), we would like to get the WG feedbacks about the abovementioned telemetr= y categories and also about other possible suggested telemetry categories. = We encourage group members from both vendors and service providers to bring= -in their valuable feedbacks and needs on this matter. It is preferable for= us to get feedbacks on the suggested categories as a whole, rather than on= a specific telemetry attribute within a specific category. The main objective is allowing us to be able to direct, and focus, our work= on draft-doron-dots-telemetry-00 according the WG directives and needs. Kindly, we will appreciate any kind of feedbacks, DOTS Telemetry draft authors --_000_E58182C4A35A8E498E553AD3D33FA001011718C22BILMB1corpradw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All

 

Following the WG last F2F meeting in Seoul, we would= like to elaborate the discussion about the DOTS Telemetry, mainly its gene= ral aspects and directives.

 

Up to now, we have two declarations for DOTS Telemet= ry:

1.     &= nbsp; The DOTS Requirement draft= draft-ietf-dots-requirements-03d defines : “DDoS attack telemetry:&n= bsp; Collected behavioral characteristics defining the nature of a DDoS att= ack. “ .

2.     &= nbsp; The DOTS Telemetry draft d= raft-doron-dots-telemetry-00  defines  “"DOTS Telemetr= y" is defined as the collection of attributes characterizing the actua= l attacks that have been detected and mitigated. The DOTS Telemetry is an optional set of attributes that can be signaled in the various DOTS = protocol messages. The DOTS Telemetry can be optionally sent from the DOTS = Client to Server and vice versa.

 

We are now figuring out the general view on the DOTS= Telemetry theme and have mapped two main categorizes of telemetry we believe are most relevant to DOTS:<= /o:p>

 

1.     &= nbsp; Telemetry for Visibilit= y – The main objectives of this category is to allow SOC / NOC te= ams, on both DOTS Client and Server side, to gain visibility on the overall= service provided by facilitating the DOTS signaling. As perceptible examples, we can suggest the Mitigation Status r= equirement (OP-004 from DOTS Requirement draft), attack details, attack BW = and PPS, packet / bytes drops and so on.

 

2.     &= nbsp; Telemetry for Mitigatio= n – The main objective of this category is to allow mitigation fa= cilities to improve their detection and mitigation performance. As percepti= ble examples, we can suggest the Mitigation Efficacy requirement (OP-007 from DOTS Requirement draft), traffic baselin= e in certain levels and so on.  

 

As part of the WG effort to define the DOTS baseline= features (the DOTS MVPs), we would like to get the WG feedbacks about the = abovementioned telemetry categories and also about other possible suggested= telemetry categories. We encourage group members from both vendors and service providers to bring-in their va= luable feedbacks and needs on this matter. It is preferable for us to get f= eedbacks on the suggested categories as a whole, rather than on a specific telemetry= attribute within a specific category.  

  

The main objective is allowing us to be able to dire= ct, and focus, our work on draft-doron-dots-telemetry-00  according th= e WG directives and needs.

 

Kindly, we will appreciate any kind of feedbacks, &n= bsp;

 

DOTS Telemetry draft authors

 

--_000_E58182C4A35A8E498E553AD3D33FA001011718C22BILMB1corpradw_-- From nobody Thu Feb 16 06:52:53 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE6512961F for ; Thu, 16 Feb 2017 06:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com 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 8kjkK6jaZA5s for ; Thu, 16 Feb 2017 06:52:48 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0113.outbound.protection.outlook.com [104.47.36.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 295F3129536 for ; Thu, 16 Feb 2017 06:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KTT6u9bXlSXhW6mu59Gy89DEoTm/kvvlsfOwns06yV8=; b=BqMfEP+K7mHtZgHYzAXYaAp6ofT/P4SLCw2WS8gD0ZwrOYO23/MISo3agmXs5yPENvtNoxtmlOEOmYoZH6l6p86jDL816KpC8LhzOXTd99oWCrvmTGsxr7Pky5xk9Z41I7coLRVxg+KEDI5+ZXj44ka1/FIE822f9eqfwmq3z8o= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; Received: from [172.19.254.104] (49.228.118.161) by BN3PR0101MB1027.prod.exchangelabs.com (10.160.182.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 16 Feb 2017 14:52:45 +0000 From: Roland Dobbins To: dots Date: Thu, 16 Feb 2017 21:52:29 +0700 Message-ID: <77D31C33-5457-4CF5-97F0-65B2510ACC34@arbor.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5344) X-Originating-IP: [49.228.118.161] X-ClientProxiedBy: KL1PR0201CA0034.apcprd02.prod.outlook.com (10.167.53.172) To BN3PR0101MB1027.prod.exchangelabs.com (10.160.182.156) X-MS-Office365-Filtering-Correlation-Id: b72a7281-373c-4916-8b36-08d4567b784b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0101MB1027; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1027; 3:DHPsnPc3dVLY6r6lcZOIXHnLuUWIj2sACMGg/WRnCabAC/vpu56pf8PzznDtiej+4Rzwz6KbxWJXw4bPqKYlNVOK2KZ1UxN+CiAvCldfXGdg4sjn6TbJuG9RsJty2/BZvXNSEo/yXC5IyTr0Sxn/Lcl2y8f3O5jb7zoPHmZZ1JoZ1zA9mtCKszAFIzlcyE1kWT2BFj9EH5AADE3pa1EbglcJ94rTB6D+F28pgKwnG4g/HdVbuTzpT+nYW/CgFbErTnUN5XebHdnaXdjfV353nw==; 25:NfvEmvsgSqtwKAu40whvkXjAuOfgD/qIB0NqE2ihnQJn+mOT0IDK6fcsdlR1/l8RMxrcMPyG7TVIBYJ2VeshDoHFCpbl/UhS52m7408RZFbUBc/f59U095wnKmF4Q8+kT0Wmqcn7frAxOCDcFSRJmupvOW69VWmY1x83Y+uQ9eFea6YsgXZsXoNa8sZ67zbOfFNQNiEV8KmawkuECbpDmnJHp5hPy7MDv2yirXD5bpFk7o3jaDqBiQeRSej5FTq1CMnzuBrzxclb7GTupAIXSgx9doPHuYohMTfYnZOuSJjLQR/rPaVjCdKuQF0NFCjAynqAan1vnuG0lO54dUmtbERTjSD2KyFmsrui1VU0TtmZwesotN+30W2FZkp+wQU5on6igxL3wAKaLYZsB6SVZ3kOk8z+ffVhptCsTImdHd7jwQlZUJDQjXVCZqaeFRXA8HL/3S760FKatq1XEgLrQQ== X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1027; 31:8jZjgPQXx3GHEOQm/5KiPChuPvud5DfgZwQFuGRtCKm4rVnOv8h4px6Ma2HV84xflYr9TmjGXKFrgAcme/DLOl8MhlKCGTfnlnqDkf81N7jfbmcZ4gQUtE3laXQHWXYUFrvSgbPwEvaU5xJUeJr0U8KPxYNx3miog5aPJ39WviivyQGYU+FVLmjKAwhGJaaWJcSSIveR6oHnfBRHqIsw0jmIcofW0J4dwTMaKHYPx+FT6D8Em2+gAaW8A6Wqs3B86L1n4snbAF3Lc23AGL4HZQ==; 20:gmGsjM0ZhTD5/330H8oQtzWG0w3/+dnsOY20vPqnK5/6pdW6Ogie9E/+2oCdweBnUqLoX6WwZosq9ig8ZoY7v498kupvwfIEizdDm/8Tx/Zd3LV8BgyxM5Sz/6oYuYxGZcE99SfA/8wMq2cjGWQsXca74JRlCUIEc6fqHHDGjDOT7fEwieDKF9cIHJMF4cU6a5sbhW9Wm/ECdLc6yg0sY0Ssbw1wtt7fMpTYdM4mn/0mUyJc98FVtn6vAks0of5CJcMSZL5L18bmPPpQboGmlK3l8+l8jpNV7AEYdd8Pz1FKjiqZRjJ8DeVghKTkTaBrRjc4sObvtbbhkYczz7P0JDruDgq9HlmmA85mS31D4uEln0nj+8JEqe8lnhcdmpHjnW40jwz0WAl220uySgtfl96iNRHyfftjnTGa0PxMTt+yNQHnNP2bEmE9Tl6OegbvTNiG2qGS00Id4B4XgaZFJRCkOV9haIkSy15oUlGDqsMH6nkxNnANhbSm5Mb8ALjj X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558025)(6072148); SRVR:BN3PR0101MB1027; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0101MB1027; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1027; 4:fN0YwJ71NHMzCzNWg60rVH8FJE2vYj1i5k1VxUyTZnUlA3OVZBQyCaeNq0biSZXnhGjYoQ6V62j0r2EbEarixolsB5elxfWwZoYQFcS3ySQByvjtXjywU9XwCmba89SOnZd91LDHfucs6WQdUk+zb1xqb48rRnKRFlglaZHvbrGuY7eyxLIH+3bk+fQ6tfRoYPssGrQZ28DVGuM+Sera2sd5I4UsH4k9KXJP3RPHcWSX1t9i1RLRfMiiSfoCIp5HMXTyjFX4VcjHiRE2mhvSG0uI5/4vQbdfnFG701b5TEflPVoW2V4nAo0YryEmA+a+wAPmst3VkHr0OqTiGmIWs6wbgV4tjAnMbBdNn3RsCJ+LsUkUgHu+0Q9Vc49aVX6oN1Unl6ZXCRVaSvb6H4nzDLEPFwY9nsgzI15zyKgPAhXfUs5ADod68uQPvzwOzD+3xWbCnVMswt8ifSJVn/N9bdnm1FwtW5rz/qkVAzZBWG/5NfatYpnzy3CGlb86kGB/39OAdht/7tjCQNT9sBehusKzGq44zFOdjd93a4KC6xbnvn/qQQrCsmTdCmlwhkQLMnz2OKnjI1p0K0Qs7kykOQFpiqLa4kmdtL5tM7cW/4s= X-Forefront-PRVS: 0220D4B98D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(39450400003)(199003)(24454002)(189002)(5003940100001)(92566002)(105586002)(42186005)(101416001)(2906002)(106356001)(86362001)(110136004)(47776003)(66066001)(33656002)(6116002)(3846002)(82746002)(53936002)(6666003)(83716003)(90366009)(6916009)(68736007)(2950100002)(6486002)(77096006)(50466002)(5660300001)(50226002)(38730400002)(229853002)(81166006)(450100001)(97736004)(8676002)(81156014)(6246003)(36756003)(76176999)(189998001)(305945005)(50986999)(25786008)(389900003)(7736002)(53546004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0101MB1027; H:[172.19.254.104]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1027; 23:pq4xb2v84yAGWPqBrSWs8Cp79KCGPo5Ou0lkcae?= =?us-ascii?Q?/Gjkc2jW5njT5m63vw1APSWZGNjEfLBKpND77Ui+QUM+iDDHwktzcV2WKFro?= =?us-ascii?Q?NlB+kElxwnNg+ajGMmI2FzEgkFa4v8265QDJ0FXbvrXQVFd0xzo16y61sxDP?= =?us-ascii?Q?NY/qK8GugucA+8KXOYe4SsINbLfVcUi5l26Lfd958qW9ME8qatlTJymt/09H?= =?us-ascii?Q?Dq2b6vKQiLRlwWZ0WWnJiUpiGXyHWnE3/bMj1zuexqXTBhJb8DZKqYEWA/EO?= =?us-ascii?Q?XbV5iM3uSRV0Euc6iOp76+rmBd7w+vffKBm5r7EvACDhMvEjjytVuyd5k5w5?= =?us-ascii?Q?Xwl7gT1xseSwu8sq1GrIEhwd33Axjuwzk9wWfJoYUICVCd/wXv7nM/DlLYvt?= =?us-ascii?Q?LvjKf74q8JIxfkw2s9WbfUzKgpgcVaOpqd/HRmhOsE/v8NHgxLfiRtVQF4oh?= =?us-ascii?Q?pZCEb2TrgIkPMkcdiFmujmlWr52yQx7mihmxdfoPQsIw8NLqwA5ksfaeBeuM?= =?us-ascii?Q?xhPz0VLC5Du2Yam/JrDxZMj0Aug3fCshPln2lXarlTp50MQ219r3sjhBKkc5?= =?us-ascii?Q?Vi+mcStSP2IT3b/oEae53qm/IrM5wcmOKLhxSkr4qAiXQe39CthGZ+ZlcpSD?= =?us-ascii?Q?9fLWNWNZkhlgsJfYE8VUsoYIyc3Dkjtd15Tvxmc+YFtMxhPIFhUi9tuoZB8A?= =?us-ascii?Q?azSCOs8eCrxUU3TsTym4czJeMXDkrqFKIUiWeKQVRsKxwK5yyNiOHhaJVIc1?= =?us-ascii?Q?xLXhuhQ/bzplW9s8GWkeWYwBEqtk6+4N59yTpW6m4NZTW1f3dTRoETE4K35r?= =?us-ascii?Q?pOoGJBqeTbaroj8eDcsnKBVINKfNST5ZkLdGDgzZ6A/5Qi3VC+784My4cX9m?= =?us-ascii?Q?s3eD5EI8exUzh7opFfOLun7sCgo2Bf4YhtI5Yo+vg7ZG/riagYN85xqxx95y?= =?us-ascii?Q?1Ax/LjERPmF8Hfrc7Kp/G5253Y6SZRNh+WmPoT3d4xkrb+PfBEdxn+SMwNcl?= =?us-ascii?Q?OSsvWGZnvY9b5uQq9rqgG0mJqdahiIVDzC41xZPOuZsOoRWNKNWTFemg4SR8?= =?us-ascii?Q?wt+hBzLaKLC7OgM4iVpdS3/6/z/h114sQYCAJF5vKn1gjBYngXV15RjKBQl8?= =?us-ascii?Q?vvjZNUTWWTKhDBbIgJg2mCuaFVchDXmMaUy5hjaTp0KLF69qNdT98FvC5y5u?= =?us-ascii?Q?scJZFMav+vs9Uc9yYVTT+WhxK+HBegSSgW0ZSk5H+IKnS+ay3StsRGJEkKzG?= =?us-ascii?Q?d5e2ELNzI6WPE6gmUnCaj5Pik6706zZwR4TWJPU8a?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1027; 6:jZlEtWIzTDde9Allmt/eWzw/LqTSeevl37JzVJdjH9AbtuJgg4qpO3L9AFPqLrw+9JB/EQE6a0rVf5EagTtGRvPN1rUUzl8mYzTneQAP4rTbstd7kyH3ILWk90pG177n1F6Ceg/+QKy7IMSngT3LWUQOadppX3myERPuG4B4gle+qFKdkZrGapYYz+fJ4AOUL+SoV+AzFU2YqO74A8hVgNOQk8TPNpgw+lbsNjcqpAj1aqtLv9xkWR0YWh/cxv/o0j9V8sSeYTOEbuJBZdjHVRx1dmYVciKlM2odCF9IlNTW7jYoU6sdqPyc6XF7SZLvMgkTLicHjpAiOI7zVpZEx/4S2FqdWO+7BHXAQ9/6K4PGSFP8/tlirXVtPhbKSj5swfaHLDIR8DbXjbzcQBZFZw==; 5:oi3xJPlJMLyWLZVkROXUHsM1ErvpULiS8fQRarpVk/wCBD8pVDSckXVfrrYG0y4aueoeiNfR/sxugE6JCyyVj4OwTwQGE1CANTZO0YvEd6sJt1IZHOGu0IwnUL0mgFCn0HwMo5AuO0qeymigEvY2gphdH7GNWCUrktFx1y4Z9RE=; 24:U85lEAhvqlCLXeGzxN4oDvx/Y7so5yNUZmYXhluxIHJBN24UlvSnVNWTDatYQGTqv3Jbd74W8TXt4QAhI+L+xiaQCTQIXWk8/zPPD1YID3M= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1027; 7:bg4e7SenCTtRlc+FxMTK2tZVcOdk/hkcmyHAmHAtYO41PxrZioFYk5TBZY86YEnk09CKjMSd9rf9BjAm/RElGkafWW+pQIJAfQRnb2gBD5C6dwWO/HIdXMLcN50Qw9eZQwyvxSxDgi985B51UVLEgSuw3r3NvRAjGiVfu/YoGj761ff3n/C4VrEk0K00B820AIjsyLd68yNxR/oTDSHZ1OnvysaxN9rKUU0Uu8qL3YIQqDuQjcaSdQa9dDEf391X9kXauyTv7Lbdq0qpScgLc3ZZRirFS9EKZhhAQqFfFjC34RnyIbEhMn8O5OGWMhDfZFRI/fleQFo+LeQeD83Q7g== X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2017 14:52:45.7158 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0101MB1027 Archived-At: Subject: Re: [Dots] DOTS Telemetry X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 16 Feb 2017 14:52:51 -0000 On 16 Feb 2017, at 21:43, Ehud Doron wrote: > Kindly, we will appreciate any kind of feedbacks, This is duplicative of existing telemetry formats such as NetFlow, IPFIX, dnstap, et. al., and should be more properly addressed in the relevant WGs, IMHO. The requirements-draft definition is intended to explain terminology used in discussions. There is no need for any additional telemetry in order to get DOTS to MVP status. Let's concentrate on the signaling functionality, and circle back to telemetry after that? ----------------------------------- Roland Dobbins From nobody Thu Feb 16 07:15:12 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE55F129CFB for ; Thu, 16 Feb 2017 07:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com 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 4tCb8d2tSbIb for ; Thu, 16 Feb 2017 07:15:09 -0800 (PST) Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15425129509 for ; Thu, 16 Feb 2017 07:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=1396; q=dns/txt; s=VRSN; t=1487258109; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=B00yzCEa/FQzzNAD86Wt27FAv254L0LIBF3ganP1y6s=; b=j7Y6uXQF+yXutuQyc47MsPQZvxQuhFX8rFtyKF1oQJQcBqqAT+vjw33M C/Oo+R7jWDqK5JVVuR2JtnCMVo/Uvi4FTBAQTLESQmI2/4UjIws0posCj kd2DesKjv/jJC99ikMBxyaK3Fb4/SuQgVh04v2FoY1szCItfjO4yWrKia JExa5IvgqBrvY+szqk2kdniO1QayBQEpHTv9jqVUp5N83EFK5lGy2FDje VUstZ3OopXO3VIFal2VauUZiy4Eh17DsvkBLr7WZeStzNdsNPZyhKRtv7 0uFNIScHgei5YTXMG17G0jj9/BLZNrWC+QbRK8FLabgkh4VvHwNAkGbv4 Q==; X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208";a="1521120" IronPort-PHdr: =?us-ascii?q?9a23=3AN1vpsxdQpqDcb+KwfjQZOgEtlGMj4u6mDksu8pMi?= =?us-ascii?q?zoh2WeGdxcSyYR7h7PlgxGXEQZ/co6odzbGH7ua4BSdfuN6oizMrSNR0TRgLiM?= =?us-ascii?q?EbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ/iOgVr?= =?us-ascii?q?O+/7BpDdj9it1+C15pbffxhEiCCzbL52LBi6txndu8YZjYZgN6o61wfErGZPd+?= =?us-ascii?q?lK321jOEidnwz75se+/Z5j9zpftvc8/MNeUqv0Yro1Q6VAADspL2466svrtQLe?= =?us-ascii?q?TQSU/XsTTn8WkhtTDAfb6hzxQ4r8vTH7tup53ymaINH2QLUpUjms86tnVBnlgz?= =?us-ascii?q?ocOjUn7G/YlNB/jKNDoBKguRN/xZLUYJqIP/Z6Z6/RYM8WSXZEUstXSidPAJ6z?= =?us-ascii?q?b5EXAuQBI+hWspX9qVUNoxSwBAmjGOzhxTBTi3/qxqI61vgtHR3c0QEiGd8FrX?= =?us-ascii?q?TarM/yNKcXSe25wrfGwivZYPNZxDfy9pDEeQ05r/GNXrJ8f9faxE4pFwPZkFqf?= =?us-ascii?q?s4PlPy6L2ekWrWiU8fBgVeO0i24mpAFxpCKjydsrionMn48YzE3P+yZhwIstON?= =?us-ascii?q?G0VFR3bcOmHZZerS2WKot7T804T212tys3yqUKtYOncCQQ1ZgqxRDSZ+aaf4WI?= =?us-ascii?q?/B7vTumcLDFlj3x/Yr2/nQy98U24x+35Ucm7zUhFozJektnJqnANzxvT6tWbSv?= =?us-ascii?q?dl/keuxzKP1wfL5+5fO0A0k7fXK5ouw741jJUTsEDDHijrmEXqkKOaaF8o+va2?= =?us-ascii?q?5OT9Y7XmvZ6cN4Byig3kLqsuncm/Dfw5MggIQWeb5fyx2KD/8UHjXblHjPM7nr?= =?us-ascii?q?PEvJ3aK8kXvLC1DgBV34o77hawFTam0NAWnXkdK1JFfQqKj471O17QOv/4Auq/?= =?us-ascii?q?jEq3nTd12f/GJLzhAo7MLnjMlrftZ6py60lZyAYr19BQ+4pUCq0dIPL0QkL+qd?= =?us-ascii?q?vYDgMiMwGvwuboFsl91o0EVWKIGK+ZP7vYsUWU6eI3P+mMeIgVtS7yJfgl+v7h?= =?us-ascii?q?kHE3lEQHfaazwJQWZmq3Hu54LEmDfXXshdIBQi82uV8TTPHmwHGFSzlVLyKfX7?= =?us-ascii?q?8wyhkBAY65BJ3OAIuqherFlG30EppKfS8MQgSAFmvzX4SJR/lKbziddJxPiDsB?= =?us-ascii?q?APKdRoYuyBzq/Cn7yPAveuzI9yQXqJ/LytVv5vbSmhd0/jtxWZfOm1qRRn15yz?= =?us-ascii?q?tbDwQ927py9Akkkg+O?= X-IPAS-Result: =?us-ascii?q?A2GHAQCewaVY//WZrQpeGwEBAQMBAQEJAQEBFwEBBAEBCgE?= =?us-ascii?q?Bgn2CEweDUooIpTSCD4IMGoYIHIItGAEBAQEBAQEBAQEBAoEHgjMiAYIbBiMRV?= =?us-ascii?q?wEIDQ0CJgIEMBUSBAESuiKCJYs6AQEBBwEBAQEBAQEhgQuFQoIEgmqEa4JvLoI?= =?us-ascii?q?xBZt/AaMckxgfgTlRFU4BhjJ1iSqBDQEBAQ?= Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id v1GFEqKS020183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 10:14:52 -0500 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Thu, 16 Feb 2017 10:14:51 -0500 From: "Teague, Nik" To: Ehud Doron , "'dots'" Thread-Topic: [Dots] DOTS Telemetry Thread-Index: AQHSiGdqIA9wGekax0icMfREU0IJKQ== Date: Thu, 16 Feb 2017 15:14:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.0.161115 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-ID: <8865A533E7C7054FA9A1F1C6F2856BF0@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS Telemetry X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 16 Feb 2017 15:15:11 -0000 T24gMTYvMDIvMjAxNywgMTQ6NDMsICJEb3RzIG9uIGJlaGFsZiBvZiBFaHVkIERvcm9uIiA8ZG90 cy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBFaHVkREBSYWR3YXJlLmNvbT4gd3JvdGU6 DQoNCiAgICBBcyBwYXJ0IG9mIHRoZSBXRyBlZmZvcnQgdG8gZGVmaW5lIHRoZSBET1RTIGJhc2Vs aW5lIGZlYXR1cmVzICh0aGUgRE9UUyBNVlBzKSwgd2Ugd291bGQgbGlrZSB0byBnZXQgdGhlIFdH IGZlZWRiYWNrcyBhYm91dCB0aGUgYWJvdmVtZW50aW9uZWQgdGVsZW1ldHJ5IGNhdGVnb3JpZXMg YW5kIGFsc28gYWJvdXQgb3RoZXIgcG9zc2libGUgc3VnZ2VzdGVkIHRlbGVtZXRyeSBjYXRlZ29y aWVzLiBXZSBlbmNvdXJhZ2UgZ3JvdXAgbWVtYmVycyBmcm9tIGJvdGggdmVuZG9ycyBhbmQgc2Vy dmljZSBwcm92aWRlcnMgdG8gYnJpbmctaW4gdGhlaXIgdmFsdWFibGUgZmVlZGJhY2tzIGFuZCBu ZWVkcyBvbiB0aGlzIG1hdHRlci4NCg0KSSB3b3VsZG7igJl0IGNsYXNzaWZ5IHRlbGVtZXRyeSBh cyBhbiBvcHRpb25hbCBmZWF0dXJlIGFzIG5lY2Vzc2FyeSBvciByZWxldmFudCB0byBNVlAg4oCT IFRlbGVtZXRyeSBoYXMgdmFyeWluZyBkZWdyZWVzIG9mIHVzZWZ1bG5lc3MgZGVwZW5kaW5nIHVw b24gc3BlY2lmaWMgYXJjaGl0ZWN0dXJlcyBvciB2ZW5kb3IgaW1wbGVtZW50YXRpb25zIGFuZCBp biBtYW55IGNhc2VzLCBtYXkgYmUgY292ZXJlZCBieSBvdGhlciBtZWNoYW5pc21zIHN1Y2ggYXMg ZmxvdyBjb2xsZWN0aW9uIGV0Yy4gdG8gdGhlIHBvaW50IG9mIGJlaW5nIHJlZHVuZGFudCBhbGwg dG9nZXRoZXIuICBJIGRvbuKAmXQgYmVsaWV2ZSB0ZWxlbWV0cnkgc2hvdWxkIGJlIGluY2x1ZGVk IGluIHRoZSBiYXNlIERPVFMgc2lnbmFscyBhbmQgYXMgaXRzIGZyZXF1ZW50bHkgY2FsbGVkIG91 dCB0byBiZSBvcHRpb25hbCBJIHdvdWxkIHNpbXBseSBsb29rIHRvIHV0aWxpemUgZXh0ZW5zaW9u cyBvciB2ZW5kb3Igc3BlY2lmaWMgZmllbGRzLg0KDQpUaGFua3MsDQoNCi1OaWsNCg0K From nobody Thu Feb 16 07:16:42 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CB01293DF for ; Thu, 16 Feb 2017 07:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com 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-HbwJs1hfak for ; Thu, 16 Feb 2017 07:16:32 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0096.outbound.protection.outlook.com [104.47.32.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406A112962F for ; Thu, 16 Feb 2017 07:16:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=phoySYF5MP3gytlI6LfUhUTiB3pSLmQCmSE7THF2Eg8=; b=cYmxuiy1soBT38JIAjKmykRx03U6aH/zi7qoKk8BKGaBMJ/aw5wQizIRE313KlO3OHDWkcYXtxnglnpeIr1iVOc+KZa+dfRBNnjZXakBxLcLxsX8oLOfvO3bBZcQFvLzOxNIjD+dF8I9ST/36u4+aL2ELfor0lmiat3MPyUw32w= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; Received: from [172.19.254.104] (49.228.118.161) by CY1PR0101MB1033.prod.exchangelabs.com (10.160.225.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 16 Feb 2017 15:16:30 +0000 From: Roland Dobbins To: dots Date: Thu, 16 Feb 2017 22:16:11 +0700 Message-ID: <083C94BA-6E98-4E5D-93B6-7B9CA5219E64@arbor.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5344) X-Originating-IP: [49.228.118.161] X-ClientProxiedBy: SIXPR04CA0043.apcprd04.prod.outlook.com (10.162.171.33) To CY1PR0101MB1033.prod.exchangelabs.com (10.160.225.13) X-MS-Office365-Filtering-Correlation-Id: 4cf1c28f-8d12-4571-648a-08d4567ec942 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0101MB1033; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1033; 3:0imL1+VaxNRbQRyv9CtLAUNcco5WiNiMcAKSAOMnvsDPtijBgf+AoQkAPlTbDA0vx4VrP42jQg0vkAUMOs/vt+nJDj+tSztMgl1zGuf7Qp5dvPGwuH+FSWsaFkhLTihPgb6eYMeTC1ZQT3quyz76nq+pm3g1lZC4+QFso+VJyo3SMV3aeSv3eLt0cLNiny27u5EjPNy6q+FZ6GFfaJtbRRVK5fDxLYSL2xiKMQo9AwXidrGgxoL0gUJtWo3ZPNDYUS9Tbkj3550LUGM6BD2KIw==; 25:xATLO47QlBttS3KE0NiivvhhlMQxSfytN9AKc9a5KX6D1t69lKKjb+cqR6NkvOLTx+z39sEJHTtpyO8KnmZ4qxGP7aBi6Bshhk5921NfPXhi8Ke4Q8/FnuK0rv+00KRGb7JrpN17DyM8AxMn4mTB6CorjwtgkkOg5U3JN0hlz0REZgvaYncIXe/LV10ZifRxUMiU/LClEMFW44WFSHvghEN2MqPVrAJFU6Y4FvQq8LgB++ixQebFODqkwRxWsv7EAqyCZfkDBVU6aNrw9vvWmp9jXfSYwZgEMtKwlW1b0gYLMve+6ehOpZr0LA4S68JMrW8smVGnLWtI2bHKqRDHI1Nd7UXiMAnOEUsgkxya3CXwlOI8/fC47uH6Fd1EgQ3ue3epCtWuv7v6YUk6SXHpQq13fNc9Qzc6g2qsYs4WW4q92M5Wa5OdHFf58tBazNbt2EpKCLM5vh04HDbsQjJAiA== X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1033; 31:cQdk1eKOf4sf8bJ7x5qVNaUOLF8JHExxTR2COa0eI4saARs97B9Zi8vwyc/OLFBw8J0C42ROzcwUzjc0lfxdHUnPotWLUIb1KaKZe2lhlZ9mjJ0zpS0f65gUn+fp4Wgni+sgJuR3r/y5priQwyV8Bu/46zF23gjpgYU03/7EVramWAvx/HU/0o+/rfM6DlskTYyJjNeYLLrNJ6XnmVMHecMwNmMOyPQjAFhf2txG0+8kADQbRbNMy1RrDna5wAq707d+WEctpur7Pr0uxY7HDw==; 20:j+ANe25flkRz1txL2Ozm7ifTBOzDX+heanWxAZDh2MFjm1FuKZAOdG2f2M4NMSdIYs1ix46ivgyg58mK7SqSjWOIx46g50sPC+22yyr1cGbhy7+joapintz+dahLnFEPTZ0A+ZJb+BCESzULI8zTd/ZaclVVIYONtbe3OLA3ZknNGzATfarywzqol4BZcBA5i8Yo3iN6J+2fQh/8sxnBhwoj78F8UjKVDrg0t0Bwe8bImgno2ZQQEXfz5M0BbdzGkzhuHV+gb3q2c7RHSmYKXe7kHYv2R62ojgXXYyAionV3rerjqPmJZS9Lu62x/x60X+Xz7QAN3yDwcxxoSUvgdmjBiVTs/boox0auVlrx9fPl/EKFUQG+6m7yJzYa7KnMsBiw3sfi+CkSGclY09vMxNQVPDzW+Mu3kXNiCfCQGjtfrbIVd+L9zRTjSAhguNORxBJrDQE/ZfPMFFZpGSR39SRdXjCEpR04W5vCucuI19GR/iYrfILNiX6jht5ghhnq X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:CY1PR0101MB1033; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0101MB1033; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1033; 4:wMNltk1aHtaYXcZ6AwH3PnF4Xi7ZrBVHuHVVF1f0OH34g7nh/i5oaa8SdD5wFyTNjW5/lglf1lfFRfWgQSWjC0ZmDI1u30MBjnh2xxl4WJBXhf8aoQJ/hQ3WHZ/GlnAJbDP93l8LnPzjmQqK6f0MoFpnSXk6Kni1vu775w3nRqzl7RTsZ2SBYiyBQVN1EH7A9YrybG+8A6ueC/0Gg/N1rIoSS0/yfnXijOyw3c59PqkBR7tQmB88JeXRcFKoc9t8pufv8qVLZSDb5OPlsIyplLd0SoeLjiV1l4B6DTNVMyzWvlmPBEIvvrPcso3Ss4ECKM+tgyZ5BdH6Csfb/fvaiBJNkEtSZ1onT6SKStWcDZwJOAK9jf9f667z6pi3XARTKIghQjGv8zwvqyPxfH0fmZH3G40nOhQcJ4hKnDVsHepHBNY7TnhlLQgvfkfX2/qCEirplaHSPD7sJkH7Z0I4yPh/Z1yceOT9020MKHu+R65GY8Dj+f5nfjYX4u63VJvog9tErBAowigA6QYuFAdgOyXJFzXDJa7owLScdxOPyVEiRnFu/geLqsX5Ng9g8KOxNKrLPTWKTiIchl38eWBmOw== X-Forefront-PRVS: 0220D4B98D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(39450400003)(24454002)(189002)(199003)(6246003)(36756003)(106356001)(305945005)(6486002)(82746002)(101416001)(5660300001)(105586002)(189998001)(77096006)(90366009)(110136004)(83716003)(38730400002)(6666003)(2870700001)(53546005)(23676002)(7736002)(6916009)(42186005)(2950100002)(2906002)(86362001)(53936002)(68736007)(81166006)(97736004)(92566002)(8676002)(229853002)(81156014)(50986999)(25786008)(47776003)(66066001)(33656002)(76176999)(50466002)(50226002)(3846002)(6116002)(450100001)(389900003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0101MB1033; H:[172.19.254.104]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjAxMDFNQjEwMzM7MjM6NEMyNTU1bzZOK0tjOEF3cWU2a1k2bW1x?= =?utf-8?B?cjFNTitZcUViSW1tUEt4STMyM1hJVWIyL040WmF2cHlRS2ozYlJ5RVBNc1Fh?= =?utf-8?B?MkJ5bUlSaXU5bHhxams0emlNdFFMNWNzcEpSWnBqTW9lVHY5Tk82Zk5HVDJ2?= =?utf-8?B?Y1FHZ3d5VE1UR08xa1o4SkhUaU1xQlJIVFRWSUlxM29uck9lWFpYL3N2NlZT?= =?utf-8?B?VzV3bldLQkc0KzNubHNHaXZTOGZCWnJaWWYvd05qNDlJM2JiNExkN3c4Z1Z3?= =?utf-8?B?SVlVNWdGWFlOMDNWS0MzcE1LVklRRFdqTFBTSkgxMWhuVHdzMldsQkMyS2lH?= =?utf-8?B?dkVlbGRnb2hvdlU0UTRzUlVubHplOGhzZkJWVXFqMC93NUtFZE82OXhYYlV6?= =?utf-8?B?TU41UFE4Sm5LeWwvUTNOTEp2ank5eExlL05TS1FWSXlYMTh0OGFROGVYTm5O?= =?utf-8?B?dTd0RlU2TmtYRE82SThkNXlMNTBlc1BKeno1YUpQa3JTNGR3ZDV1eWV2WFND?= =?utf-8?B?YXZOSWY0WVZNa25BTk9ucUR1WjFQRmI0TmlUQy83NS85Z3VzQzdvZ3RIa3Fn?= =?utf-8?B?djN0dFM2VHNzU044eVdXdGFMUVorUjVNdFlpTHp1cHBNVWc3Q3l4Q2pOT2Er?= =?utf-8?B?NEpjdXM4STFtb3Fnc0E5ajFHSnpCOVpLZElpVnFqVzRHb1REQVlvQkpqeHJh?= =?utf-8?B?OHFkNDlRTlRiQzRuVWwwdzFWdVIwZWVWRXpyRTRNNVEvYTl4aUhiTy9wZGZT?= =?utf-8?B?VFhRbmZPZjZWVlV0cDU3RExoZTVKTmYrSXBqR0paNVB0ZE1uMXpuZzYxdjg0?= =?utf-8?B?RDBUS2plMlg5eHhpQ1BhWmRscTRNNnEwNW45V1NseDkraDVRVFlIcnNCSDJ6?= =?utf-8?B?VmYrcmw1NWh1WFJBVmhmN1VldldoL2RDTWVYankzOXFYelV2R3hZQkIvcTJn?= =?utf-8?B?ZVNxYmFtUmZWUW5EQW5MeG1JenlNOUJPVnVwRXhPK3FWU0VvdWNBWUQxMThX?= =?utf-8?B?QVNvNzY0OWFUSC9aTXRvUVBYY01WNWlLdW9vbnpEcml5Ymo5by9CY3kyOFV2?= =?utf-8?B?OWVOOU1FK3dxOXU5MCtGUlNPOU1UNjNpelhhVTFlTW02VjVTWTVpMTlMa3dD?= =?utf-8?B?aFRValVDSVVHMk9nRGplSElrTVVSdkt2QTJGRElVc2VGYkNoY09tT28yd1pK?= =?utf-8?B?N211bmprRmE3dDdVNUtiQXpVbUxqYi91UkI1M0JkUWtMUUg4R2U5QWtDUWJm?= =?utf-8?B?UkcxN0tEWVhaQlltMXRvcWE1SFhLLy9ENmVkT0JzQlhuNkd6dkFSazFzbXZo?= =?utf-8?B?enRsUEtKVFVEZkhtalh2a2srRG9IM2JWdUVUZUMwMXpKUmg2QndtM3pZTzV5?= =?utf-8?B?NnIyL21QZ0gwRkNqYXBqQ0NQTFNFUkFvVHE3ZC9tMVJHNXNaKzliUElCZWhL?= =?utf-8?B?SjRXTGFSTVZ4RkI5V3JLSzdDd3oyU3BMcTMyYStUNTFlVEJvSnpZQ21lVE5V?= =?utf-8?B?bVdTK2xaaTdiRTRpY21JNVQ3SVplcTJwMEVoeUtHanIyb1p1MVRoajVYSlgx?= =?utf-8?B?Q2wxdjBqOTAyc2FoWjdZWitHRExnWk9qTnRVanJIcTBtV2pZcFo4L1pLRXhr?= =?utf-8?B?aWF5ZVRDVjRWWmg4RXRmVkRXQkt5M1k1dDNQdjlIQzJteXorYWl3RnJOMnlK?= =?utf-8?B?bmd4cUh4UHIrN0w4SlpFc29sbVE3SmZhbFU2OTI5RlUrQjAzUDR2dVBIc09O?= =?utf-8?B?M0RFYmlpckloejgrT095elJnPT0=?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1033; 6:VKRlPtro1Ui3qkQUqq61wAch1Nv7kHzRpMYUZoD8L66xOJz1ckGrC9LvWYEr7oymAlbyVTA4/cw9HB58Eh5jyCHMCDjTYpoRqN1Yh+o6TAuewsiGEwYT1OiO+IV9WDUNFrr/X6d1SsyhrbXXKyxPUx1YCE2l3hzx6wZJa1y3YY5FD97Qb4shBlKxSY6VHAWfDksH2432hjr/WIa8u1IhAFqtpXYyD9C9YXyAm5MuRfo4H+JBGx1mSKMPFRj5GDE6+iyz1Jijk2zuTHbjWEx/CtQmWmuBO9VMNaPNLWZiLHaOnGXViNjeCz0ha+ZIAfz7lpYSexYTiTV9vIks+tJ+FNV1FAtqgywCuj+7+998mJC/Pi120u5g1gLO7x0qZBczCf7+K/ayE2wM3akyxu51gA==; 5:KH2guWMOLBiabHnU4cbl93IQlBi1WeQBwCksgWpCafm6zzokQy25SMniSh5bMwowltgYHlZXWUaScgVaGmohNMsULYpCRWEdHA8ch136K81tw7c+sOe1w/4AJVqapJXMySuJOF025afHeNVHS5DO+g==; 24:2J/h/bhSDEJVwiQtnsweNIqyORSnE4KTcMWmZmco7JXTfbprGc1HRuH8JfEElcO9avZLxReeVR39APRFHpD4Fs71dMC+hrK/mv/r4CTGZBw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1033; 7:XhiGvkfpUJ71qhRMW+TB8sTRulVMmGj6MDqMzAJSuQ0q5hh0nXtK9LFVNsGTu06pejmHdSLfak0cXR8957nwN5ZG7Qx9Ys5Q72P2EWHaU5vL6EDuqwX/S1dn68WjhubLEgdbSPxX8peRteAN52m0qlbXfMpWNWef8izR3fVWZu7poKB3r0Bg183f59wjuPYmO+hJkcB/uZghF7GqYCxrY+tDfSyjeH5cnrm18DmkTCVlemoqk97g0ivPAYhdOM6Vmb77aVti3mG51IIaA8NJTee8vCXf59WRIazWWsXKlaJH1cjtDBfWm91+bmvhJwzyWOwpcbd35SmY33j9XRk79g== X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2017 15:16:30.1246 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0101MB1033 Archived-At: Subject: Re: [Dots] DOTS Telemetry X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 16 Feb 2017 15:16:35 -0000 On 16 Feb 2017, at 22:14, Teague, Nik wrote: > I don’t believe telemetry should be included in the base DOTS > signals and as its frequently called out to be optional I would simply > look to utilize extensions or vendor specific fields. +1 ----------------------------------- Roland Dobbins From nobody Thu Feb 16 08:10:33 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C114B1294B5 for ; Thu, 16 Feb 2017 08:10:31 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 FH0wpbLfqP3m for ; Thu, 16 Feb 2017 08:10:29 -0800 (PST) Received: from mailout1.radware.com (mailout1.radware.com [192.115.180.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091BF1293F9 for ; Thu, 16 Feb 2017 08:10:27 -0800 (PST) Received: from ILMB1.corp.radware.com ([169.254.1.237]) by ILCAS2.corp.radware.com ([176.200.120.122]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 18:10:25 +0200 From: Ehud Doron To: "Mortensen, Andrew" , "Tirumaleswar Reddy (tireddy)" Thread-Topic: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . Thread-Index: AdKCER/slEaaT/pbTQCa8ffUgEh/YgEvK4mgADZPhAAAMOw/gA== Date: Thu, 16 Feb 2017 16:10:25 +0000 Message-ID: References: <331a77a5ec074db69cf2bc2715a7645e@XCH-RCD-017.cisco.com> <6601F335-76C8-4DDA-8DAA-A88A9F7F2E3B@arbor.net> In-Reply-To: <6601F335-76C8-4DDA-8DAA-A88A9F7F2E3B@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [176.200.121.207] x-tm-as-product-ver: SMEX-11.0.0.4179-8.100.1062-22888.007 x-tm-as-result: No--33.175000-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E58182C4A35A8E498E553AD3D33FA001011718C5DAILMB1corpradw_" MIME-Version: 1.0 Archived-At: Cc: dots Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 16 Feb 2017 16:10:32 -0000 --_000_E58182C4A35A8E498E553AD3D33FA001011718C5DAILMB1corpradw_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kcmV3DQoNClRoYW5rcyBmb3IgeW91ciBmZWVkYmFjay4NCg0KTGV0IG1lIHBsZWFzZSBjbGFy aWZpZWQgbXkgcG9pbnRzIGhlcmUuIEkgdG90YWxseSBhZ3JlZSB3aXRoIHlvdXIgc3RhbmRwb2lu dHMgdGhhdCB0aGUgc2lnbmFsIGNoYW5uZWwgcmVzdHJpY3Rpb25zIHNob3VsZCBub3QgYmUgdmlv bGF0ZWQgYnkgYW55IGtpbmQgb2YgaW5mb3JtYXRpb24uDQoNCk15IHZpZXcgaXMgdGhhdCBkcmFm dC1kb3Jvbi1kb3RzLXRlbGVtZXRyeS0wMCBzaG91bGQgbm90IGRpY3RhdGUgaG93IGFueSBraW5k IG9mICB0ZWxlbWV0cnkgaW5mb3JtYXRpb24gc2hvdWxkIGJlIHNpZ25hbGVkIGFuZCBpbiB3aGlj aCBjaGFubmVsLiBJIGJlbGlldmUgdGhhdCB0aGlzIHNob3VsZCBub3QgYmUgZGlzY3Vzc2VkIGFz IHBhcnQgb2YgdGhlIERPVFMgVGVsZW1ldHJ5IHdvcmssIGJ1dCByYXRoZXIgYXMgcGFydCBvZiB0 aGUgcmVsZXZhbnQgcHJvdG9jb2wgc3RhbmRhcmQgd29yay4gSSBzZWUgdGhlIERPVFMgVGVsZW1l dHJ5IGRyYWZ0IGFzIHRoZSBET1RTIGtub3dsZWRnZWJhc2UgZm9yIHRoZSB0ZWxlbWV0cnkgbWF0 dGVyLiBBcyBwYXJ0IGRvIHRoZSBET1RTIHByb3RvY29sIHdvcmssIGl0IHNob3VsZCBiZSBjb25z aWRlcmVkIHdoYXQgY2FuIChvciBjYW7igJl0KSBiZSBzaWduYWxlZCwgb24gd2hpY2ggY2hhbm5l bCBhbmQgaG93Lg0KDQpNb3Jlb3Zlciwgd2UgY2FuIHRoaW5rIG9uIHNtYWxsIGJhc2ljIHNldCBv ZiDigJxlc3NlbnRpYWzigJ0gdGVsZW1ldHJ5IGNvbnZleWVkIHVzaW5nIHRoZSBzaWduYWxpbmcg Y2hhbm5lbCwgZS5nLiBhdHRhY2sgQlcsIFBQUywgZHJvcHBlZCB0cmFmZmljIG9yIHNpbWlsYXIg KHNlZSBUaXJ14oCZcyBzdWdnZXN0aW9ucyBpbiBoaXMgZW1haWwpLCBhbmQgdGhlIHJlc3Qgb2Yg aW5mb3JtYXRpb24gdXNpbmcgdGhlIGRhdGEgY2hhbm5lbC4NCg0KTmV2ZXJ0aGVsZXNzLCB0aGUg V0cgbmVlZCB0byBmaXJzdCBnZXQgdG8gYW4gYWdyZWVtZW50IGFib3V0IHRoZSBraW5kIG9mIHRl bGVtZXRyeSByZXF1aXJlZCB0byBmYWNpbGl0YXRlIGEgdmlhYmxlIGFudGktRG9TIHNlcnZpY2Ug KHNlZSBwbGVhc2UgdGhlIGVtYWlsIHRoZSBET1RTIHRlbGVtZXRyeSBhdXRob3JzIHNlbnQgdG8g dGhlIFdHKS4NCg0KSSB0aGluayB0aGlzIGlzIGEgdmVyeSBnb29kIGRpc2N1c3Npb24uDQoNClRo YW5rcywgRWh1ZA0KDQoNCkZyb206IE1vcnRlbnNlbiwgQW5kcmV3IFttYWlsdG86YW1vcnRlbnNl bkBhcmJvci5uZXRdDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE1LCAyMDE3IDY6MTggUE0N ClRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIDx0aXJlZGR5QGNpc2NvLmNvbT4NCkNj OiBFaHVkIERvcm9uIDxFaHVkREBSYWR3YXJlLmNvbT47IGRvdHMgPGRvdHNAaWV0Zi5vcmc+OyBE YXZpZCBBdml2IDxEYXZpZEFAUmFkd2FyZS5jb20+DQpTdWJqZWN0OiBSZTogW0RvdHNdIENvbW1l bnRzIGFuZCBmZWVkYmFja3Mgb24gZHJhZnQtcmVkZHktZG90cy1zaWduYWwtY2hhbm5lbC0wNyBh bmQgZHJhZnQtcmVkZHktZG90cy1kYXRhLWNoYW5uZWwtMDMgLg0KDQoNCk9uIEZlYiAxNCwgMjAx NywgYXQgOTo1MyBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBjaXNj by5jb208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPj4gd3JvdGU6DQoNCkhpIEVodWQsDQoNClRo YW5rcyBmb3IgdGhlIGRldGFpbGVkIHJldmlldywgUGxlYXNlIHNlZSBpbmxpbmUgKEkgd2lsbCBy ZXNwb25kIHRvIGRhdGEgY2hhbm5lbCBjb21tZW50cyBpbiBhIHNlcGFyYXRlIG1haWwpDQoNCkZy b206IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFaHVk IERvcm9uDQog4oCmIHNuaXAuLi4NCjYuICAgICAgIFBhZ2UgMTQgZmlndXJlIDU6IFRoZSBtaXRp Z2F0aW9uIHJlcXVlc3QgYXR0cmlidXRlcyBhcmUgcmlnaHQgYnV0IG5vdCBlbm91Z2guIE5lZWQg dG8gYWRkIG1vcmUgdGVsZW1ldHJ5IGluZm8gYWJvdXQgdGhlIGFjdHVhbCBhdHRhY2sgdGhhdCBp dCBpcyByZXF1aXJlZCB0byBtaXRpZ2F0ZSwgbmVlZCB0byBjb25zaWRlciBhdHRyaWJ1dGVzIGlu IGRyYWZ0LWRvcm9uLWRvdHMtdGVsZW1ldHJ5LTAwIGFzIHBhcnQgb2YgdGhlIGRpc2N1c3Npb24g aW4gdGhlIFdHLg0KDQpbVFJdIFllcywgSSBwbGFuIHRvIHVwZGF0ZSB0aGUgZHJhZnQgd2l0aCB0 ZWxlbWV0cnkgaW5mbyBiYXNlZCBvbiBvdXRjb21lIG9mIGRyYWZ0LWRvcm9uLWRvdHMtdGVsZW1l dHJ5LTAwLg0KDQpJIHVuZGVyc3RhbmQgbmVlZCBmb3IgYW5kIHN1cHBvcnQgdGhlIGVmZm9ydCB0 byBlbnN1cmUgdGVsZW1ldHJ5IGJldHdlZW4gRE9UUyBhZ2VudHMsIGJ1dCBJ4oCZbSBza2VwdGlj YWwgYWJvdXQgdGhlIHN1Z2dlc3Rpb24gdGhhdCB0aGUgcmlnaHQgcGxhY2UgZm9yIGl0IGlzIGlu IHRoZSBzaWduYWwgY2hhbm5lbC4gVGhlIHNpZ25hbCBjaGFubmVsIHJlcXVpcmVtZW50cyBhcmUg cmVzdHJpY3RpdmUgYnkgZGVzaWduIChzdWItTVRVIG1lc3NhZ2Ugc2l6ZSwgZXhwZWN0YXRpb24g b2YgcGFja2V0IGxvc3MsIGV0Yy4pLCBzdWdnZXN0aW5nIGluY29tcGF0aWJpbGl0eSB3aXRoIHRo ZSBwcm9wb3NlZCB0ZWxlbWV0cnkgYXR0cmlidXRlcyBpbiBkcmFmdC1kb3Jvbi1kb3RzLXRlbGVt ZXRyeS0wMC4gQW1vbmcgb3RoZXIgdGhpbmdzLCB0aGF0IGRyYWZ0IHByb3Bvc2VzIENFRiBmb3Ig YXR0YWNrIGRldGFpbHMgYW5kIHRoZSBpbmNsdXNpb24gb2YgYSBsaXN0IG9mIGF1dGhlbnRpY2F0 ZWQgc291cmNlcy4gVGlydeKAmXMgc2lnbmFsIGNoYW5uZWwgZHJhZnQgc3VnZ2VzdHMgYXNzdW1p bmcgYW4gTVRVIG9mIG5vIG1vcmUgdGhhbiAxMjgwIGJ5dGVzIGlmIHRoZSBQTVRVIGlzIG5vdCBr bm93biwgYW5kIGNvbmNsdWRlcyB0aGF0IGEgbWF4aW11bSBkYXRhZ3JhbSBzaXplIG9mIDU3NiBi eXRlcyB3aXRoIGEgRE9UUyBwYXlsb2FkIHNpemUgb2YgNTAwIGJ5dGVzIGlzIGJlc3QgdG8gZW5z dXJlIHRoZSBzaWduYWwgY2hhbm5lbCB3aWxsIG5vdCBiZSBmcmFnbWVudGVkLg0KDQpBbGwgb2Yg dGhhdCBpcyB0byBzYXkgSSBkaXNhZ3JlZSB3aXRoIHRoZSBzdWdnZXN0aW9uIHRoYXQgdGhlIHNp Z25hbCBjaGFubmVsIHNob3VsZCBiZSB0aGUgcHJpbWFyeSB2ZWhpY2xlIGZvciB0ZWxlbWV0cnku IEZlZWRiYWNrLCB5ZXM7IHVuc2NvcGVkIHRlbGVtZXRyeSwgbm8uIEhvdyBkbyB3ZSBkZXRlcm1p bmUgaWYgdGhlcmXigJlzIGVub3VnaCB0ZWxlbWV0cnk/IEhvdyBtdWNoIHRlbGVtZXRyeSBkb2Vz IHZlbmRvciBBIHJlcXVpcmUgdG8gZnVuY3Rpb24gYXMgYSBET1RTIHNlcnZlciBvciBjbGllbnQ/ IEhvdyBtdWNoIHRlbGVtZXRyeSBsb3NzIGNhbiBlaXRoZXIgYWdlbnQgKGFuZCB2ZW5kb3IgaW1w bGVtZW50YXRpb24pIHdpdGhzdGFuZD8NCg0KSW4gY29udHJhc3QsIHRoZSBkYXRhIGNoYW5uZWwg c2VlbXMgbGlrZSB0aGUgaWRlYWwgcGxhY2UgZm9yIHRoZSBzb3J0IG9mIHRlbGVtZXRyeSBkZXNj cmliZWQgaW4gZHJhZnQtZG9yb24tZG90cy10ZWxlbWV0cnktMDAuIFRoZXJlIGFyZSBubyByZXN0 cmljdGl2ZSBzaXplIG9yIHBhY2tldCBsb3NzIGhhbmRsaW5nIHJlcXVpcmVtZW50cywgYW5kIFJF U1RDT05GIHN1cHBvcnRzIGV2ZW50IHN0cmVhbXMgdGhhdCB3b3VsZCBzZWVtIHRvIGZpdCB0aGUg bmVlZCBxdWl0ZSB3ZWxsLg0KDQphbmRyZXcNCg== --_000_E58182C4A35A8E498E553AD3D33FA001011718C5DAILMB1corpradw_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVy dGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kcmV3PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgZmVlZGJhY2suPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5MZXQgbWUgcGxlYXNlIGNsYXJpZmll ZCBteSBwb2ludHMgaGVyZS4gSSB0b3RhbGx5IGFncmVlIHdpdGggeW91ciBzdGFuZHBvaW50cyB0 aGF0IHRoZSBzaWduYWwgY2hhbm5lbCByZXN0cmljdGlvbnMgc2hvdWxkIG5vdCBiZSB2aW9sYXRl ZCBieSBhbnkga2luZCBvZiBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPk15IHZpZXcgaXMgdGhhdCBkcmFmdC1kb3Jvbi1kb3RzLXRlbGVtZXRy eS0wMCBzaG91bGQgbm90IGRpY3RhdGUgaG93IGFueSBraW5kIG9mICZuYnNwO3RlbGVtZXRyeSBp bmZvcm1hdGlvbiBzaG91bGQgYmUgc2lnbmFsZWQgYW5kIGluIHdoaWNoIGNoYW5uZWwuIEkgYmVs aWV2ZSB0aGF0DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPnRoaXMgc2hvdWxk IG5vdCBiZSBkaXNjdXNzZWQgYXMgcGFydCBvZiB0aGUgRE9UUyBUZWxlbWV0cnkgd29yaywgYnV0 IHJhdGhlciBhcyBwYXJ0IG9mIHRoZSByZWxldmFudCBwcm90b2NvbCBzdGFuZGFyZCB3b3JrLiBJ IHNlZSB0aGUgRE9UUyBUZWxlbWV0cnkgZHJhZnQgYXMgdGhlIERPVFMga25vd2xlZGdlYmFzZSBm b3IgdGhlIHRlbGVtZXRyeSBtYXR0ZXIuIEFzIHBhcnQgZG8gdGhlDQogRE9UUyBwcm90b2NvbCB3 b3JrLCBpdCBzaG91bGQgYmUgY29uc2lkZXJlZCB3aGF0IGNhbiAob3IgY2Fu4oCZdCkgYmUgc2ln bmFsZWQsIG9uIHdoaWNoIGNoYW5uZWwgYW5kIGhvdy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+TW9yZW92ZXIsIHdlIGNhbiB0aGluayBvbiBzbWFsbCBiYXNpYyBzZXQg b2Yg4oCcZXNzZW50aWFs4oCdIHRlbGVtZXRyeSBjb252ZXllZCB1c2luZyB0aGUgc2lnbmFsaW5n IGNoYW5uZWwsIGUuZy4gYXR0YWNrIEJXLCBQUFMsIGRyb3BwZWQgdHJhZmZpYyBvciBzaW1pbGFy IChzZWUgVGlydeKAmXMgc3VnZ2VzdGlvbnMgaW4gaGlzIGVtYWlsKSwgYW5kIHRoZSByZXN0IG9m DQogaW5mb3JtYXRpb24gdXNpbmcgdGhlIGRhdGEgY2hhbm5lbC4gJm5ic3A7Jm5ic3A7Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5OZXZlcnRoZWxlc3MsIHRoZSBX RyBuZWVkIHRvIGZpcnN0IGdldCB0byBhbiBhZ3JlZW1lbnQgYWJvdXQgdGhlIGtpbmQgb2YgdGVs ZW1ldHJ5IHJlcXVpcmVkIHRvIGZhY2lsaXRhdGUgYSB2aWFibGUgYW50aS1Eb1Mgc2VydmljZSAo c2VlIHBsZWFzZSB0aGUgZW1haWwgdGhlIERPVFMgdGVsZW1ldHJ5IGF1dGhvcnMgc2VudCB0byB0 aGUgV0cpLg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkkgdGhpbmsgdGhpcyBpcyBhIHZlcnkgZ29vZCBkaXNjdXNzaW9uLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MsIEVodWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNb3J0 ZW5zZW4sIEFuZHJldyBbbWFpbHRvOmFtb3J0ZW5zZW5AYXJib3IubmV0XQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMTUsIDIwMTcgNjoxOCBQTTxicj4NCjxiPlRvOjwv Yj4gVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSAmbHQ7dGlyZWRkeUBjaXNjby5jb20mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBFaHVkIERvcm9uICZsdDtFaHVkREBSYWR3YXJlLmNvbSZndDs7IGRv dHMgJmx0O2RvdHNAaWV0Zi5vcmcmZ3Q7OyBEYXZpZCBBdml2ICZsdDtEYXZpZEFAUmFkd2FyZS5j b20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRG90c10gQ29tbWVudHMgYW5kIGZlZWRi YWNrcyBvbiBkcmFmdC1yZWRkeS1kb3RzLXNpZ25hbC1jaGFubmVsLTA3IGFuZCBkcmFmdC1yZWRk eS1kb3RzLWRhdGEtY2hhbm5lbC0wMyAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gRmViIDE0LCAyMDE3LCBhdCA5OjUzIEFNLCBUaXJ1bWFsZXN3 YXIgUmVkZHkgKHRpcmVkZHkpICZsdDs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5jb20i PnRpcmVkZHlAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkg RWh1ZCw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIGRldGFpbGVkIHJldmlldywgUGxlYXNlIHNlZSBp bmxpbmUgKEkgd2lsbCByZXNwb25kIHRvIGRhdGEgY2hhbm5lbCBjb21tZW50cyBpbiBhIHNlcGFy YXRlIG1haWwpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RG90cw0KIFs8YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHls ZT0iY29sb3I6Izk1NEY3MiI+bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+ XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBC ZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9iPkVodWQgRG9yb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDvi gKYgc25pcC4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjYuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5QYWdlDQogMTQgZmlndXJlIDU6IFRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QgYXR0cmlidXRlcyBh cmUgcmlnaHQgYnV0IG5vdCBlbm91Z2guIE5lZWQgdG8gYWRkIG1vcmUgdGVsZW1ldHJ5IGluZm8g YWJvdXQgdGhlIGFjdHVhbCBhdHRhY2sgdGhhdCBpdCBpcyByZXF1aXJlZCB0byBtaXRpZ2F0ZSwg bmVlZCB0byBjb25zaWRlciBhdHRyaWJ1dGVzIGluPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5kcmFmdC1k b3Jvbi1kb3RzLXRlbGVtZXRyeS0wMDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+YXMNCiBwYXJ0IG9mIHRoZSBkaXNjdXNzaW9uIGluIHRoZSBX Ry48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5bVFJdIFllcywgSSBwbGFuIHRvIHVwZGF0ZSB0aGUgZHJhZnQgd2l0aCB0ZWxlbWV0cnkg aW5mbyBiYXNlZCBvbiBvdXRjb21lIG9mIGRyYWZ0LWRvcm9uLWRvdHMtdGVsZW1ldHJ5LTAwLjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgdW5kZXJzdGFuZCBuZWVkIGZvciBhbmQgc3VwcG9ydCB0aGUgZWZmb3J0IHRvIGVuc3VyZSB0 ZWxlbWV0cnkgYmV0d2VlbiBET1RTIGFnZW50cywgYnV0IEnigJltIHNrZXB0aWNhbCBhYm91dCB0 aGUgc3VnZ2VzdGlvbiB0aGF0IHRoZSByaWdodCBwbGFjZSBmb3IgaXQgaXMgaW4gdGhlIHNpZ25h bCBjaGFubmVsLiBUaGUgc2lnbmFsIGNoYW5uZWwgcmVxdWlyZW1lbnRzIGFyZSByZXN0cmljdGl2 ZSBieSBkZXNpZ24NCiAoc3ViLU1UVSBtZXNzYWdlIHNpemUsIGV4cGVjdGF0aW9uIG9mIHBhY2tl dCBsb3NzLCBldGMuKSwgc3VnZ2VzdGluZyBpbmNvbXBhdGliaWxpdHkgd2l0aCB0aGUgcHJvcG9z ZWQgdGVsZW1ldHJ5IGF0dHJpYnV0ZXMgaW4gZHJhZnQtZG9yb24tZG90cy10ZWxlbWV0cnktMDAu IEFtb25nIG90aGVyIHRoaW5ncywgdGhhdCBkcmFmdCBwcm9wb3NlcyBDRUYgZm9yIGF0dGFjayBk ZXRhaWxzIGFuZCB0aGUgaW5jbHVzaW9uIG9mIGEgbGlzdCBvZiBhdXRoZW50aWNhdGVkDQogc291 cmNlcy4gVGlydeKAmXMgc2lnbmFsIGNoYW5uZWwgZHJhZnQgc3VnZ2VzdHMgYXNzdW1pbmcgYW4g TVRVIG9mIG5vIG1vcmUgdGhhbiAxMjgwIGJ5dGVzIGlmIHRoZSBQTVRVIGlzIG5vdCBrbm93biwg YW5kIGNvbmNsdWRlcyB0aGF0IGEgbWF4aW11bSBkYXRhZ3JhbSBzaXplIG9mIDU3NiBieXRlcyB3 aXRoIGEgRE9UUyBwYXlsb2FkIHNpemUgb2YgNTAwIGJ5dGVzIGlzIGJlc3QgdG8gZW5zdXJlIHRo ZSBzaWduYWwgY2hhbm5lbCB3aWxsIG5vdCBiZQ0KIGZyYWdtZW50ZWQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbCBvZiB0aGF0IGlzIHRv IHNheSBJIGRpc2FncmVlIHdpdGggdGhlIHN1Z2dlc3Rpb24gdGhhdCB0aGUgc2lnbmFsIGNoYW5u ZWwgc2hvdWxkIGJlIHRoZSBwcmltYXJ5IHZlaGljbGUgZm9yIHRlbGVtZXRyeS4gRmVlZGJhY2ss IHllczsgdW5zY29wZWQgdGVsZW1ldHJ5LCBuby4gSG93IGRvIHdlIGRldGVybWluZSBpZiB0aGVy ZeKAmXMgZW5vdWdoIHRlbGVtZXRyeT8gSG93IG11Y2ggdGVsZW1ldHJ5IGRvZXMgdmVuZG9yDQog QSByZXF1aXJlIHRvIGZ1bmN0aW9uIGFzIGEgRE9UUyBzZXJ2ZXIgb3IgY2xpZW50PyBIb3cgbXVj aCB0ZWxlbWV0cnkgbG9zcyBjYW4gZWl0aGVyIGFnZW50IChhbmQgdmVuZG9yIGltcGxlbWVudGF0 aW9uKSB3aXRoc3RhbmQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkluIGNvbnRyYXN0LCB0aGUgZGF0YSBjaGFubmVsIHNlZW1zIGxpa2UgdGhl IGlkZWFsIHBsYWNlIGZvciB0aGUgc29ydCBvZiB0ZWxlbWV0cnkgZGVzY3JpYmVkIGluIGRyYWZ0 LWRvcm9uLWRvdHMtdGVsZW1ldHJ5LTAwLiBUaGVyZSBhcmUgbm8gcmVzdHJpY3RpdmUgc2l6ZSBv ciBwYWNrZXQgbG9zcyBoYW5kbGluZyByZXF1aXJlbWVudHMsIGFuZCBSRVNUQ09ORiBzdXBwb3J0 cyBldmVudCBzdHJlYW1zIHRoYXQNCiB3b3VsZCBzZWVtIHRvIGZpdCB0aGUgbmVlZCBxdWl0ZSB3 ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5hbmRyZXc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_E58182C4A35A8E498E553AD3D33FA001011718C5DAILMB1corpradw_-- From nobody Thu Feb 16 08:58:15 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24391295DA for ; Thu, 16 Feb 2017 08:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 zo5lUfoeMKTu for ; Thu, 16 Feb 2017 08:58:12 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91598129637 for ; Thu, 16 Feb 2017 08:58:12 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v1GGw8BG006588; Thu, 16 Feb 2017 11:58:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1487264288; bh=IDfrQeR2NSLOqH8cfD6DKG3SUtwa8IC/9DUvr7bpGbY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version:Sender:Reply-To:Cc; b=E5jFfSTrui2GBnDH3SJrnzKykLFrG38DPnoW1zV81QUcZbMv69IV/wpoxMxhycUZr v+cJrAs5hDKyslkLa1hwE6eH1cIaOLZ9TuDzEWkBbKyUJsfuGVu7PmFVJpSqEj1dfD PZSf94nHnUmNdRcUKCNGb9FgDJRG1oGbfcBAs6J0= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v1GGw6kk020125; Thu, 16 Feb 2017 11:58:06 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 11:58:06 -0500 From: "Roman D. Danyliw" To: "Mortensen, Andrew" , "dots@ietf.org" Thread-Topic: [Dots] Fwd: DDoS Open Threat Signaling (dots) WG Virtual Meeting: 2017-02-22 Thread-Index: AQHSiBnZgUl1NhlouESco0oLaBu/iqFr14wQ Date: Thu, 16 Feb 2017 16:58:06 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104F033F1@marathon> References: <148720345553.31523.5616766500805936690.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC0104F033F1marathon_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Fwd: DDoS Open Threat Signaling (dots) WG Virtual Meeting: 2017-02-22 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 16 Feb 2017 16:58:15 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC0104F033F1marathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agreed. I hope we can do it in in less but we need to bring the matter to c= losure. Based on additional agenda item requests, this topic has been cons= olidated into a general discussion slot. See the updated agenda (now forma= lly uploaded) at: https://datatracker.ietf.org/doc/agenda-interim-2017-dots-01-dots-01/ Roman From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Mortensen, Andrew Sent: Thursday, February 16, 2017 12:59 AM To: dots@ietf.org Subject: [Dots] Fwd: DDoS Open Threat Signaling (dots) WG Virtual Meeting: = 2017-02-22 Does 15 minutes on RESTCONF seem excessive to anyone else? Begin forwarded message: From: IESG Secretary > Subject: [Dots] DDoS Open Threat Signaling (dots) WG Virtual Meeting: 2017-= 02-22 Date: February 15, 2017 at 7:04:15 PM EST To: "IETF-Announce" > Cc: dots@ietf.org ... - Discussion: Use of RESTCONF (15 min) --_000_359EC4B99E040048A7131E0F4E113AFC0104F033F1marathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agreed. I hope we can do it in in les= s but we need to bring the matter to closure.  Based on additional age= nda item requests, this topic has been consolidated into a general discussion slot.  See the updated agenda (now formally= uploaded) at:

 

https://datatracker.ietf.org/d= oc/agenda-interim-2017-dots-01-dots-01/

 

Roman

 

 

 

From: Dots [mailto:dots-bounces@ietf= .org] On Behalf Of Mortensen, Andrew
Sent: Thursday, February 16, 2017 12:59 AM
To: dots@ietf.org
Subject: [Dots] Fwd: DDoS Open Threat Signaling (dots) WG Virtual Me= eting: 2017-02-22

 

Does 15 minutes on RESTCONF seem excessive to anyone= else?



Begin forwarded message:

 

From: IESG Secre= tary <iesg-secretary@ietf.org= >

Subject: [Dots] DDoS Open Threat Signaling (dots) WG Virtual Me= eting: 2017-02-22

Date: February 1= 5, 2017 at 7:04:15 PM EST

To: "IETF= -Announce" <ietf-announce= @ietf.org>

 

...
  - Discussion: Use of RESTCONF (15 min)

 

--_000_359EC4B99E040048A7131E0F4E113AFC0104F033F1marathon_-- From nobody Thu Feb 16 13:44:08 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4672B1296CC for ; Thu, 16 Feb 2017 13:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 mGaxAH66B4_D for ; Thu, 16 Feb 2017 13:44:01 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943FB1296C9 for ; Thu, 16 Feb 2017 13:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7804; q=dns/txt; s=iport; t=1487281441; x=1488491041; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=09oTkBzuoXLVWxQP2N78kOUL4XwzCMHB31pUYVE/ST0=; b=GyHZLqDVwrmKtonpXLqVoFUiayEBi/AgFER4aQqMY9lCuQtEFfCtv8nt ar40S5XE7816KWqoTdV90o/hkx98QuQTiJXeAzNRrfzz4YfzFw06oBNiI lctIVH2t0YekBpKCb26at7ZqA80eKhxpj6yRIBas/6adtb60iDPnEf/CU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMDgCAHKZY/5JdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgygpYQOBBoNZnBeQB4UsggwfAQqFeAKCEEAXAQIBAQEBAQEBYii?= =?us-ascii?q?EcAEBAQMBAQEhSxALCxgVFQICJzAGAQwGAgEBiVsFCA6wVYIlK4sqAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARoFhkyCBYJqhCUZVYJHgl8FkESLO5IXij+GR5MYIAE2gQA?= =?us-ascii?q?0HRU9hmIiNYo3AQEB?= X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208,217";a="384770153" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 21:44:00 +0000 Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v1GLhxt7008589; Thu, 16 Feb 2017 21:44:00 GMT To: "Teague, Nik" , Ehud Doron , "'dots'" References: From: Flemming Andreasen Message-ID: <8e4b578e-c96e-60f1-244a-f648067dcad5@cisco.com> Date: Thu, 16 Feb 2017 16:43:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1C094AA6E24D1A49F9D6D9D1" Archived-At: Subject: Re: [Dots] DOTS Telemetry X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 16 Feb 2017 21:44:07 -0000 This is a multi-part message in MIME format. --------------1C094AA6E24D1A49F9D6D9D1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/16/17 10:14 AM, Teague, Nik wrote: > On 16/02/2017, 14:43, "Dots on behalf of Ehud Doron" wrote: > > As part of the WG effort to define the DOTS baseline features (the DOTS MVPs), we would like to get the WG feedbacks about the abovementioned telemetry categories and also about other possible suggested telemetry categories. We encourage group members from both vendors and service providers to bring-in their valuable feedbacks and needs on this matter. > > I wouldn’t classify telemetry as an optional feature as necessary or relevant to MVP – Telemetry has varying degrees of usefulness depending upon specific architectures or vendor implementations and in many cases, may be covered by other mechanisms such as flow collection etc. to the point of being redundant all together. I don’t believe telemetry should be included in the base DOTS signals and as its frequently called out to be optional I would simply look to utilize extensions or vendor specific fields. I agree for a very basic definition of MVP, but we clearly have several requirements that go beyond MVP (e.g. most of the data-channel definition), so where do we draw the line (this is the recurring mandatory/optional/extension classification of requirements, that we have yet to complete) ? Looking at requirements that (potentially) pertain more directly to telemetry, we have for example: OP-007 Mitigation Efficacy: When a mitigation request by a DOTS client is active, DOTS clients SHOULD transmit a metric of perceived mitigation efficacy to the DOTS server, per "Automatic or Operator-Assisted CPE or PE Mitigators Request Upstream DDoS Mitigation Services" in [I-D.ietf-dots-use-cases]. DOTS servers MAY use the efficacy metric to adjust countermeasures activated on a mitigator on behalf of a DOTS client. We also have the following as part of OP-004 (for the reverse direction): A server MAY refuse to engage in coordinated attack response with a client. To make the status of a client's request clear, the server MUST indicate in server signals whether client-initiated mitigation is active. When a client-initiated mitigation is active, and threat handling details such as mitigation scope and statistics are available to the server, the server SHOULD include those details in server signals sent to the client. DOTS clients SHOULD take mitigation statistics into account when deciding whether to request the DOTS server cease mitigation. What are your thoughts on satisfying those requirements ? Thanks -- Flemming > Thanks, > > -Nik > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------1C094AA6E24D1A49F9D6D9D1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 2/16/17 10:14 AM, Teague, Nik wrote:
On 16/02/2017, 14:43, "Dots on behalf of Ehud Doron" <dots-bounces@ietf.org on behalf of EhudD@Radware.com> wrote:

    As part of the WG effort to define the DOTS baseline features (the DOTS MVPs), we would like to get the WG feedbacks about the abovementioned telemetry categories and also about other possible suggested telemetry categories. We encourage group members from both vendors and service providers to bring-in their valuable feedbacks and needs on this matter.

I wouldn’t classify telemetry as an optional feature as necessary or relevant to MVP – Telemetry has varying degrees of usefulness depending upon specific architectures or vendor implementations and in many cases, may be covered by other mechanisms such as flow collection etc. to the point of being redundant all together.  I don’t believe telemetry should be included in the base DOTS signals and as its frequently called out to be optional I would simply look to utilize extensions or vendor specific fields.
I agree for a very basic definition of MVP, but we clearly have several requirements that go beyond MVP (e.g. most of the data-channel definition), so where do we draw the line (this is the recurring mandatory/optional/extension classification of requirements, that we have yet to complete) ?

Looking at requirements that (potentially) pertain more directly to telemetry, we have for example:

   OP-007  Mitigation Efficacy: When a mitigation request by a DOTS
      client is active, DOTS clients SHOULD transmit a metric of
      perceived mitigation efficacy to the DOTS server, per "Automatic
      or Operator-Assisted CPE or PE Mitigators Request Upstream DDoS
      Mitigation Services" in [I-D.ietf-dots-use-cases].  DOTS servers
      MAY use the efficacy metric to adjust countermeasures activated on
      a mitigator on behalf of a DOTS client.

We also have the following as part of OP-004 (for the reverse direction):

      A server MAY refuse to engage in coordinated attack response with
      a client.  To make the status of a client's request clear, the
      server MUST indicate in server signals whether client-initiated
      mitigation is active.  When a client-initiated mitigation is
      active, and threat handling details such as mitigation scope and
      statistics are available to the server, the server SHOULD include
      those details in server signals sent to the client.  DOTS clients
      SHOULD take mitigation statistics into account when deciding
      whether to request the DOTS server cease mitigation.

What are your thoughts on satisfying those requirements ?

Thanks

-- Flemming 

Thanks,

-Nik

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

--------------1C094AA6E24D1A49F9D6D9D1-- From nobody Thu Feb 16 14:43:10 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A4B126B6D for ; Thu, 16 Feb 2017 14:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com 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 LIC3MXJYM1nY for ; Thu, 16 Feb 2017 14:43:06 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0096.outbound.protection.outlook.com [104.47.37.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC6E124281 for ; Thu, 16 Feb 2017 14:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=63j9YEeAZBCOgamkitAoqH/8I66YBP9KEFRuswz3TRs=; b=KqAhM44fHrw/WJKXUopHhLZnDbapcExmQT5xqDY5BlFXjSpc1yN8chTbZVHaNRUrS7bRZppIIr96cK8E+7hWgRB/MGAzVZw3iWFef0rm3RtT8Ez4u8TRBIMympOsvpWZ5qAe19CtZOoJfD+5g9lDBr/lU//N79eQdGDNlug44rA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; Received: from [172.19.254.104] (49.228.118.161) by CY1PR0101MB1036.prod.exchangelabs.com (10.160.225.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 16 Feb 2017 22:43:04 +0000 From: Roland Dobbins To: dots Date: Fri, 17 Feb 2017 05:42:48 +0700 Message-ID: In-Reply-To: <8e4b578e-c96e-60f1-244a-f648067dcad5@cisco.com> References: <8e4b578e-c96e-60f1-244a-f648067dcad5@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5344) X-Originating-IP: [49.228.118.161] X-ClientProxiedBy: SG2PR01CA0033.apcprd01.prod.exchangelabs.com (10.165.9.171) To CY1PR0101MB1036.prod.exchangelabs.com (10.160.225.140) X-MS-Office365-Filtering-Correlation-Id: 881ec184-0561-49a1-608c-08d456bd2bc1 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0101MB1036; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 3:5w2SpXTlWlSYSEc09moXBeloj4JHF0fFsEGw/7TVZa9XHF2EsatTPPMLEBv8CtH+COFk0hKPyu+Xy4EW2OEDaEeexFFhhQBB9r3O3C9LvJAiuOiEMe6kopoKYSf9O8qYadyxF4BwNed8O+9IeFicDnps0MkkOdOIe1boCrfwhjamYb3peEbJBp8lHRRXtlfXAOXW4bhh9IEKcQ9fGFQrhMa6H6T1yPd9ZATPqBJ2mtCFj1yXjg51wyArYzeYdSzqdjhXM1M1L/nYSooh0p9SEQ==; 25:rYdPJyF2uG3uH5+ts6d6SHFweCqrn1x6/BZyiVUXzloVCA5ImQpIQ4J4RPtdyYbk77Lujf7hpG01aE5KAi7b15TUjhAdslC3wAJTG9cWwbHggc4/ddClbk7QTiz/eHsmFNYbvtal4visFpII1d52bj0bqfw6NKmIEKW3QAcuC7aZN0tZQwRCemb4fB9Fct3e+wg6btRNBN3oIOSCvo3gG7+aqH/rAADdNbQJj0Ywu29Ilu+sdxbph7XJW2uYlVgwAtyg7lL6tdZhAefIvuB8sTVNg9ZR2q07D91joo/4fR0g4soz1uAh/dQLy1RjLRLIDsSBIJ6cNM9d5wYi84ZJKwUU/UORtEuIXw9I18pMd6CtMXKmBnhYKjiuyNro2Q3LdaSitEXWUk7RQ1Wtg+6cJDe6oCGT7EeD+Prd+PuhQlq7WpEEl8Jq80ej0xGLlBWY5d97LddbGUELSM74sWuqRA== X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 31:dUgcyQoWFZdd1UkpKlpuI1C7+Rh3jbnHy7PC3DYcIwQCvrYMdzLQISUUxs4Lgp0WSzoES9XP9VBCNEdcyEZSbPN/CqMwQAUC5kYQzZKhzVbTr6IXoBOzLm57YLfk4u7ELzl4WbN3P8V7cloHJa04MZ+lgAChedenHv13SOd5bBAcR7y2Yf843h4hTAyULdoxip4rwdAShu8Nteq+hbYimFd/YhU14ypzz2kFp6yzqUNmA6fTEwD0YcRg4PusaSp/yYEliq5XQs9yoCXe5l8EKA==; 20:R7q+L4siuArNOqE1ZSZkhDPg/isRfbd/D8pY94DFqp+xgD/P/KDx3CTrRusizvnxTaE8Gd9cUmDM6FewgEFI+rPLH8fzYgwaueMQF7Q/t7hOT+cMCDZcsySpdleBqMUCgRK5RAfzg2n25Fx8aLMCHqcZJTsOLtP9V16cuHX8MehmCoo7Fb3GScdqUfuhW5AtXy+nn6RlhSc912LrcLfdZuXmuYFXXD/c/WlNLxEZB0hWpci984UT5ogmpapWd29Bdh2U4pPXflvpej1kXNVGFnmu+T2rOLqTgn4EKo1K11FTgjUAN4u9vUOxJqMe+GnT+w54Y+U6THHk+q3rEl+Yclmv1+SRvfRDsu2s0FZCxNlYKJloFfx+WQlhUwsOk0OVhCkTVMI9/lDZZLZyQqccKra2kDvFxKvH6mkvBuqjrqvEfCoDC+op8gErsjnrDUPzdR2un7ecjtXc5pEnc/M1SqVK6g9IqNNYiCtsNvyJJg1xo8i9vOgkdg9KV78UxojC X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(6072148); SRVR:CY1PR0101MB1036; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0101MB1036; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 4:QOa7KUFXLYvLyslfKVW2eJme/tmYu32gR5QnkWlqWQ3f2dJunakgsjEDbrkJ8TAk8jtt182S4eEo5Ah1UAHTW5dsNx7zlMZyg3MTvDMQmFox0G6W4eSbZYzfEYCP6Ls8JibCF5sDv0yLTmIyDosZcSGQ6egxb3LSNnVBfQ5utB3X3II3AK2DPoIH9u4gip9Be1nYta7y53QUkDoeXg1b8LKujkr+rkNe4wus7SmgDds07pRCaHUJMaAt1q4T2zQEVe7PoF0h7faAVPdCIGDVMapDX+Mtzt8DNxbbjtD+Kyg/3s7WzjAQTgOdLz3WkGkpDBiKjkuj79HsTr5oE167OnDXXJHjYsnLq9KBFuIVjm2q5SBWA8Kc5IPBz2nsPADGKnj8Ghvg94mxC8Ce5xmy3n8808M4d6E4D+tVRc2IM5k0CvRGqSnOw7HcYCE/jT7nua1Kk+CkpsEWmmaNokxVmyhTSIGu35ZWSWjGSFC2Rlw4iuEtiB0sguI6KDMbIpWYkFJU6qYHSCB/Dhth4TH35O/W1X5S1kNqgdgTNI6xC0JD6q8tMpwpz8PrQxZ/Y/QoHnQ2OFVXCVPrmjNtqFqmkw== X-Forefront-PRVS: 0220D4B98D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(39450400003)(52054003)(24454002)(199003)(189002)(36756003)(68736007)(101416001)(92566002)(7736002)(8676002)(97736004)(81166006)(50226002)(305945005)(81156014)(82746002)(189998001)(83716003)(76176999)(5003940100001)(50986999)(53936002)(33656002)(5660300001)(42186005)(86362001)(6916009)(90366009)(6666003)(6486002)(6246003)(25786008)(2950100002)(77096006)(229853002)(3846002)(6116002)(105586002)(450100001)(389900003)(38730400002)(106356001)(66066001)(110136004)(47776003)(50466002)(2906002)(53546006)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0101MB1036; H:[172.19.254.104]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0101MB1036; 23:hesGgjE6DByVFjdAbsQcP2bpSUcyX02hg6519S+?= =?us-ascii?Q?jNKYP1ga4YLz2NbFXC/TQ+AgCzBo8nDTMBHVechCjnsZW8clPDWU1NU1pVUP?= =?us-ascii?Q?yn+7Q2w44i3vchBIUNco6IB1PoYKUvmMdohh37IrQwGy/XDw6uOZEqNPct7W?= =?us-ascii?Q?QJpwJnDqQDFrPoloCtx5tmyAiJOW7MXXYJ25Kde09dOHKTWgq3QdNGhuiMuT?= =?us-ascii?Q?OfFZjpfwl+FugjvmlYdG0M8IzUFKHRP9SmNjLOhYDjvsNaCnAVoZPglg4HcR?= =?us-ascii?Q?RsxnAeH41BTV99nhDv8U5zewoRBH53O/wM4mSFBCZlUgdG6NWRB3EJwwlMpN?= =?us-ascii?Q?tbY0gca91y8p5nLxGJBsqhjq4YtOk40fBh8wBnKU1WY2FW2iNH4+zGMfz/G3?= =?us-ascii?Q?wwMsUDl50W7Un/mRw5cBkkTfbAvu2GdHru6N4y1bUzNKM+qbsen9XJEhsgeL?= =?us-ascii?Q?jKnRwuaU1lAGG++441mhJj65B+RoOk2kqvQ8N+ZUOu/ZXi4JTnGUx6oiyp3t?= =?us-ascii?Q?eV2wZLmlnZc2Jd/4RFFtmPm7mCePnEsJFM1cBnG9+0+lVj7A+UtQU4vc2urb?= =?us-ascii?Q?nPESyUqLWu/GpVt9JNYt53AlYSJ5kUqlX9pmX1fIjsfNRYvuCLxPzWMok2n6?= =?us-ascii?Q?aUaQqy/gzuk/2gplKlw29TI7v/gtBpCkRXU8ZEnEEz0GF5qvbakKzryIzjiY?= =?us-ascii?Q?VZATnfYT6cXuIy+feUU2ddoD93hh8z5iDcMjauk5wXSEqWVgoXPQBwZIocWv?= =?us-ascii?Q?C4ZDo4q7M4wzxwe7XaKcTiL5zFs2TUt+ayQI76++ahInIQKwsGPTM3uki9VW?= =?us-ascii?Q?/XIuelQ/HUlC2QGkcyx9OW3vw7/vQzhODeDqZ5ycxceu3LCR4xqsAzomMGX8?= =?us-ascii?Q?xmTdUV7xaQiO1KnpOvjPq0I8Ke2FSa85K8eHRNN3D7CHI71JUlJbRbAA4NK5?= =?us-ascii?Q?uOgGeSGf5VUwYF1hPbxuzE4ab2IBPyLMXF87BNteqfI5tNMYxmor9xclw3Rw?= =?us-ascii?Q?Ju2TF9nv0hDvXnroGBxmg+Mi24LPfYpOwKIe1AkuDverrz/BM8uaDtZaOUmT?= =?us-ascii?Q?GEw5sm+J5ptoDpZrapEEb4Wu0KSMLepM6+oabKr/Pg3PWIhRzXk7r334+0Fg?= =?us-ascii?Q?+gJmu035Ul4J96dUKPEYTHB28h+oOckZCnY6FbkFoWgaGMDtV+aPT4+ZNrY2?= =?us-ascii?Q?RisqnFcbiSeuaEzMag+9cu03KbJRAoBdy6bH/YRa2CEYDakU3unu9w2uRedL?= =?us-ascii?Q?KgHlTobRGYKEzL0u4ySPkQS3fZ4ZmZDGg23J5e5uk/Oi/TVTsq8qI6ZBfIhN?= =?us-ascii?Q?I3w=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 6:31PVwZwZC2avhZFoXAGF6x6B8hKXQYPkMmrfIpmTaBLjutPMVloFB70st4tkeXf+ITxT9ZR3miM5JXRoo9UmUtNzYmOQwPSVnpl8w+3fXiG6584I7ok22OFpUuC/O0MzUjMA9D4blQcOth+bHPvqeUyy3DQ22DN/gIssCiWIhKynSs82CPTBN1QC2hTNM7dn+yUyFoVjZVTCx7f3lsX0GELUIKbO9EJxyc9mnSekApdz6dIh58sjER15VI2M/MvCqdLGH2KXZGQ2he0oA5CWvHvgJt8J1IM+6L6Wzhk+LdkLvSbQP5WZ5LGH0GIzc8wyRbgNdpBOPbWkUKz3neDn8hqbxG0B9n/cvQBpt2JZ5+g26khT8DYtugBFmLZP5sqFpOruIBqmVWXWoPI0c8fXzQ==; 5:QAnk+rDD49xT9PnAbyHUhu38oYTZ0ekSpg4Bh7UnXdekzSeXr3xxSFaOTbLRLFI24gSA7BX64KZCzA3Rof26gqk1vHruDAMbnYTRoZExfl5RxnTUG9yFlsSvnGKMkHOyUADxyH4dXlHH1VJ8ooobEA==; 24:PazM+1YvCq53xqlKUTQL0Cmynw3VZJEyp0b+E+Evfp1+FoYlHrnf3GTlP2BxoU3ulRtyRQ2AJUefUSo99P/wZf3E8/VaL7Umy1261qylwQc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 7:+WQsTExagMfAw61Trf1XBkfrKZXAFzEgnDrVf54+bELqaC9EZEBa0qeB9SbKOmAL9cHHWUdHVqGA+qvUTrrORYHuS69Iya/9qW9XBBwc0WtQXUFjpsqqvBwxyk5X8JeWmElMKoMD8ij8nRIurUrl9YDlXV2zT6Oav4JJqko1R31l6op0cmSB/z6G4haWs/p/DPttiqI/YhTkJGMpPWBaHl0Vvz+CnM5JpM27RoyCaMaMSHZ/j3r2UBFXTMbWGanJxCMzKGR1CuDUVKRyBF5HNslIPlhh7092yXODVnqedRvc40dkcjHp8LGbofUs1gS9TWOQJct0bVV9zz6WD0jzHg== X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2017 22:43:04.1757 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0101MB1036 Archived-At: Subject: Re: [Dots] DOTS Telemetry X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 16 Feb 2017 22:43:08 -0000 On 17 Feb 2017, at 4:43, Flemming Andreasen wrote: > What are your thoughts on satisfying those requirements ? Those things aren't 'telemetry' in the sense it's used in the DDoS mitigation space. It's status information. And it ought to be standardized as part of this WG's efforts at some point, IMHO. However, that's more of a forward-looking recommendation. Quantifying mitigation efficacy is something that we want to see included within the scope of DDoS mitigation solut to ionsthe degree that it's practical to do so, but is not a capability we really see today. It's largely done out-of-band to date. So, this shouldn't be a MVP requirement, because it's forward-looking guidance. We want to a) encourage its implementation and adoption and b) be ready to accommodate it once it's implemented and adopted. ----------------------------------- Roland Dobbins From nobody Thu Feb 16 20:36:58 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE0112997E for ; Thu, 16 Feb 2017 20:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 cvYeSvg9QFWA for ; Thu, 16 Feb 2017 20:36:52 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 32E211294A3 for ; Thu, 16 Feb 2017 20:36:45 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id D913925F6EA; Fri, 17 Feb 2017 13:36:43 +0900 (JST) Received: from DHCP-190.nttv6.jp (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id AB992759011; Fri, 17 Feb 2017 13:36:43 +0900 (JST) To: "Tirumaleswar Reddy (tireddy)" , Ehud Doron , 'dots' References: <73716c67d08b4de5b8e6df1394da199f@XCH-RCD-017.cisco.com> <0dd8cd77a95f45aabcc64e30ef0bcd06@XCH-RCD-017.cisco.com> From: kaname nishizuka Message-ID: <2c809b8c-d7f7-ea38-d0eb-02a78fca4a15@nttv6.jp> Date: Fri, 17 Feb 2017 13:36:43 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <0dd8cd77a95f45aabcc64e30ef0bcd06@XCH-RCD-017.cisco.com> Content-Type: multipart/alternative; boundary="------------4C92A9D875EBDF3A8CB1907C" Archived-At: Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 17 Feb 2017 04:36:57 -0000 This is a multi-part message in MIME format. --------------4C92A9D875EBDF3A8CB1907C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Tiru, Thanks for your response and clarifications. Please see my response inline[kaname2] On 2017/02/16 21:09, Tirumaleswar Reddy (tireddy) wrote: > > Hi Kaname, > > Please see inline [TR2] > > *From:*kaname nishizuka [mailto:kaname@nttv6.jp] > *Sent:* Thursday, February 16, 2017 1:22 PM > *To:* Tirumaleswar Reddy (tireddy) ; Ehud Doron ; 'dots' > *Cc:* David Aviv > *Subject:* Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Hi Tiru, > > please see inline. > > On 2017/02/16 13:18, Tirumaleswar Reddy (tireddy) wrote: > > Hi Kaname, > > Please see inline [TR] for responses > > *From:*kaname nishizuka [mailto:kaname@nttv6.jp] > *Sent:* Wednesday, February 15, 2017 11:27 AM > *To:* Tirumaleswar Reddy (tireddy) ; Ehud Doron ; 'dots' > *Cc:* David Aviv > *Subject:* Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Hi Tiru, > > I really appreciate your time and effort. > Please see my comments on the drafts. > > # draft-reddy-dots-signal-channel-07 > > 1. [General] I believe that DOTS request should not be another tool of blocking other one's traffic. Is there any validation mechanism of requested target-ips, target-ports and target-protocols? Even If it is out side of the DOTS specification, how about returning 4.xx codes when the requested target-* is not a property of the organization. > > [TR] The validation scope is outside the scope of this draft, 4.xx error code is already used in the draft to identity invalid requests. > > [kaname]OK, understood. > > > 2. [page14] Does one DOTS client and DOTS server peer have only one signal channel and one data channel? (I'm thinking about a namespace of the "alias-name") > > [TR] No, DOTS peers can have more than one signal and data channel but the recommendation is to use only signal and data channel to reduce connection setup delay. > > [kaname] If there are more than one signal and data channel, how can they coupled? > > [TR2] DOTS client authenticate to the DOTS server (see https://tools.ietf.org/html/draft-reddy-dots-signal-channel-07#page-35), the DOTS server knows the DOTS client identity to couple the signal and data channel sessions. > > [kaname2] I see. Could I confirm that my understanding is right. The signal and data channel sessions are coupled based on the client certification. So, the same client certification should be used among (D)TLS in signal channel session and TLS in data channel session. If so, how about writing it explicitly in the main part of [draft-reddy-dots-data-channel-04]? Now, mutual authentication is described only in 6. Security Considerations. > One DOTS server will accommodate more than one DOTS client, so is there any way to know which data channel is belong to which signal channel? Source IP? > I recommend to use only one signal and data channel per one DOTS peer, too. > > If their are multiple data channels, "DOTS signal" in Fig.5 should specify according data channel when it refers to "alias-names" of the identifiers. > > [TR] I did not get the comment. > > [kaname] Different DOTS clients will be belonging to different customers(organizations). > So I think there is a chance of requesting the same "alias-names" from different customers. > Then, will the DOTS server reject conflicted "alias-names" between different customers? > > [TR] No. > > or keep them with prefixes like customerA: and customerB: internally? Also, customerA should not use an alias-name of customerB. How can the DOTS server check that. > > [TR2] Same response as above. Aliases do not have global scope, they are specific to a DOTS client (DOTS server knows the DOTS client identity). > [kaname2]OK, I understood. > > 3. [Page21] How about adding status of "mitigation delete is in progress" like status:1. > Here is a life cycle of a mitigation in our environment. Activating and deleting of mitigation could take several seconds (or minutes). > POST. > - activating(status=1) > STATUS AFTER ACTIVATED > - attack mitigated (status=2) > - attack stopped (status=3) > - attack exceeded capability(status=4) > DELETE > - deleting(status=5?) > - deleted(RETURN 4.04) > > > [TR] Delete is a confirmable message, DOTS server will send an ACK to acknowledge the receipt of the message to avoid retransmissions from the DOTS client. After the mitigation request is successfully deleted, DOTS server returns 2.02 (Deleted) response code, thus conveying the transient status in this case is not necessary. > > [kaname] As I noted, deleting of mitigation could take several seconds (or minutes) in real-life. > > [TR2] Yes, but the DOTS server immediately sends a ACK (acknowledging the receipt of the DELETE message), thus the DOTS client knows the server has received the Delete request and is processing the request. After deleting the mitigation (may take several seconds), server sends 2.02 (Delete) response code. I don’t see a problem. > > -Tiru > > [kaname2] The same story could be applied to the status:1 (Attack mitigation is in progress) thank you, Kaname > > If the DOTS client retrieve the status while that time, getting "deleting status", not "2.02 status", will help operators. > > 4. [Page25] 5.4 b) I couldn't find "retransmission timeout value" attribute in the later figures. Is that equivalent to "ack-timeout"? > > [TR] The initial retransmission timeout value is based on the ack-timeout (see https://tools.ietf.org/html/rfc7252#section-4.2). > > [kaname] Thank you, I found the reference. > > 5. [Page27] "policy-id" in "signal-config" is different from "policy-id" in "mitigation-scole". How about using "session-id" in this case? > > [TR] Policy-id is a unique identifier identifying the signal channel session configuration request. > > [kaname] "policy-id" in Fig.9 and Fig.15 are totally different. I've got confused when reading the draft because they have the same name. > > # draft-reddy-dots-data-channel-03 > > 1. [General] Data channel doesn't have heartbeat mechanism. I guess the reason is that there is heartbeat mechanism in the signal channel so it is enough, is that right? > > [TR] No, the heartbeat mechanism in signal channel cannot be used for data channel. DOTS signal channel is using the “CoAP ping mechanism”. For data channel, TLS heartbeat can be used. I have updated draft. > > [kaname] OK. I'll see updated draft. > > > 2. [related to Ehud's question 8] I-D.ietf-netmod-acl-model says "ACL is an ordered list of Access List Entries (ACE)" but I couldn't find a text about how they are ordered. Should we have a operation of changing the order of ACEs installed in a DOTS server? > > [TR] PUT can be used by the DOTS client to re-order/update/modify the list of ACE conveyed to the DOTS server. Updated draft to discuss about PUT. > > [kaname] OK. I'll see updated draft. > > > thank you, > kaname > > -Tiru > > > thank you, > Kaname > > On 2017/02/14 23:58, Tirumaleswar Reddy (tireddy) wrote: > > Hi Ehud, > > Please see inline for responses to comments on draft-reddy-dots-data-channel-03 > > *From:* Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Ehud Doron > *Sent:* Wednesday, February 8, 2017 7:21 PM > *To:* 'dots' > *Cc:* David Aviv > *Subject:* [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Tiru and authors Hi > > Attached please find my comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > *_Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel draft-reddy-dots-signal-channel-07_* > > 1.General comment: For all signals in the draft, need to add means to allow vendor specific attributes as part of all signals transactions > > 2.General comment: Just for clarity, need to explicitly mention on each figure when it is an example or the actual API > > 3.Page 3 second paragraph : DOTS should not be limited to “enterprise network” only > > . > > 4.Page 4 chapter 4: The overall context of the “happy eyeballs” and its relations (or coexistence) to CoAP is not clear. > > 5.Page 7 chapter 5.2.1: The need for YANG model cannot be understood from text. What are the needs for YANG models? What is the relation to the JSONs in the other chapters in the draft > > 6.Page 14 figure 5: The mitigation request attributes are right but not enough. Need to add more telemetry info about the actual attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. > > 7.Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested > > 8.Page 15 last paragraph: Not sure that target port or target protocol can define a protected entity. IP, FQDN, URI are the only “stand alone” attributes , port and protocol are companion attributes. See also figure 9 . > > 9.Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is related ? “policy ID” ? I think the best is have another attribute to define the priority of mitigation requests > > 10.Page 21 table: The return status are right but not enough. Need to add more telemetry info about the actual mitigation going on (how much traffic was mitigated) and the attack that are mitigated, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. > > 11.Page 15 : Need to find the way to bind the target-ip*s* with target-port-range*s* and target-protocol*s*, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth. > > 12.Page 21 last paragraph: This is very strong point. > > 13.Page 25 : Regarding attack status, same point about telemetry. > > 14.Page 25 chapter 5.4: I believe it can valuable to add a short high level description about the proposed API flow, same as you did for 5.3 . > > 15.Page 27: The necessity of policy_id here is not clear enough, are the “Signal Channel Session Configuration” define only “single” DOTS session or the entire communication between Client and Server for several DOTS request for mitigation? > > 16.Page 27: Not sure about the reason for “at least one of the attributes heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor MUST be present.” Also consider to change to “presented”. > > 17.Page 30 chapter 5.5: Need to specify the overall scenario, in reaction to which signal (or API transaction POST of Mitigation Request , unidirectional notification from Server as describes in page 23 in page 21 ?) the redirection occurred ? > > *_Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel draft-reddy-dots-data-channel-03_* > > 1.General comment: For all signal in the draft, need to add means to allow vendor specific attributes as part of all signals transactions > > [TR] Agreed, updated draft. > > 2.Page 5 second paragraph: Why it is required to configure the DOTS signal channel session ? > > [TR] No need to configure DOTS signal channel session, fixed second paragraph. > > 3.Page 8 chapter 3.2.1 : Any reason for not including these identifiers in the DOTS signal channel draft ? > > [TR] Identifiers created for resources in DOTS data channel are used in DOTS signal channel to request DDOS mitigation. It’s the responsibility of DOTS data channel to create aliases for resources (see https://tools.ietf.org/html/draft-ietf-dots-requirements-03#section-2.3). The main reason for DOTS signal channel not creating identifiers is the message size may exceed Path MTU. > > 4.Page 9 figure 3 : Need to find the way to bind the target-ip*s* with target-port-range*s* and target-protocol*s*, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth. > > [TR] Yes, it is possible; create different aliases for IP1 TCP port 80 and IP2 UDP port 53. > > 5.Page 13 chapter 3.3 : Need to emphasize that filtering rules are relevant for both client server direct communication and through a DOTS gateway. The chapter is a bit confusing. > > [TR] Thanks, fixed chapter 3.3. > > 6.Page 14 chapter 3.3 : I am missing the white-list installation, is it by using the permit action ? > > [TR] Yes, “permit” action is used for white-list installation; it’s defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 > > 7.Page 15 figure 8: For DDoS it is highly valuable to have rate limit as an action. Consider adding such action (if already defined need to explain where and how). > > [TR] Done, updated draft. > > 8.Page 15 figure 8: Need to consider adding priority to an ACL to support cases when several filtering rules are conflicting. > > [TR] We are not doing anything new to ACL, ACL an ordered list of Access List Entries (ACE) based on priority. > > 9.Page 15 : The action field cannot be optional attribute. > > [TR] As per https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09if the action field not specified then “deny” is the default action. > > 10.Page 16 chapter 3.3.3: Need to add more telemetry info about the actual traffic that was blocked (bps, pps and so on), but as I believe this might be another issue… > > [TR] Chapter 3.3.3 only discusses telemetry details of number of matches for the installed filtering rules. > > -Tiru > > Thanks, > > ** > > *Ehud Doron *| Senior Architect, *Radware* CTO office | *M:*+972-54-7575503 | *T:* +972-72-3917120 > > > > > > _______________________________________________ > > 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 --------------4C92A9D875EBDF3A8CB1907C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Tiru,

Thanks for your response and clarifications.
Please see my response inline[kaname2]


On 2017/02/16 21:09, Tirumaleswar Reddy (tireddy) wrote:

Hi Kaname,

 

Please see inline [TR2]

 

From: kaname nishizuka [mailto:kaname@nttv6.jp]
Sent: Thursday, February 16, 2017 1:22 PM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; Ehud Doron <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru,

please see inline.

On 2017/02/16 13:18, Tirumaleswar Reddy (tireddy) wrote:

Hi Kaname,

 

Please see inline [TR] for responses

 

From: kaname nishizuka [mailto:kaname@nttv6.jp]
Sent: Wednesday, February 15, 2017 11:27 AM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; Ehud Doron <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru,

I really appreciate your time and effort.
Please see my comments on the drafts.

# draft-reddy-dots-signal-channel-07

1. [General] I believe that DOTS request should not be another tool of blocking other one's traffic. Is there any validation mechanism of requested target-ips, target-ports and target-protocols? Even If it is out side of the DOTS specification, how about returning 4.xx codes when the requested target-* is not a property of the organization.

[TR] The validation scope is outside the scope of this draft, 4.xx error code is already used in the draft to identity invalid requests.

[kaname]OK, understood.


2. [page14] Does one DOTS client and DOTS server peer have only one signal channel and one data channel? (I'm thinking about a namespace of the "alias-name")

[TR] No, DOTS peers can have more than one signal and data channel but the recommendation is to use only signal and data channel to reduce connection setup delay.

[kaname] If there are more than one signal and data channel, how can they coupled?

 

[TR2] DOTS client authenticate to the DOTS server (see https://tools.ietf.org/html/draft-reddy-dots-signal-channel-07#page-35), the DOTS server knows the DOTS client identity to couple the signal and data channel sessions.


[kaname2] I see. Could I confirm that my understanding is right.
The signal and data channel sessions are coupled based on the client certification. So, the same client certification should be used among (D)TLS in signal channel session and TLS in data channel session.
If so, how about writing it explicitly in the main part of [draft-reddy-dots-data-channel-04]? Now, mutual authentication is described only in 6. Security Considerations.


One DOTS server will accommodate more than one DOTS client, so is there any way to know which data channel is belong to which signal channel? Source IP?
I recommend to use only one signal and data channel per one DOTS peer, too.

 

 

If their are multiple data channels, "DOTS signal" in Fig.5 should specify according data channel when it refers to "alias-names" of the identifiers.

[TR] I did not get the comment.

[kaname] Different DOTS clients will be belonging to different customers(organizations).
So I think there is a chance of requesting the same "alias-names" from different customers.
Then, will the DOTS server reject conflicted "alias-names" between different customers?

 

[TR] No.

 

or keep them with prefixes like customerA:<same-alias-name> and customerB:<same-alias-name> internally? Also, customerA should not use an alias-name of customerB. How can the DOTS server check that.

 

[TR2] Same response as above. Aliases do not have global scope, they are specific to a DOTS client (DOTS server knows the DOTS client identity).

[kaname2]OK, I understood.


3. [Page21] How about adding status of "mitigation delete is in progress" like status:1.
    Here is a life cycle of a mitigation in our environment. Activating and deleting of mitigation could take several seconds (or minutes).
    POST.
     - activating(status=1)
    STATUS AFTER ACTIVATED
     - attack mitigated (status=2)
     - attack stopped (status=3)
     - attack exceeded capability(status=4)
    DELETE
     - deleting(status=5?)
     - deleted(RETURN 4.04)


[TR] Delete is a confirmable message, DOTS server will send an ACK to acknowledge the receipt of the message to avoid retransmissions from the DOTS client. After the mitigation request is successfully deleted, DOTS server returns 2.02 (Deleted) response code, thus conveying the transient status in this case is not necessary.

[kaname] As I noted, deleting of mitigation could take several seconds (or minutes) in real-life.

 

[TR2] Yes, but the DOTS server immediately sends a ACK (acknowledging the receipt of the DELETE message), thus the DOTS client knows the server has received the Delete request and is processing the request. After deleting the mitigation (may take several seconds), server sends 2.02 (Delete) response code. I don’t see a problem.

 

-Tiru


[kaname2] The same story could be applied to the status:1 (Attack mitigation is in progress)


thank you,
Kaname

If the DOTS client retrieve the status while that time, getting "deleting status", not "2.02 status", will help operators.

4. [Page25] 5.4 b) I couldn't find "retransmission timeout value" attribute in the later figures. Is that equivalent to "ack-timeout"?

[TR] The initial retransmission timeout value is based on the ack-timeout (see https://tools.ietf.org/html/rfc7252#section-4.2).

[kaname] Thank you, I found the reference.

5. [Page27] "policy-id" in "signal-config" is different from "policy-id" in "mitigation-scole". How about using "session-id" in this case?

[TR] Policy-id is a unique identifier identifying the signal channel session configuration request.

[kaname] "policy-id" in Fig.9 and Fig.15 are totally different. I've got confused when reading the draft because they have the same name.

 

# draft-reddy-dots-data-channel-03

1. [General] Data channel doesn't have heartbeat mechanism. I guess the reason is that there is heartbeat mechanism in the signal channel so it is enough, is that right?

[TR] No, the heartbeat mechanism in signal channel cannot be used for data channel. DOTS signal channel is using the “CoAP ping mechanism”. For data channel, TLS heartbeat can be used. I have updated draft.

[kaname] OK. I'll see updated draft.


2. [related to Ehud's question 8] I-D.ietf-netmod-acl-model says "ACL is an ordered list of Access List Entries (ACE)" but I couldn't find a text about how they are ordered. Should we have a operation of changing the order of ACEs installed in a DOTS server?

[TR] PUT can be used by the DOTS client to re-order/update/modify the list of ACE conveyed to the DOTS server. Updated draft to discuss about PUT.

[kaname] OK. I'll see updated draft.


thank you,
kaname

-Tiru


thank you,
Kaname

On 2017/02/14 23:58, Tirumaleswar Reddy (tireddy) wrote:

Hi Ehud,

 

Please see inline for responses to comments on draft-reddy-dots-data-channel-03

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru and authors Hi

 

Attached please find my comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

 

Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy-dots-signal-channel-07

 

1.       General comment: For all signals in the draft, need to add means to allow vendor specific attributes as part of all signals transactions

 

2.       General comment: Just for clarity, need to explicitly mention on each figure when it is an example or the actual API

 

3.       Page 3 second paragraph : DOTS should not be limited to “enterprise network” only

.

4.       Page 4 chapter 4: The overall context of the “happy eyeballs” and its relations (or coexistence) to CoAP is not clear.  

 

5.       Page 7 chapter 5.2.1: The need for YANG model cannot be understood from text. What are the needs for YANG models? What is the relation to the JSONs in the other chapters in the draft

 

6.       Page 14 figure 5: The mitigation request attributes are right but not enough. Need to add more telemetry info about the actual attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG.

 

7.       Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested

 

8.       Page 15 last paragraph: Not sure that target port or target protocol can define a protected entity. IP, FQDN, URI are the only “stand alone” attributes , port and protocol are companion attributes. See also figure 9 .

 

9.       Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is related ?   “policy ID” ? I think the best is have another attribute to define the priority of mitigation requests

 

10.   Page 21 table: The return status are right but not enough. Need to add more telemetry info about the actual mitigation going on (how much traffic was mitigated) and the attack that are mitigated, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG.

 

11.   Page 15 : Need to find the way to bind the target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

12.   Page 21 last paragraph: This is very strong point.

 

13.   Page 25 : Regarding attack status, same point about telemetry.

 

14.   Page 25 chapter 5.4: I believe it can valuable to add a short high level description about the proposed API flow, same as you did for 5.3 .

 

15.   Page 27:  The necessity of policy_id here is not clear enough, are the “Signal Channel Session Configuration” define only “single” DOTS session or the entire communication between Client and Server for several DOTS request for mitigation?

 

16.   Page 27: Not sure about the reason for “at least one of the attributes heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor MUST be present.” Also consider to change to “presented”.

 

17.   Page 30 chapter 5.5: Need to specify the overall scenario, in reaction to which signal (or API transaction POST of Mitigation Request , unidirectional notification from Server as describes in page 23 in page 21 ?) the  redirection occurred ?

 

 

Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-dots-data-channel-03

 

1.       General comment: For all signal in the draft, need to add means to allow vendor specific attributes as part of all signals transactions

 

[TR] Agreed, updated draft.

 

2.       Page 5 second paragraph: Why it is required to configure the DOTS signal channel session ?  

 

[TR] No need to configure DOTS signal channel session, fixed second paragraph.

 

3.       Page 8 chapter 3.2.1 : Any reason for not including these identifiers in the DOTS signal channel draft ?

 

[TR] Identifiers created for resources in DOTS data channel are used in DOTS signal channel to request DDOS mitigation. It’s the responsibility of DOTS data channel to create aliases for resources (see https://tools.ietf.org/html/draft-ietf-dots-requirements-03#section-2.3). The main reason for DOTS signal channel not creating identifiers is the message size may exceed Path MTU.

 

 

4.       Page 9 figure 3 : Need to find the way to bind the target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

[TR] Yes, it is possible; create different aliases for IP1 TCP port 80 and IP2 UDP port 53.

 

 

5.       Page 13 chapter 3.3 : Need to emphasize that filtering rules are relevant for both client server direct communication and through a DOTS gateway. The chapter is a bit confusing.

 

[TR] Thanks, fixed chapter 3.3.

 

 

6.       Page 14 chapter 3.3 : I am missing the white-list installation, is it by using the permit action ?

 

[TR]  Yes, “permit” action is used for white-list installation; it’s defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09

 

 

7.       Page 15 figure 8: For DDoS it is highly valuable to have rate limit as an action. Consider adding such action (if already defined need to explain where and how).

 

[TR] Done, updated draft.

 

8.       Page 15 figure 8: Need to consider adding priority to an ACL to support cases when several filtering rules are conflicting.

 

[TR]  We are not doing anything new to ACL, ACL an ordered list of Access List Entries (ACE) based on priority.

 

 

9.       Page 15 : The action field cannot be optional attribute.

 

[TR] As per https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 if the action field not specified then “deny” is the default action.

 

10.   Page 16 chapter 3.3.3: Need to add more telemetry info about the actual traffic that was blocked (bps, pps and so on), but as I believe this might be another issue…

 

[TR] Chapter 3.3.3 only discusses telemetry details of number of matches for the installed filtering rules.

 

-Tiru

 

Thanks,

 

Ehud Doron |  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

 





_______________________________________________
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

--------------4C92A9D875EBDF3A8CB1907C-- From nobody Thu Feb 16 21:40:24 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B311293FB for ; Thu, 16 Feb 2017 21:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com 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 wOAfhedL5D18 for ; Thu, 16 Feb 2017 21:40:20 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0138.outbound.protection.outlook.com [104.47.34.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF375128AB0 for ; Thu, 16 Feb 2017 21:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vjTvHgz636TLAUD8T7Eum7XJCIHFj9zQQcF/UxLbRXI=; b=d9eIwDGD7S3ATvzkXoG9c3NSIEqSBZeD7ofvqw8b9Fad+HbWrNa11LF8Wq1cCpHvObBAv+N0UkUnt3u9CgdQipF5modZt1wIx4fwnyOJUIS417j9WwfqF0wq3SeH8Q7/xQAFiO7/4KXUNHZbWvw9JV9IPsYeB7YvQNLddJrZhS8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; Received: from [172.19.254.104] (49.228.118.161) by BN3PR0101MB1026.prod.exchangelabs.com (10.160.182.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Fri, 17 Feb 2017 05:40:16 +0000 From: Roland Dobbins To: dots Date: Fri, 17 Feb 2017 12:39:54 +0700 Message-ID: <2F10CDEC-D9B7-44BE-8B89-E2713FC97D81@arbor.net> In-Reply-To: References: <331a77a5ec074db69cf2bc2715a7645e@XCH-RCD-017.cisco.com> <6601F335-76C8-4DDA-8DAA-A88A9F7F2E3B@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5344) X-Originating-IP: [49.228.118.161] X-ClientProxiedBy: SG2PR01CA0010.apcprd01.prod.exchangelabs.com (10.165.9.148) To BN3PR0101MB1026.prod.exchangelabs.com (10.160.182.155) X-MS-Office365-Filtering-Correlation-Id: 02699f8c-9547-4494-efaa-08d456f77477 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0101MB1026; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1026; 3:kNRl2iFE/GR6Y2/18Yy2f4sx2gAkAGNGsSFtD9HeWkKCQAGh8TvG2zGoi90fnXOf1NuCfue8Qc+KZAU/mMR2NPMUbU0AqLJ3j/1oCzngOQfDFDaxrP8kfH0fje6wTCYmWxrTi4ZJfrmVhKT71/tyl3u6K8b5p/Dq10q+GFowKjAbnk7bJq+hLerL3CaAC/lkdNXzy6N8oePDFZwfaGoXu8akiAYkHP0u7y2DT0+Z4VFaivgYTwquXwod+BCqQkglEfKvkW1a2IVnQ4Qp0oZRYQ==; 25:qjrIVE2FjXeNdNXgMIGxZWsFU3hdTjcXZAiUktaafL5xlmgiO25g2OelTRGQ3AzMz1NRaBuzT3f/LhVCupIxPG+k1xiSWMXdh+IBgr78Y8iK7ZP4PhLRyi+0150dhlS+wayX3/AdYatF3E5Y6N3/H6GSj+7MZ+3ol7yaWpvgzpLhs8y5P24OuyW3g4Y2p8uTWXl/MRTalQGbt1EMCqiWAC5l0IlZljpmJ9htsU3p8eBDn4y9EIvpHga8qHTwuDWUdxFjzaIGqxBja4Or4C/a3Xe1dc1bzEelDXqaN/Zl3qWOls8MuhSNLtyoChmPvE6Gifnh9xs07jrlk+r3aJppojYAKwZMxCvU5UntOItO7UoHJoENwhfEbYX58E6HQHPbGfF1kitnyY0TDs/2mCO7ukUmrq7e0dz/UlFsadYX3P+j6PFcr2+5rEj065Tlxb72HOvk7vfCLYAwToY1EMu5jQ== X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1026; 31:c8f3TTaEGnwNt5522133CyRin+1LJhwtUD0um2IzucA0vmTC8nLQ0ZzAsy11guczxgZZr85WtFWuquLHDGCLrzyTHaSEFv3IdMeDXPPbMb6KrrMJWp+eZMRfw2PWTDByg4g1DV6Jg2LWVXXVUq3j6yPFDeqHdINrgwHuwGdAFSuLMwMZETfUonQ3wtXO8FpUIFgNeMiw+ZWzJA4Z20P9icr6dhMjDzhQ8BqU+HE9DUYgIb/ji1CyQTrRJGZ4YfF3ZZ9QO+eSoY4Cw2VTFxRKGw==; 20:/R39v/xLNuE3PzsKG3YFvHrATyJJt0/5TeN3ftcCpRCidRgFWr8Awvsu7w+20C+4BOHDa4rqM/pKSy1X7wE5YDzQ/YXyQw6k9baJPqmLNddHJTFCIcSCgpeQwmzdGuEpkzNqNjbb9hh9/VP6a7ubiLPhZvMPAItXl2Q0fe7eI/q9vms3+OvZNr453V0N2w4RAL0bhxYdv4/JmMndlyJGzY+7tloBRFIh7RrJ+rzdOCCu8MsOPR25sX7fkukRbeVt3roIsb3/XzFdB1pYFd1+S1FX31qOnjFM6R+2Hd+THWQ4uJ4zKyXKJX3klYBz8XNe1bU1XYztJ4F7UKTSRo7AbjIKqKkybJjmoJFOBxJoxRarDtmMOoOkSRM7Jr9eVsv+a1vuFpJ+8jPlS/325cbRRhEnD2Rcr5FM/PFk5Th0Bym79S/kQASkcCB1+nEW3VatgRGsFcUNMa6lRHfM1r7AI32yf4M2eYx8nn2J91o3UKX8Rm1ta70pXZIidy/vRyhG X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(20161123558025)(6072148); SRVR:BN3PR0101MB1026; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0101MB1026; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1026; 4:nRkLhYc0wN46T+nVUqHQZNJMQmqwkZ/CuMvknOPABvztYJWN3Fn9ICr4ysi1dXp2a36U4Wh/InSNGTK1L1THVDnTakc4+FEA54d9kWQnJ4VipBHsbr6Xg6Gr3FZKvInu6O/JGtzEwEyNKyUNFdbz2ZShWh9f85aIsXPWiDVJSWPJn+qGQHM9S2P+om7FyVwhn0Ts95/8aeNyM9RB38cYxMMAaWz9VdaB/s229wwsFpGJa89Gn3ddHJITRHnK8d6mBabaIGhXB7KQ0YqtvggDcEP7MYaL/uyq45kp14b6ekSfcDrRHfVHZ3J/k5gZReyzeEc6c4e6vYvd4sS/nS6/saDoHOXJV6+It75HOzYdGgA7TWORPUObExp0WaC/b9OcXl4SlUUT775MfKE5HYK5FIeYqJGHzvtQkVL/S1OzqM7rCQp7h8shlro1wN9fhAJ0bOVq0PBsKh2GyRLA7h6umqGoiEGjXPWTsWRkNdeTDKEeOnP7AiIGy8cQMzW/XupOsF7P/t8aCglfrGUm/4XddhqBijF4OQWItao+WNcwC1nfAjxo7pG7ZW0bu6sz0iYv+4C1Xq8ezSLBpC/Z0RALHA== X-Forefront-PRVS: 02213C82F8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(39450400003)(24454002)(199003)(189002)(81166006)(6916009)(81156014)(2950100002)(8676002)(6666003)(50466002)(83716003)(53936002)(36756003)(106356001)(105586002)(110136004)(25786008)(5660300001)(50226002)(97736004)(82746002)(38730400002)(6246003)(90366009)(229853002)(77096006)(189998001)(101416001)(6486002)(5003940100001)(230783001)(76176999)(33656002)(93886004)(47776003)(42186005)(86362001)(50986999)(305945005)(68736007)(3846002)(7736002)(6116002)(2906002)(450100001)(66066001)(92566002)(53546006)(132733001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0101MB1026; H:[172.19.254.104]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1026; 23:qJU880CRDLxsApQaAfPwkV3uxbptoN4P9WVm2jZ?= =?us-ascii?Q?pgpVlNG/7ZIy0XRp20sKmYVcxmjKu4/CtBUE52PJPlje0uaXa4QA9HjElbIb?= =?us-ascii?Q?16gZ4ixYu3uKG5mLV9eqV067cp3cSVQSmQ2z7xfi8BGrA2LMrf8577ECcs7n?= =?us-ascii?Q?GTVW4/MaHyp55xYsQUXbT5RO/3R1ci5fNSmu11aa/3AGWl2m7i7EyszoIb3W?= =?us-ascii?Q?cqLP6YjM664XMI8yJCNaz5H7ErpLEim2USBBHEh7hy53YtRDlRaFiQxUqRlf?= =?us-ascii?Q?tt0aUtSH6p0N5jhIqsw5+fOWxQ0tifDIO9YiihHym57ZHqY3Dut6dlGk/RNC?= =?us-ascii?Q?TIKe06p6z04v8+nmAxwzYvkJ/lKIHMhOoBw7SeuOeUbac05gQAgKH74kBzIR?= =?us-ascii?Q?RH6mBu5q3cFh3mN/JGd7tlskTCBCiM0f3mhbG5svjM23ufSdoKV+ZpBI22MD?= =?us-ascii?Q?Lurck/5dVOZxHk9SXEvCxfgYmWgI6y1Ke1/LEt4H8M5Ul/4I/b44pGW7A4uI?= =?us-ascii?Q?DL+XOicDfsb+xLH8/+zxhR9l8d1AjyY8BG1D0UIrHRzWIVsVWhrhNZBkrxj8?= =?us-ascii?Q?jntlYdFT9VADyPDVMgBVRVqv12/h1ogyT/vPerbcoMqA8zXJJaex7d/tu7lI?= =?us-ascii?Q?LuyY4FsdfyIxeQz+7+krXrd3ykK6rgQ/mKWUJ2W/GsNeVMHR6QlwCNwOu1F9?= =?us-ascii?Q?gg72zEittt9JDNBnmxfjXplnjdr3ElyXxVJx8diC42P4b1/9zESIreOfbkDp?= =?us-ascii?Q?/X4TceKYZzqUXzRGz9eyiMUE/8nGlHKqFEcTrMMjq/hhQxk1+hBocuNzowiW?= =?us-ascii?Q?XakLVVw8BVGXlczwyU2cKaOiL8gxUoHsUBCvg9gPGqUT6U8jRZJbXpLmM4vR?= =?us-ascii?Q?jXYuvmQg+0T9/bIvMX9+Aryv1cINOn/qDGfnIYRAr899appO6sDWr0CcNwci?= =?us-ascii?Q?gOASQWQFmucJkdOg2U4vnpJwssUxIRy3Pd5io5cC5owmoP4veJBTbJqLPlE2?= =?us-ascii?Q?8xwj5B5rNzwuUDQaDgdrplZiBoiKp9VBAwSgcgiO28TawR5FGwZ1Lp2/serc?= =?us-ascii?Q?JwMiryst2L5PgtIILz1iSnEZH3xbeBwUR6NTXZWrBCjKY5UPWOdgoi9Sq36e?= =?us-ascii?Q?rMt4rXduI1bGr9QRbpD+oE/58F5UeTI0qAVFh8MD4VjTAxWCagA2msJSNmZ1?= =?us-ascii?Q?eGXDWLS2e79BzcX4cQOSF+5ZKfa4hc78Nx7thDajoMXzSVNY6lCACp/PBvo9?= =?us-ascii?Q?ybiShJYOOAZYAuBFKS+jg/yRAPC5EezrsMo4SV2DJl0CCxViYlFYjHpUtbd6?= =?us-ascii?Q?1dLufCzir56f2tMPKOXiixMg=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1026; 6:M6C3PpLmtl6cF9AkXjOuFtEQbxcdbERdqpK8jcFtbhJhCtqZUA1aKXN1eCuvxSffbIO0prdNNiGfmj/5b4WnBoWbVr3B5MSxc1hV/r99oLPq59VDRKAIMjnVtvKiwNDmX/28cKFQiFyEirIcHCFFS10QfXlNAcpcl5F26OZTXzMeYmDseF4dNXA4STMTOjZ+KQAnHEX09i/L9zXb7CKXvuOP4jT9tPiDCkLwvJ1CL7m9AaZut355CaldhDuQ6VDHSYoJhcCETMiSLn6S6OanR4w5VRukdJpPRYk6Y7hJobCG9Amm8+SooNJFw0qaGNIBTPEw/j5YIg0TkXdk+tRgGZ6uvHqSMrQD6somDUBr+5YdXPB04kxT3E4CerxO+azJXmAaI1LYZ087PJD/eQyhvQ==; 5:/RzlVxjJU88yUOsVmTmDL9Fai7/fLsGKgWBxPhoVHx0UkE775Ye5r4vxtGUMCayHKpwV8VwWVkoNYdK+CtlF/oA8rMjxDbBPjM6b5fv4PkWnkWhUl/kT5TLpPjtOye8B4faeQav1p8Xak0IfTIuTGA==; 24:rkE6PPk+VcrPHeHlB9qlBCW34DHrAqW4cSKbn88/ynfc+4ZTyz8+a7zKnw56zfEOp9zxSy7olYOnhyT6fFJUuiZWXaYT/87fnnIFxfnCHbo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1026; 7:axmnsDR8VCUESS4x9JHRQAuOkjiBj0u0F+8p1BDN03r+ui7/uBOy2g/MYbNfwhx9kweM0vvgMMoN/TZYYr+kDa0FRYHFJEPLNneUedrbzCwfLvo3xr24zmN5ypyCg3K3V2KfwIRLbGQ+zeG+jzFwfIztc/u8LLM+D/TIiqMcFQNYNXGztxBba10Rf+cLAmFRdMKh/RhVAXFwLans0xEYp/GJRDL5XYTqhmu8RbRZHAmJ9Dh1hQdRFHh1Uu89EOWOKzwhXq18Yck8UhErwOuu18/Ism1yssUtUmDMeAYZ5c2YWI21Vdzk4gyed+00puHAaKRqCFld5N3K4Iojwhirxg== X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Feb 2017 05:40:16.8975 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0101MB1026 Archived-At: Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 17 Feb 2017 05:40:22 -0000 On 16 Feb 2017, at 23:10, Ehud Doron wrote: > Nevertheless, the WG need to first get to an agreement about the kind > of telemetry required to facilitate a viable anti-DoS service (see > please the email the DOTS telemetry authors sent to the WG). Why? There are already viable anti-DDoS services today, using a variety of telemetry. ----------------------------------- Roland Dobbins From nobody Fri Feb 17 05:13:18 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F84D129A64 for ; Fri, 17 Feb 2017 05:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 lqzhzEYyOcF7 for ; Fri, 17 Feb 2017 05:13:14 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id 7D040129A5E for ; Fri, 17 Feb 2017 05:13:14 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 9AC4425F6FE; Fri, 17 Feb 2017 22:13:13 +0900 (JST) Received: from [IPv6:::1] (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id D3132759011; Fri, 17 Feb 2017 22:13:12 +0900 (JST) To: Roland Dobbins , dots References: <8e4b578e-c96e-60f1-244a-f648067dcad5@cisco.com> From: kaname nishizuka Message-ID: <97d79d4e-1bdc-f45f-eb6f-874544a9c05d@nttv6.jp> Date: Fri, 17 Feb 2017 22:13:12 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] DOTS Telemetry X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 17 Feb 2017 13:13:16 -0000 >> What are your thoughts on satisfying those requirements ? client-to-server and server-to-client bandwidth information are very important for our network's DDoS protection. Let me introduce our way to satisfy these requirement. * client-to-server We are providing various countermeasures: 1) RTBH, 2) ACL and 3) dedicated mitigation boxes. We are requesting our customers to send attack bandwidth(bps/pps) information before starting the request for protection because we are caring about the rest of capacity of the mitigation boxes. If the mitigation boxes could be overwhelmed when the new protection request is added on them, we avoid to use them and select RTBH/ACL to protect our customer and our platform(mitigation boxes). Then, bandwidth information from client to our system is crucial hint of selection of the countermeasures. * server-to-client We are providing bandwidth(bps/pps) information of passed(it seems legitimate) and dropped traffic to our customers. This is critical requirement from customers. They want to check the efficacy of the protection, then if it is not satisfactory, they will decide to take another action to make their services work again as soon as possible. With these in my mind, I draw lines like this: mandatory: MVP(targeted IP etc..) optional: Bandwidth(bps/pps) information (client-to-server and server-to-client) extension: other telemetries I think DOTS is mainly about volumetric DDoS attacks because it is concerning about the hostile condition of upper circuit. If DOTS protocol can convey volumetric information in its spec, it is reasonable and can relief operators who are interested in using it. When it comes to WG strategy, I tend to agree with Roland's step-by-step approach. step1: concentrate on the signaling functionality, step2: circle back to telemetry thank you, Kaname On 2017/02/17 7:42, Roland Dobbins wrote: > On 17 Feb 2017, at 4:43, Flemming Andreasen wrote: > >> What are your thoughts on satisfying those requirements ? > > Those things aren't 'telemetry' in the sense it's used in the DDoS mitigation space. It's status information. > > And it ought to be standardized as part of this WG's efforts at some point, IMHO. > > However, that's more of a forward-looking recommendation. Quantifying mitigation efficacy is something that we want to see included within the scope of DDoS mitigation solut to ionsthe degree that it's practical to do so, but is not a capability we really see today. It's largely done out-of-band to date. > > So, this shouldn't be a MVP requirement, because it's forward-looking guidance. We want to a) encourage its implementation and adoption and b) be ready to accommodate it once it's implemented and adopted. > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Feb 17 05:21:05 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773C812943D for ; Fri, 17 Feb 2017 05:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.787 X-Spam-Level: X-Spam-Status: No, score=-3.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com 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 5KzWPc73RPE5 for ; Fri, 17 Feb 2017 05:21:02 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0092.outbound.protection.outlook.com [104.47.41.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1DD129A50 for ; Fri, 17 Feb 2017 05:21:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vz3jFn+og5C9eFTj2JzORmwFyV91etlRG4Bz0FhIQsE=; b=GX9VhgqpNke01cOzDa94Ojbm0ZaWcEtmRnIX5D0Nc1w8/4WAE0dBUoVsD+QPNTS0ZYRjG4u6zUOIfj5gJnDILZ6+O7HlrbjqjyfLk7cwqHkVyQs4+j+WR5gpONkeLn84LFQVkYlLf91KjLyLYK5FhZCiEuzzwz8BEhlGy+cBlCo= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1038.prod.exchangelabs.com (10.160.129.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 17 Feb 2017 13:21:00 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([10.160.129.156]) by DM2PR0101MB1039.prod.exchangelabs.com ([10.160.129.156]) with mapi id 15.01.0888.030; Fri, 17 Feb 2017 13:21:00 +0000 From: "Dobbins, Roland" To: kaname nishizuka Thread-Topic: [Dots] DOTS Telemetry Thread-Index: AQHSiGdqs9jnVMU+R1WnPYyVGJhdZKFsKsCAgACFyACAAH3XAIAAAi4S Date: Fri, 17 Feb 2017 13:21:00 +0000 Message-ID: <0F63FC45-0030-41F0-9FFD-7485F5597F95@arbor.net> References: <8e4b578e-c96e-60f1-244a-f648067dcad5@cisco.com> , <97d79d4e-1bdc-f45f-eb6f-874544a9c05d@nttv6.jp> In-Reply-To: <97d79d4e-1bdc-f45f-eb6f-874544a9c05d@nttv6.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2405:9800:b400:bfe0:b9da:9f32:143a:e1de] x-ms-office365-filtering-correlation-id: 9172fc52-3b08-4e45-1107-08d45737d0f3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:DM2PR0101MB1038; x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1038; 7:HHLZthE8MYV/YBJxxKoiHtFaiBlUQXqOBmb3wPrOxt6QaFL6GT9cWIOfk1qt9VxrdMdbxEfr4ufwVvL/28gKgMWfMu2CgtaiBLfqDSvhbOKbEiy4hpjiGc1P1hSI93lX3rVhoF1VOMfb8LSUAnEHWjKVU95hIf8QU77vHx3nc6QP0S07DjvLFB/Ts3BfT+bYvtWnjIIJnsYXFewU3FpL9uSBrNLfbqb/VONsz1qyP9vvAFdBvRZT0ZhKEl8hKFdjd3UefZwIYpPu/35XlXEj+LFkRYILuynhKiPhd5bJDZ6g0DXVkSWKODjudNt4TgptsfWoTwjfefm6UpGPacpDOA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123562025)(20161123555025)(20161123558025)(20161123560025)(20161123564025)(6072148); SRVR:DM2PR0101MB1038; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0101MB1038; x-forefront-prvs: 02213C82F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(199003)(189002)(85664002)(24454002)(5660300001)(36756003)(6116002)(236005)(2906002)(6916009)(101416001)(33656002)(3660700001)(53936002)(102836003)(4326007)(2950100002)(76176999)(86362001)(54896002)(54356999)(8936002)(83716003)(50986999)(3280700002)(68736007)(81166006)(122556002)(8676002)(6512007)(106356001)(2900100001)(189998001)(7736002)(82746002)(6246003)(81156014)(77096006)(6436002)(93886004)(105586002)(92566002)(6506006)(25786008)(38730400002)(106116001)(229853002)(6486002)(99286003)(97736004)(110136004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1038; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_0F63FC45003041F09FFD7485F5597F95arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2017 13:21:00.4615 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1038 Archived-At: Cc: dots Subject: Re: [Dots] DOTS Telemetry X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 17 Feb 2017 13:21:04 -0000 --_000_0F63FC45003041F09FFD7485F5597F95arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBGZWIgMTcsIDIwMTcsIGF0IDIwOjEzLCBrYW5hbWUgbmlzaGl6dWthIDxrYW5hbWVAbnR0 djYuanA8bWFpbHRvOmthbmFtZUBudHR2Ni5qcD4+IHdyb3RlOg0KDQpJIHRoaW5rIERPVFMgaXMg bWFpbmx5IGFib3V0IHZvbHVtZXRyaWMgRERvUyBhdHRhY2tzIGJlY2F1c2UgaXQgaXMgY29uY2Vy bmluZyBhYm91dCB0aGUgaG9zdGlsZSBjb25kaXRpb24gb2YgdXBwZXIgY2lyY3VpdC4NCk5vLCBp dCBpc24ndCBtYWlubHkgYWJvdXQgdm9sdW1ldHJpYyBhdHRhY2tzIC0gdGhhdCdzIGp1c3Qgd2hh dCBhIGxvdCBvZiB0aGUgZGlzY3Vzc2lvbiBpcyBhYm91dC4NCg0KSXQgYXBwbGllcyB0byBhbGwg Zm9ybXMgb2YgRERvUyBhdHRhY2sgLSBieSBkZXNpZ24uDQoNClRoZXJlJ3Mgbm90aGluZyBhYm91 dCBET1RTIHdoaWNoIGlzIHNwZWNpZmljIHRvIGNpcmN1aXQgY29uZGl0aW9ucy4NCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0Bh cmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+DQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0PG1h aWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0K --_000_0F63FC45003041F09FFD7485F5597F95arbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T24gRmViIDE3LCAyMDE3LCBhdCAy MDoxMywga2FuYW1lIG5pc2hpenVrYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthbmFtZUBudHR2Ni5q cCI+a2FuYW1lQG50dHY2LmpwPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8ZGl2Pjxicj4NCkkgdGhp bmsgRE9UUyBpcyBtYWlubHkgYWJvdXQgdm9sdW1ldHJpYyBERG9TIGF0dGFja3MgYmVjYXVzZSBp dCBpcyBjb25jZXJuaW5nIGFib3V0IHRoZSBob3N0aWxlIGNvbmRpdGlvbiBvZiB1cHBlciBjaXJj dWl0Ljxicj4NCjwvZGl2Pg0KPGRpdj5ObywgaXQgaXNuJ3QgbWFpbmx5IGFib3V0IHZvbHVtZXRy aWMgYXR0YWNrcyAtIHRoYXQncyBqdXN0IHdoYXQgYSBsb3Qgb2YgdGhlIGRpc2N1c3Npb24gaXMg YWJvdXQuICZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SXQgYXBwbGllcyB0 byBhbGwgZm9ybXMgb2YgRERvUyBhdHRhY2sgLSBieSBkZXNpZ24uICZuYnNwOzwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlcmUncyBub3RoaW5nIGFib3V0IERPVFMgd2hpY2ggaXMg c3BlY2lmaWMgdG8gY2lyY3VpdCBjb25kaXRpb25zLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUs IDI1NSwgMCk7Ij48c3BhbiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBm b250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgZm9udC12YXJpYW50LW51bWVyaWM6IG5vcm1h bDsgZm9udC12YXJpYW50LWFsdGVybmF0ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNp YW46IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPC9zcGFuPjxiciBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9y bWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgZm9udC12YXJpYW50LW51bWVyaWM6 IG5vcm1hbDsgZm9udC12YXJpYW50LWFsdGVybmF0ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVh c3QtYXNpYW46IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPg0KPHNwYW4gc3R5bGU9ImZv bnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1udW1lcmljOiBub3JtYWw7IGZvbnQtdmFyaWFudC1hbHRlcm5hdGVz OiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7Ij5Sb2xhbmQgRG9iYmlucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9y Lm5ldCIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycz0idHJ1ZSIgeC1hcHBsZS1kYXRhLWRldGVjdG9y cy10eXBlPSJsaW5rIiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXJlc3VsdD0iMiI+cmRvYmJpbnNA YXJib3IubmV0PC9hPiZndDs8L3NwYW4+PC9zcGFuPjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwg MCk7Ij48c3BhbiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZh cmlhbnQtcG9zaXRpb246IG5vcm1hbDsgZm9udC12YXJpYW50LW51bWVyaWM6IG5vcm1hbDsgZm9u dC12YXJpYW50LWFsdGVybmF0ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPC9zcGFuPjxiciBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBm b250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgZm9udC12YXJpYW50LW51bWVyaWM6IG5vcm1h bDsgZm9udC12YXJpYW50LWFsdGVybmF0ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNp YW46IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtdmFy aWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGZv bnQtdmFyaWFudC1udW1lcmljOiBub3JtYWw7IGZvbnQtdmFyaWFudC1hbHRlcm5hdGVzOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 Ij5Sb2xhbmQgRG9iYmlucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCIg eC1hcHBsZS1kYXRhLWRldGVjdG9ycz0idHJ1ZSIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycy10eXBl PSJsaW5rIiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXJlc3VsdD0iMiI+cmRvYmJpbnNAYXJib3Iu bmV0PC9hPiZndDs8L3NwYW4+PC9zcGFuPjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0F63FC45003041F09FFD7485F5597F95arbornet_-- From nobody Fri Feb 17 05:57:44 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD8612956B for ; Fri, 17 Feb 2017 05:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.286 X-Spam-Level: X-Spam-Status: No, score=-3.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 YKSeQjMv6xAf for ; Fri, 17 Feb 2017 05:57:41 -0800 (PST) Received: from smtp86.iad3a.emailsrvr.com (smtp86.iad3a.emailsrvr.com [173.203.187.86]) (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 7163E1294A8 for ; Fri, 17 Feb 2017 05:57:41 -0800 (PST) Received: from smtp35.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp35.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id AE76259A9; Fri, 17 Feb 2017 08:57:36 -0500 (EST) X-Auth-ID: bgreene@senki.org Received: by smtp35.relay.iad3a.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id 4E3E95A40; Fri, 17 Feb 2017 08:57:36 -0500 (EST) X-Sender-Id: bgreene@senki.org Received: from [172.16.1.3] (c-73-92-124-43.hsd1.ca.comcast.net [73.92.124.43]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 17 Feb 2017 08:57:36 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Barry Raveendran Greene In-Reply-To: <97d79d4e-1bdc-f45f-eb6f-874544a9c05d@nttv6.jp> Date: Fri, 17 Feb 2017 05:57:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4CE6428E-1FD6-4E6D-A2FB-B27B5A85C579@senki.org> References: <8e4b578e-c96e-60f1-244a-f648067dcad5@cisco.com> <97d79d4e-1bdc-f45f-eb6f-874544a9c05d@nttv6.jp> To: kaname nishizuka X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Roland Dobbins , dots Subject: Re: [Dots] DOTS Telemetry X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 17 Feb 2017 13:57:42 -0000 > On Feb 17, 2017, at 5:13 AM, kaname nishizuka wrote: >=20 > I think DOTS is mainly about volumetric DDoS attacks because it is = concerning about the hostile condition of upper circuit. > If DOTS protocol can convey volumetric information in its spec, it is = reasonable and can relief operators who are interested in using it. On the Telemetry side, this sort of information is NOT going to make a = dent in the problem. We need information that would contribute to a = trackback and backtrace to a DOS attack.=20 For the people who really mitigate attacks, the most tedious part of the = process is calling each of their peers for whom the attack is inbound = from, then working with them to trace back to that peer=E2=80=99s entry = point. =46rom there, the next upstream point of the attack. Then getting = into the ASN to find the origin points. If the ASN has the tools turned = on the router to do traffic engineering and traffic analytics for = business/planning, then they also have the tools to run the tracebacks. = That would be an ideal tools for DOTS Telemetry to =E2=80=9Cask for = information.=E2=80=9D This was done in TIDP/TMS. So it can be done.=20 From nobody Fri Feb 17 06:05:35 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CE212946F for ; Fri, 17 Feb 2017 06:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com 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 eM6M0wMZXX1j for ; Fri, 17 Feb 2017 06:05:31 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0100.outbound.protection.outlook.com [104.47.37.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B9B1295C9 for ; Fri, 17 Feb 2017 06:05:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=njtzj/DrxkUiIBKMpk8/lxwe+HFS3mh1ubmZXk57e3E=; b=fpZ9ah9yJhfopUrbXfbF0pmRUFwgqKhD97Q+rLMVQl+Nzw1waaSMAtpYPom2ABOqcCV/R2r/8MVGrkcUr+DTi7BAmj9C3wmRoOXJOltXqlwr/JM+JYlg+FSTjyq4VSNkIYn4KIzMOoNDr9TbEGgm08PcHJQAJOu7HCLHP3ZdQYY= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 17 Feb 2017 14:05:30 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([10.160.129.156]) by DM2PR0101MB1039.prod.exchangelabs.com ([10.160.129.156]) with mapi id 15.01.0888.030; Fri, 17 Feb 2017 14:05:30 +0000 From: "Dobbins, Roland" To: Barry Raveendran Greene Thread-Topic: [Dots] DOTS Telemetry Thread-Index: AQHSiGdqs9jnVMU+R1WnPYyVGJhdZKFsKsCAgACFyACAAH3XAIAADGeAgAACNkQ= Date: Fri, 17 Feb 2017 14:05:30 +0000 Message-ID: <9DDFFA4C-BA2E-4453-BC14-049563612454@arbor.net> References: <8e4b578e-c96e-60f1-244a-f648067dcad5@cisco.com> <97d79d4e-1bdc-f45f-eb6f-874544a9c05d@nttv6.jp>, <4CE6428E-1FD6-4E6D-A2FB-B27B5A85C579@senki.org> In-Reply-To: <4CE6428E-1FD6-4E6D-A2FB-B27B5A85C579@senki.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2405:9800:b400:bfe0:b9da:9f32:143a:e1de] x-ms-office365-filtering-correlation-id: 70dd66b3-dedd-42db-51e6-08d4573e0827 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:DM2PR0101MB1039; x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1039; 7:jOiN5QWXUbCqgw0JyesPNTD8IXqzIRj2FaFLhechHJhcgOzZWA2gD+mjI5FY+tJrkxJYL4DHDpYLa55hVbSDewzlUPfSCDiRY4fuo2YcqTspol3XeXLFPwEkx7HdmDqzQHOBpyX7lC4+4drIeLDi1fXQgYL9LSkLSVv4hr/I1AayxjdzkQ3BYwqz23kP9WXtSWdqD+9djsCfeWWe+S4KljnfCSavv9pIm3Txyp8y5DA7jlfFZkULX/jwvUdAtdh89goCICJRhVY5F9fxz3iJ29PNagINrAC/breH8Uvgji+6wczZyg+EAc/GrOMkWd30IKbkrld7m72tJCtg/kBavQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558025)(6072148); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0101MB1039; x-forefront-prvs: 02213C82F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(24454002)(199003)(189002)(6506006)(50986999)(38730400002)(81166006)(81156014)(99286003)(54896002)(6512007)(82746002)(106356001)(54906002)(236005)(6486002)(8676002)(229853002)(3660700001)(77096006)(93886004)(6436002)(110136004)(83716003)(25786008)(2906002)(4326007)(3280700002)(53936002)(2900100001)(68736007)(92566002)(97736004)(101416001)(122556002)(5660300001)(36756003)(76176999)(54356999)(86362001)(106116001)(6116002)(6246003)(33656002)(102836003)(8936002)(6916009)(105586002)(2950100002)(7736002)(189998001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_9DDFFA4CBA2E4453BC14049563612454arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2017 14:05:30.1216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 Archived-At: Cc: dots , kaname nishizuka Subject: Re: [Dots] DOTS Telemetry X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 17 Feb 2017 14:05:34 -0000 --_000_9DDFFA4CBA2E4453BC14049563612454arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBGZWIgMTcsIDIwMTcsIGF0IDIwOjU3LCBCYXJyeSBSYXZlZW5kcmFuIEdyZWVuZSA8Ymdy ZWVuZUBzZW5raS5vcmc8bWFpbHRvOmJncmVlbmVAc2Vua2kub3JnPj4gd3JvdGU6DQoNClRoaXMg d2FzIGRvbmUgaW4gVElEUC9UTVMuIFNvIGl0IGNhbiBiZSBkb25lLg0KV2hlbiBvcGVyYXRvcnMg aGF2ZSBET1RTIHBlZXJzIHNldCB1cCwgYWxsIHRoZXkgaGF2ZSB0byBkbyBpcyByZXF1ZXN0IG1p dGlnYXRpb24gZm9yIHRoZSB0YXJnZXQuICBUaGVpciBwZWVycyBkbyB0aGUgc2FtZSwgZXRjLg0K DQpUaGF0IHdpbGwgc3ByZWFkIG1pdGlnYXRpb24gaW4gJ2lua2Jsb3QnIGZhc2hpb24gLSBpLmUu LCAndHJhY2ViYWNrIHZpYSBwZXJ2YXNpdmUgbWl0aWdhdGlvbicuDQoNClRoZSBzdGF0dXMgbWVz c2FnZXMgYWxzbyBzZXJ2ZSB0aGlzIHB1cnBvc2UuDQoNCklmIHdlIHdhbnQgdG8gYWRkIGV4cGxp Y2l0IHRyYWNlYmFjayByZXF1ZXN0cyBsYXRlciwgd2UgY2FuLiAgQnV0IHBlcnZhc2l2ZSBtaXRp Z2F0aW9uIGluIGFuZCBvZiBpdHNlbGYgYWNjb21wbGlzaGVzIHRoZSBnb2FsLCB0byBhIGxhcmdl IGV4dGVudC4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJvbGFuZCBE b2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+DQo= --_000_9DDFFA4CBA2E4453BC14049563612454arbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T24gRmViIDE3LCAyMDE3LCBhdCAy MDo1NywgQmFycnkgUmF2ZWVuZHJhbiBHcmVlbmUgJmx0OzxhIGhyZWY9Im1haWx0bzpiZ3JlZW5l QHNlbmtpLm9yZyI+YmdyZWVuZUBzZW5raS5vcmc8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxkaXY+ PGJyPg0KVGhpcyB3YXMgZG9uZSBpbiBUSURQL1RNUy4gU28gaXQgY2FuIGJlIGRvbmUuPGJyPg0K PC9kaXY+DQo8ZGl2PldoZW4gb3BlcmF0b3JzIGhhdmUgRE9UUyBwZWVycyBzZXQgdXAsIGFsbCB0 aGV5IGhhdmUgdG8gZG8gaXMgcmVxdWVzdCBtaXRpZ2F0aW9uIGZvciB0aGUgdGFyZ2V0LiAmbmJz cDtUaGVpciBwZWVycyBkbyB0aGUgc2FtZSwgZXRjLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+VGhhdCB3aWxsIHNwcmVhZCBtaXRpZ2F0aW9uIGluICdpbmtibG90JyBmYXNoaW9uIC0g aS5lLiwgJ3RyYWNlYmFjayB2aWEgcGVydmFzaXZlIG1pdGlnYXRpb24nLjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIHN0YXR1cyBtZXNzYWdlcyBhbHNvIHNlcnZlIHRoaXMgcHVy cG9zZS4gJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JZiB3ZSB3YW50IHRv IGFkZCBleHBsaWNpdCB0cmFjZWJhY2sgcmVxdWVzdHMgbGF0ZXIsIHdlIGNhbi4gJm5ic3A7QnV0 IHBlcnZhc2l2ZSBtaXRpZ2F0aW9uIGluIGFuZCBvZiBpdHNlbGYgYWNjb21wbGlzaGVzIHRoZSBn b2FsLCB0byBhIGxhcmdlIGV4dGVudC4gJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAw KTsiPjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFy aWFudC1wb3NpdGlvbjogbm9ybWFsOyBmb250LXZhcmlhbnQtbnVtZXJpYzogbm9ybWFsOyBmb250 LXZhcmlhbnQtYWx0ZXJuYXRlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08L3NwYW4+PGJyIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZv bnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBmb250LXZhcmlhbnQtbnVtZXJpYzogbm9ybWFs OyBmb250LXZhcmlhbnQtYWx0ZXJuYXRlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lh bjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+DQo8c3BhbiBzdHlsZT0iZm9udC12YXJp YW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgZm9u dC12YXJpYW50LW51bWVyaWM6IG5vcm1hbDsgZm9udC12YXJpYW50LWFsdGVybmF0ZXM6IG5vcm1h bDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsi PlJvbGFuZCBEb2JiaW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0IiB4 LWFwcGxlLWRhdGEtZGV0ZWN0b3JzPSJ0cnVlIiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXR5cGU9 ImxpbmsiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMtcmVzdWx0PSIyIj5yZG9iYmluc0BhcmJvci5u ZXQ8L2E+Jmd0Ozwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9DDFFA4CBA2E4453BC14049563612454arbornet_-- From nobody Mon Feb 20 10:30:40 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D42D126BF7 for ; Mon, 20 Feb 2017 10:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com 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 CU8DEmfJrlmK for ; Mon, 20 Feb 2017 10:30:36 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0090.outbound.protection.outlook.com [104.47.42.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701AF1294B6 for ; Mon, 20 Feb 2017 10:30:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OsaP6pZQb5/w9yaMVxb/jDlUCThaRHEny+pgUml/CUs=; b=fMwd+BRntA927LQkQ12opmmTmjoLNZ6jmKq2HjPYRKnO4BzeQYqb5KO95goVXjCecTP2M2b4zqBAFmjvM49qtMoOQS/+EQujRQ1zSu2uuwNL/KByZVDco4cq35BpX60JhcrpPZGAtTzN4jJ0/Dad1ZJhY/xNd46yE4B3mz8A0i8= Received: from MWHPR0101MB3118.prod.exchangelabs.com (10.174.167.145) by MWHPR0101MB3120.prod.exchangelabs.com (10.174.168.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Mon, 20 Feb 2017 18:30:34 +0000 Received: from MWHPR0101MB3118.prod.exchangelabs.com ([10.174.167.145]) by MWHPR0101MB3118.prod.exchangelabs.com ([10.174.167.145]) with mapi id 15.01.0919.015; Mon, 20 Feb 2017 18:30:34 +0000 From: "Mortensen, Andrew" To: Dave Dolson Thread-Topic: feedback on draft-ietf-dots-requirements Thread-Index: AdJCw56N3It0vvnJSvSfOG8E2IPZ9BI48yMA Date: Mon, 20 Feb 2017 18:30:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=amortensen@arbor.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [76.206.40.10] x-ms-office365-filtering-correlation-id: d661fdb0-504e-41bb-fe74-08d459be8edb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:MWHPR0101MB3120; x-microsoft-exchange-diagnostics: 1; MWHPR0101MB3120; 7:glq57aAjRyl+vv7I7IwnD1t0L7GefuTxOcb3q6nr47GoO9HWMzHoG8eYucD+DbRu/JnnpgX8N6fIwoT55ZB63kDJQ48/LxKIJbSt2u0VN++mmNSz4FAtM+T1+p/ozC9i5/PtB2tkYQoOjOV+pBJt1PqSS/oIK68DSOKWR4436ac+SMrIfuQcnBg7//q1cERfwega/TqfqUCh/guAgAOjrZ2EAAHm6dopdKWaPWBp5mN7CnFXcDmTSY/QzskCuvGVp+T3vAgnVzaEsJEILKOMX2HXm7iXl+EirR6RU6b1ZorvEMKgGw6w+9CAx3VLZVXYmSpxD2S1UaRGAwrwZFyymw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(20161123558025)(6072148); SRVR:MWHPR0101MB3120; BCL:0; PCL:0; RULEID:; SRVR:MWHPR0101MB3120; x-forefront-prvs: 02243C58C6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(189002)(199003)(377454003)(57704003)(24454002)(81166006)(8936002)(25786008)(68736007)(86362001)(77096006)(6436002)(6486002)(36756003)(8676002)(6506006)(6916009)(81156014)(122556002)(3660700001)(3280700002)(2906002)(229853002)(82746002)(54356999)(50986999)(76176999)(2950100002)(102836003)(6116002)(38730400002)(110136004)(4326007)(3846002)(230783001)(6246003)(105586002)(83716003)(2900100001)(106356001)(101416001)(97736004)(189998001)(92566002)(7736002)(99286003)(53936002)(236005)(33656002)(5660300001)(54896002)(6512007)(66066001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR0101MB3120; H:MWHPR0101MB3118.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_C94EC833D04D49A7A13B392ACB52BF45arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2017 18:30:33.6349 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0101MB3120 Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] feedback on draft-ietf-dots-requirements X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 20 Feb 2017 18:30:39 -0000 --_000_C94EC833D04D49A7A13B392ACB52BF45arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBEYXZlLiBUaGlzIGlzIHZlcnkgaGVscGZ1bC4gTXkgKGV4dHJlbWVseSB0YXJkeSkg cmVzcG9uc2VzIGFyZSBpbmxpbmUuIEnigJl2ZSBzbmlwcGVkIG1vc3Qgb2YgdGhlIG1pbm9yIHJl cGhyYXNpbmcgc3VnZ2VzdGlvbnMuIEFsbCBjb21tZW50cyBhcmUgbWUgc3BlYWtpbmcgZm9yIG15 c2VsZiwgbm90IG5lY2Vzc2FyaWx5IGZvciB0aGUgb3RoZXIgcmVxdWlyZW1lbnRzIGRyYWZ0IGVk aXRvcnMuDQoNCknigJl2ZSBvcGVuZWQgaXNzdWVzIG9uIGdpdGh1YiBmb3IgbW9zdCBvZiB0aGVz ZSBjb21tZW50cy4NCg0KT24gTm92IDI2LCAyMDE2LCBhdCA5OjMxIFBNLCBEYXZlIERvbHNvbiA8 ZGRvbHNvbkBzYW5kdmluZS5jb208bWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tPj4gd3JvdGU6 DQoNCuKApnNuaXAuLi4NCjEuMg0K4oCmc25pcC4uLg0KRm9yIOKAnGNvdW50ZXJtZWFzdXJl4oCd LCB0aGlzIHNvdW5kcyBsaWtlIG9ubHkgcGFja2V0IGZpbHRlcmluZy4gSXMgdGhhdCBhY2N1cmF0 ZSBhbmQgY29tcGxldGU/IENvdWxkIHRhci1waXQgb3Igcm91dGluZyBjaGFuZ2VzIGJlIGluY2x1 ZGVkIGluIGNvdW50ZXJtZWFzdXJlcz8NCg0KSSBkb27igJl0IHdhbnQgdGhlIGRvY3VtZW50IHRv IHJlc3RyaWN0IHRoZSBkZWZpbml0aW9uIG9mIGNvdW50ZXJtZWFzdXJlLCBidXQgSeKAmW0gYWxz byBub3Qga2VlbiB0byBlbnNocmluZSBzcGVjaWZpYyB0eXBlcyBvZiBjb3VudGVybWVhc3VyZSwg ZWl0aGVyLiBJ4oCZbGwgcmV2aXNlIHRvIG1ha2UgaXQgY2xlYXJlci4NCg0KSXMg4oCcc2lnbmFs IGNoYW5uZWzigJ0gaW50ZW5kZWQgdG8gYmUgdGhlIHNhbWUgdGhpbmcgYXMgdGhlIOKAnHNlc3Np b27igJ0gbWVudGlvbmVkIGluIHRoZSBhcmNoaXRlY3R1cmU/IEkgdGhpbmsgc28sIGFuZCB0ZXJt aW5vbG9neSBzaG91bGQgYmUgbWFkZSBjb25zaXN0ZW50IGJldHdlZW4gdGhlIGRvY3MuIElmIG5v dCwgSSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBjaGFubmVsIGFu ZCBzZXNzaW9uLg0KDQpTcGVha2luZyBmb3IgbXlzZWxmLCB0aGUg4oCcY2hhbm5lbOKAnSBkaXN0 aW5jdGlvbiBpcyBtZWFudCB0byBkaXN0aW5ndWlzaCB0aGUgdW5yZWxpYWJsZSwgbGlnaHR3ZWln aHQgU09TIG1lc3NhZ2VzIHRvIGJlIHVzZWQgd2hlbiB1bmRlciBhdHRhY2sgZnJvbSB0aGUgcmVs aWFibGUgbWVzc2FnaW5nIHJlcXVpcmVkIHRvIGUuZy4gbWFuYWdlIGZpbHRlcnMgYW5kIHJlc291 cmNlIGFsaWFzZXMuIFRoZSDigJxzaWduYWxpbmcgc2Vzc2lvbuKAnSBpbiB0aGUgYXJjaGl0ZWN0 dXJlIGRvY3VtZW50IGlzIGFjdGl2ZSBtZXNzYWdpbmcgYmV0d2VlbiBET1RTIGFnZW50cyBvdmVy IHRoZSBzaWduYWwgY2hhbm5lbC4NCg0KU2hvdWxkIOKAnEZpbHRlcuKAnSBiZSBsaW1pdGVkIHRv IHRoZSB0d28gYWN0aW9ucyBvZiByYXRlLWxpbWl0aW5nIG9yIGRpc2NhcmRpbmc/ICBJcyBmaWx0 ZXIgcmVhbGx5IGludGVuZGVkIHRvIGluY2x1ZGUgYWN0aW9uLCBvciBqdXN0IHRoZSBtYXRjaCBj cml0ZXJpYT8NCg0KSXQgc291bmRzIGxpa2UgeW914oCZcmUgcmVhbGx5IGFza2luZyB3aGV0aGVy IHdlIHNob3VsZCBsZWF2ZSB0aGUgZGVmaW5pdGlvbiBvZiDigJxmaWx0ZXJpbmfigJ0gdXAgdG8g dGhlIERPVFMgc2VydmVyL21pdGlnYXRvci4gSSB3b3JyeSB0aGF0IGxlYXZpbmcg4oCcZmlsdGVy aW5n4oCdIGxvb3NlbHkgZGVmaW5lZCB3aWxsIGxlYWQgdG8gY29uZnVzaW9uIGZ1cnRoZXIgZG93 biB0aGUgbGluZS4gSSB0aGluayB3ZSBuZWVkIGV4cGxpY2l0IGFjdGlvbnM6IGRpc2NhcmQgaXMg dmVyeSBkaWZmZXJlbnQgZnJvbSByYXRlLWxpbWl0Lg0KDQpBcyBJIHNlZSBpdCwgZmlsdGVyaW5n IGlzIGRpc3RpbmN0IGZyb20gdmVuZG9yIGV4dGVuc2lvbnMgd2hpY2ggbWlnaHQgaW5jbHVkZSBj b3VudGVybWVhc3VyZSBzcGVjaWZpY3MuIEkgZG9u4oCZdCB0aGluayBET1RTIGlzIGEgZ2VuZXJh bCBwdXJwb3NlIGludGVyZmFjZSBmb3IgY291bnRlcm1lYXN1cmUgY29uZmlndXJhdGlvbi4NCg0K U2ltaWxhcmx5IGZvciDigJxCbGFja2xpc3TigJ06IGlzIGJsb2NrIHRoZSBvbmx5IHZhbGlkIGFj dGlvbiBmb3IgYmxhY2stbGlzdGVkIGFkZHJlc3Nlcz8NCg0KWWVzLCB0aGF04oCZcyB0aGUgZGlz dGluZ3Vpc2hpbmcgY2hhcmFjdGVyaXN0aWMgb2YgYSBibGFja2xpc3RlZCBzb3VyY2UuIEEgd2hp dGVsaXN0ZWQgc291cmNlIGlzIGFsd2F5cyBhbGxvd2VkIHRvIHBhc3MuIFRoZSBET1RTIGNsaWVu dCBoYXMgZnVsbCBjb250cm9sIG92ZXIgdGhlIGJsYWNrLS93aGl0ZS1saXN0cywgdGhvdWdoIHRo ZSBzY29wZSBpcyByZXN0cmljdGVkIGJ5IHRoZSBET1RTIHNlcnZlciB0byBwcmVmaXhlcy9yZXNv dXJjZXMgYmVsb25naW5nIHRvIHRoZSBET1RTIGNsaWVudC4NCg0KMi4NClRoZSBzZWNvbmQgcGFy YWdyYXBoIHNheXMg4oCcRE9UUyBpcyBhbiBhZHZpc29yeSBwcm90b2NvbC7igJ0gSSB0aG91Z2h0 IHRoaXMgbWlnaHQgbWVhbiB0aGF0IChhKSBhIGNsaWVudOKAmXMgcmVxdWVzdCBmb3IgYWlkIG1h eSBiZSBpZ25vcmVkIGFuZCAoYikgbWl0aWdhdGlvbiBtYXkgYmUgZG9uZSBwcmlvciB0byByZXF1 ZXN0IG9yIGFmdGVyIHdpdGhkcmF3YWwuIFdvdWxkIHRoYXQgaWRlYSBiZSBhY2N1cmF0ZT8NCg0K SSB0aGluayAoYSkgaXMgY29ycmVjdCwgdGhvdWdoIGlnbm9yaW5nIGEgcmVxdWVzdCB3aXRob3V0 IHByb3ZpZGluZyBhIHJlYXNvbiB3aGVuIGEgc2VydmljZSBhZ3JlZW1lbnQgaXMgaW4gcGxhY2Ug c2VlbXMgbGlrZSBhIHBvb3Igd2F5IHRvIG1hbmFnZSBhIHNlcnZpY2UuIEluIGdlbmVyYWwgYSBE T1RTIHJlcXVlc3QgZm9yIG1pdGlnYXRpb24gc2hvdWxkIHJlc3VsdCBpbiBtaXRpZ2F0aW9uLCBh c3N1bWluZyBidXNpbmVzcyBvciBzZXJ2aWNlIGFncmVlbWVudHMgYXJlIGluIHBsYWNlLCBidXQg bWl0aWdhdGluZyB0aGUgYXR0YWNrIG1pZ2h0IGludm9sdmUgbW9yZSB0aGFuIGp1c3QgYQ0KDQpJ biBjYWxsaW5nIERPVFMg4oCcYWR2aXNvcnnigJ0gSSB3YXMgdHJ5aW5nIHRvIGVtcGhhc2l6ZSB0 d28gcG9pbnRzOiB0aGUgZGlmZmljdWx0eSBvZiBtYWludGFpbmluZyByZWxpYWJsZSBtZXNzYWdp bmcgdW5kZXIgYXR0YWNrIGNvbmRpdGlvbnMgKHdpdGggdGhlIGNvcm9sbGFyeSB0aGF0IGEgRE9U UyBzZXJ2ZXIgbWF5IG5vdCBiZSBhYmxlIHRvIGhlbHAgZXZlbiBpZiBhIHJlcXVlc3QgZ2V0cyB0 aHJvdWdoKTsgYW5kIHRoZSBmYWN0IHRoYXQgRE9UUyBpcyBub3QgYSBnZW5lcmFsIHB1cnBvc2Ug bWl0aWdhdGlvbiBBUEkuDQoNCk1heWJlIEkgc2hvdWxkIGNsYXJpZnkgdGhhdCBmdXJ0aGVyLiBJ IGJlbGlldmUgdGhlIERPVFMgKnNpZ25hbCBjaGFubmVsKiBpcyBub3QgYSBnZW5lcmFsIHB1cnBv c2UgbWl0aWdhdGlvbiBBUEkuIFRoZSBET1RTIGRhdGEgY2hhbm5lbCBjb3VsZCBldm9sdmUgaW50 byB0aGF0IGFzIGEgc29ydCBvZiBET1RTIGNvbnRyb2wgcHJvdG9jb2wsIGluIHdoaWNoIHRoZSBp bXBhY3Qgb2YgYW4gYXR0YWNrIG9uIHRoZSBjb21tdW5pY2F0aW9uIGxheWVyIGJldHdlZW4gY2xp ZW50IGFuZCBzZXJ2ZXIgaXMgbm90IGEgY29uY2Vybi4NCg0KKE15IHRoaW5raW5nIGlzIHRoYXQg YSBET1RTIHNlcnZlciBtYXkga25vdyBiZXR0ZXIgdGhhbiB0aGUgY2xpZW50IGJhc2VkIG9uIGEg d2lkZXIgc291cmNlIG9mIHRlbGVtZXRyeS4pDQoNCkFncmVlZC4gT25jZSBhIG1pdGlnYXRvciBi ZWdpbnMgZmlsdGVyaW5nIHRyYWZmaWMgYm91bmQgZm9yIHRoZSBkb21haW4gb2YgdGhlIERPVFMg Y2xpZW50LCB0aGUgRE9UUyBjbGllbnTigJlzIHZpZXcgaW50byB0aGUgYXR0YWNrIGlzIHNrZXdl ZC4NCg0KDQotIGluIEdFTi0wMDQsIGNvbnNpZGVyIHBpY2tpbmcgYSBzcGVjaWZpYyBNVFUgc2l6 ZSwgbGlrZSA1MDAgYnl0ZXMsIGJlY2F1c2Ugb3RoZXJ3aXNlIHRoZXJlIGlzIG5vIHdheSB0byBq dWRnZSBpZiB0aGUgcHJvdG9jb2wgbWVldHMgcmVxdWlyZW1lbnRzLg0KDQpUaGlzIGhhcyBiZWNv bWUgbW9yZSBpbXBvcnRhbnQgc2luY2UgeW91IHN1Z2dlc3RlZCBpdCwgaW4gbGlnaHQgb2YgdGhl IHJlY2VudCB0aHJlYWQgb24gdGVsZW1ldHJ5LiBkcmFmdC1yZWRkeS1kb3RzLXNpZ25hbC1jaGFu bmVsIGlzIHN1Z2dlc3RpbmcgNTAwIGJ5dGVzIGluIHRoZSBldmVudCB0aGUgY2xpZW50IGNhbuKA mXQgZGlzY2VybiBwYXRoIE1UVS4gSeKAmW0gY29tZm9ydGFibGUgd2l0aCB0ZXh0IHRvIHRoZSBl ZmZlY3QgdGhhdCBjbGllbnRzIFNIT1VMRCB0cnkgdG8gZGV0ZXJtaW5lIHBhdGggTVRVLCBhbmQg ZmFsbCBiYWNrIHRvIDUwMCBieXRlcyBpZiBpdCBjYW7igJl0IGJlIGRpc2NvdmVyZWQuDQoNCg0K SW4gMi4yLA0K4oCmIHNuaXAgLi4uDQpPUC0wMDQ6IFRoaXMgcmVxdWlyZW1lbnQgaGFzIHNldmVy YWwgaWRlYXMgaW4gaXQsIHdoaWNoIEkgdGhpbmsgc2hvdWxkIGJlIGJyb2tlbiBpbnRvIG11bHRp cGxlIHJlcXVpcmVtZW50czoNCihhKSAgICBUaGUgaWRlYSB0aGF0IG1lc3NhZ2VzIGJlIGFja25v d2xlZGdlZCB3aXRoIGEgc3RhdHVzIGNvZGUuDQotICAgICAgICAgIEJ1dCBpdCBpcyB1bmNsZWFy IHdoZXRoZXIgdGhlIHN0YXR1cyBtdXN0IGJlIGRlbGl2ZXJlZCBpbW1lZGlhdGVseSwgb3IgcmVw b3J0ZWQgbGF0ZXIuIEkgZXhwZWN0IHRoZXJlIGNvdWxkIGJlIGFuIGltbWVkaWF0ZSDigJxJIGhl YXIgeW91ciByZXF1ZXN04oCdLCB3aGljaCBkb2VzbuKAmXQgbmVjZXNzYXJpbHkgbWVhbiBhbnl0 aGluZyBjYW4gYmUgZG9uZS4gVGhlcmUgc2hvdWxkIGJlIGEgd2F5IGZvciB0aGUgY2xpZW50IHRv IGxhdGVyIGFzaywg4oCcaG93IGFyZSB5b3UgZG9pbmcgd2l0aCB0aGF0IHJlcXVlc3Q/4oCdDQoN CkkgbWVhbnQgdGhpcyB0byBiZSBsZXNzIHJlc3RyaWN0aXZlIHRoYW4gd2hhdCB5b3XigJl2ZSBk ZXNjcmliZWQuIFRoZXJlIHNob3VsZCBiZSBzb21lIHdheSBmb3IgdGhlIERPVFMgY2xpZW50IHRv IGRldGVjdCB0aGF0IGl0cyBtZXNzYWdlcyBhcmUgYmVpbmcgcmVjZWl2ZWQvcHJvY2Vzc2VkIG9y IGxvc3QsIGFuZCB0aGUgc2FtZSBpcyB0cnVlIGZvciB0aGUgRE9UUyBzZXJ2ZXIuIFRoYXQgZG9l c27igJl0IGhhdmUgdG8gbWVhbiBhbiBIVFRQLWxpa2UgbW9kZWwuIEZvciBleGFtcGxlLCBpbiB0 aGUgcHJvdG9jb2wgZHJhZnQgTmlrIFRlYWd1ZSBhbmQgSSBoYXZlIHB1dCB0b2dldGhlciwgdGhl IHNpZ25hbCBjaGFubmVsIGlzIG9uZ29pbmcsIHBlcmlvZGljIGNvbW11bmljYXRpb24gYmV0d2Vl biBjbGllbnQgYW5kIHNlcnZlci4gVGhlIGNsaWVudCBkb2VzIG5vdCBuZWVkIHRvIHNlbmQgYSBz ZXBhcmF0ZSBtZXNzYWdlIHRvIGFzayBhYm91dCByZXF1ZXN0IHN0YXR1cywgc2luY2UgdGhlIERP VFMgc2VydmVyIHdpbGwgc2VuZCBpdCBpbiBhIGZldyBzZWNvbmRzIGFueXdheS4NCg0KKGIpICAg V2hldGhlciB0aGUgc2VydmVyIE1VU1QgZG8gYXMgaXQgaXMgdG9sZC4NCi0gICAgICAgICAgT24g dGhpcyBwb2ludCwgSSB0aGluayB0aGUg4oCcTVVTVCBjZWFzZSBtaXRpZ2F0aW9uIGFjdGl2aXR5 4oCdIGlzIHdyb25nLCBzaW5jZSB0aGUgc2VydmVyIG1heSBoYXZlIG90aGVyIGV2aWRlbmNlIG9y IG90aGVyIGNsaWVudHMgcmVxdWVzdGluZyB0aGUgbWl0aWdhdGlvbi4gVGhpcyBpcyBhY2tub3ds ZWRnZWQgYnkgdGhlIOKAnG1heSBjb250aW51ZSBtaXRpZ2F0aW5n4oCdIGxhdGVyIGluIHRoZSBw YXJhZ3JhcGguIFNvIGF0IG1pbmltdW0gdGhlIE1VU1QgaXMgdG9vIHN0cm9uZy4NCg0KVGhlIGZ1 bGwgcGhyYXNlIGlzIOKAnE1VU1QgY2Vhc2UgbWl0aWdhdGlvbiBhcyBxdWlja2x5IGFzIHBvc3Np Ymxl4oCdLCBieSB3aGljaCBJIG1lYW50IHRvIGV4cHJlc3MgdGhlIGltcG9ydGFuY2Ugb2YgYWxs b3dpbmcgdGhlIHNlcnZlciB0byBtYWludGFpbiB0aGUgbWl0aWdhdGlvbiBmb3IgYSBzaG9ydCBw ZXJpb2QgdG8gcmVkdWNlIHRoZSBpbXBhY3Qgb2YgYSBET1RTIGNsaWVudCByYXBpZGx5IHRvZ2ds aW5nIG1pdGlnYXRpb24uIEl0IHNvdW5kcyBsaWtlIHRoZSBkdXJhdGlvbiBvZiB0aGF0IHNob3J0 IHBlcmlvZCBuZWVkcyB0byBiZSBkZWZpbmVkLg0KDQpJIHRoaW5rIHR3byB0aGluZ3Mgc2hvdWxk IGJlIGNsZWFyIGluIHRoZSBmaW5hbCB0ZXh0Og0KDQoxKSBUaGUgRE9UUyBjbGllbnQgY2FuIGNl YXNlIHRvIGJlIHRoZSBjYXVzZSBmb3IgYSBtaXRpZ2F0aW9uIGF0IGFueSB0aW1lIGJ5IHNlbmRp bmcgYSBtaXRpZ2F0aW9uIHRlcm1pbmF0aW9uIHJlcXVlc3QsIGJ1dCBjYW5ub3QgY29uc2lkZXIg YSBtaXRpZ2F0aW9uIHRlcm1pbmF0ZWQgdW50aWwgY29uZmlybWF0aW9uIGZyb20gdGhlIHNlcnZl ci4gKE1pdGlnYXRpb24gbGlmZXRpbWUgaXMgdGhlcmUgdG8gaGFuZGxlIHRoZSBjYXNlcyB3aGVy ZSB0aGUgc2VydmVy4oCZcyBjb25maXJtYXRpb24gaXMgbm90IGRlbGl2ZXJlZC4pDQoNCjIpIE9u Y2UgYSBET1RTIGNsaWVudCB0ZWxscyBhIERPVFMgc2VydmVyIHRvIHN0b3AgbWl0aWdhdGluZywg dGhlIERPVFMgY2xpZW50IGlzIG5vIGxvbmdlciByZXNwb25zaWJsZSBmb3IgdGhlIG1pdGlnYXRp b24uIFRoZSBET1RTIHNlcnZlci9taXRpZ2F0b3IgY2FuIGNvbnRpbnVlIG1pdGlnYXRpbmcgYXJi aXRyYXJpbHksIGJ1dCBhZnRlciB0aGUgbWl0aWdhdGlvbiB0ZXJtaW5hdGlvbiBncmFjZSBwZXJp b2QgZWxhcHNlcyBhbmQgdGhlIGNsaWVudCBoYXNu4oCZdCByZW5ld2VkIGEgcmVxdWVzdCBmb3Ig bWl0aWdhdGlvbiwgYWxsIHJlc3BvbnNpYmlsaXR5IGZvciB0aGUgbWl0aWdhdGlvbiBpcyBib3Ju ZSBieSB0aGUgRE9UUyBzZXJ2ZXIgZG9tYWluLg0KDQpPUC0wMDYuIEkgd291bGQgbGlrZSB0byBz ZWUgYWxsIG9mIHNwZWNpZmljIHNjb3BlcyBwcmVjaXNlbHkgZGVmaW5lZCBhcyByZXF1aXJlZCBv ciBvcHRpb25hbCwgYnV0IG5vdCBhcyBleGFtcGxlcy4NCg0KWWVzLCB0aGlzIGlzIGEgZ29vZCBz dWdnZXN0aW9uLg0KDQpBbHNvLCBJ4oCZbSBub3QgY2xlYXIgb24gd2hhdCBETlMgbmFtZSBmaWx0 ZXJpbmcgbWVhbnM6IGlzIHRoaXMgZm9yIGZpbHRlcmluZyBETlMgcGFja2V0cywgb3IgZm9yIGxv b2tpbmcgdXAgdGhlIG5hbWUgYW5kIGZpbHRlcmluZyB0aGUgY29ycmVzcG9uZGluZyBhZGRyZXNz ZXM/DQoNCkl04oCZcyBub3QgRE5TIG5hbWUgZmlsdGVyaW5nLCBidXQgaW5kaWNhdGluZyB3aGlj aCBGUUROcyBuZWVkIG1pdGlnYXRpb24uDQoNCg0KT1AtMDA4LiBJIGhvcGUgdGhlcmUgaXNu4oCZ dCBnb2luZyB0byBiZSBhbiBhcmd1bWVudCBhYm91dCB0aGlzLCBidXTigKYgSSBiZWxpZXZlIGl0 IGlzIG5vdCBhIGNsaWVudCBlcnJvciB0byBhc2sgZm9yIGEgbWl0aWdhdGlvbiB0aGF0IGNvbmZs aWN0cyB3aXRoIGFub3RoZXIgY2xpZW50IChob3cgY291bGQgaXQgZXZlbiBrbm93PykuIFJhdGhl ciwgaXQgaXMgdXAgdG8gdGhlIHNlcnZlciB0byB3ZWlnaCB0aGUgdmFyaW91cyByZXF1ZXN0cyBh bmQgYWN0IGZvciB0aGUgb3ZlcmFsbCBnb29kLiBBcyBwYXJhZ3JhcGggMiBvZiBzZWN0aW9uIDIg c2F5cywg4oCcRE9UUyBpcyBhbiBhZHZpc29yeSBwcm90b2NvbOKAnS4NCkkgZG9u4oCZdCBldmVu IHRoaW5rIGFuIG92ZXJsYXBwaW5nIHByZWZpeCByYW5nZSBpcyBhbiBlcnJvcjsgcmF0aGVyIGJv dGggY2xpZW50cyBoYXZlIGlkZW50aWZpZWQgdGhlIHNhbWUgYXR0YWNrLg0KDQpUaGlzIGlzIGEg ZmFpciBjb3VudGVycG9pbnQuIOKAnEFjdCBmb3IgdGhlIG92ZXJhbGwgZ29vZOKAnSBpcyB1bmZv cnR1bmF0ZWx5IG5vdCBjb25jcmV0ZSBlbm91Z2ggZm9yIGEgcmVxdWlyZW1lbnQuIENhc2VzIGxp a2UgdHdvIERPVFMgY2xpZW50cyByZXF1ZXN0aW5nIG1pdGlnYXRpb24gZm9yIHRoZSBzYW1lIHJl c291cmNlcyBhcmUgZWFzeSB0byBoYW5kbGXigJR0aGUgc2VydmVyIGp1c3QgbGV0cyB0aGUgbG9z aW5nIGNsaWVudCBrbm93IG1pdGlnYXRpb24gaXMgYWxyZWFkeSBpbiBwcm9ncmVzc+KAlGJ1dCBw YXJ0aWFsbHkgb3ZlcmxhcHBpbmcgbWl0aWdhdGlvbiByZXF1ZXN0cyBhcmUgaGFyZGVyIHRvIGhh bmRsZS4gRG9lcyB0aGUgc2VydmVyIG5vdGlmeSBlYWNoIGNsaWVudCB0aGF0IHRoZSBhY3R1YWwg bWl0aWdhdGlvbiBzY29wZSBpcyBsYXJnZXIgdGhhbiBvcmlnaW5hbGx5IHJlcXVlc3RlZD8NCg0K DQoyLjUgIC0gRGF0YSBtb2RlbCByZXF1aXJlbWVudHMNCknigJltIG5vdCBzdXJlIHdoYXQgdG8g bWFrZSBvZiB0aGlzIHNlY3Rpb24uIEkgdGhpbmsgSSBqdXN0IHdhbnQgdG8gcmV2aWV3IHRoZSBk YXRhIG1vZGVsLg0KDQpJ4oCZbSBjb21mb3J0YWJsZSBqdXN0IHJlbW92aW5nIHRoaXMgc2VjdGlv bi4gV2l0aCBGbGVtbWluZydzIGRyYWZ0IGFwcGFyZW50bHkgZXZvbHZpbmcgbW9yZSB0b3dhcmQg aW5mb3JtYXRpb24gbW9kZWwsIGRvIHdlIG5lZWQgdG8gZGlzY3VzcyBkYXRhIG1vZGVsIGF0IGFs bCBvdXRzaWRlIG9mIHRoZSBzb2x1dGlvbnMgZHJhZnRzPw0KDQphbmRyZXcNCg== --_000_C94EC833D04D49A7A13B392ACB52BF45arbornet_ Content-Type: text/html; charset="utf-8" Content-ID: <6BBBE70343C336489B8A01C26F135F41@prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhhbmtzLCBEYXZlLiBUaGlzIGlz IHZlcnkgaGVscGZ1bC4gTXkgKGV4dHJlbWVseSB0YXJkeSkgcmVzcG9uc2VzIGFyZSBpbmxpbmUu IEnigJl2ZSBzbmlwcGVkIG1vc3Qgb2YgdGhlIG1pbm9yIHJlcGhyYXNpbmcgc3VnZ2VzdGlvbnMu IEFsbCBjb21tZW50cyBhcmUgbWUgc3BlYWtpbmcgZm9yIG15c2VsZiwgbm90IG5lY2Vzc2FyaWx5 IGZvciB0aGUgb3RoZXIgcmVxdWlyZW1lbnRzIGRyYWZ0IGVkaXRvcnMuDQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J4oCZdmUgb3BlbmVkIGlzc3Vl cyBvbiBnaXRodWIgZm9yIG1vc3Qgb2YgdGhlc2UgY29tbWVudHMuPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE5vdiAyNiwgMjAxNiwgYXQgOToz MSBQTSwgRGF2ZSBEb2xzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNv bSIgY2xhc3M9IiI+ZGRvbHNvbkBzYW5kdmluZS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxi ciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0K4oCmc25pcC4u LjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQoxLjI8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQrigKZzbmlwLi4uPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4NCkZvciDigJxjb3VudGVybWVhc3VyZeKAnSwgdGhpcyBzb3VuZHMg bGlrZSBvbmx5IHBhY2tldCBmaWx0ZXJpbmcuIElzIHRoYXQgYWNjdXJhdGUgYW5kIGNvbXBsZXRl PyBDb3VsZCB0YXItcGl0IG9yIHJvdXRpbmcgY2hhbmdlcyBiZSBpbmNsdWRlZCBpbiBjb3VudGVy bWVhc3VyZXM/PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SSBkb27igJl0IHdhbnQgdGhlIGRvY3VtZW50IHRvIHJl c3RyaWN0IHRoZSBkZWZpbml0aW9uIG9mIGNvdW50ZXJtZWFzdXJlLCBidXQgSeKAmW0gYWxzbyBu b3Qga2VlbiB0byBlbnNocmluZSBzcGVjaWZpYyB0eXBlcyBvZiBjb3VudGVybWVhc3VyZSwgZWl0 aGVyLiBJ4oCZbGwgcmV2aXNlIHRvIG1ha2UgaXQgY2xlYXJlci48L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KSXMg4oCcc2ln bmFsIGNoYW5uZWzigJ0gaW50ZW5kZWQgdG8gYmUgdGhlIHNhbWUgdGhpbmcgYXMgdGhlIOKAnHNl c3Npb27igJ0gbWVudGlvbmVkIGluIHRoZSBhcmNoaXRlY3R1cmU/IEkgdGhpbmsgc28sIGFuZCB0 ZXJtaW5vbG9neSBzaG91bGQgYmUgbWFkZSBjb25zaXN0ZW50IGJldHdlZW4gdGhlIGRvY3MuIElm IG5vdCwgSSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBjaGFubmVs IGFuZCBzZXNzaW9uLjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdj5TcGVha2luZyBmb3IgbXlzZWxmLCB0aGUg4oCcY2hhbm5lbOKA nSBkaXN0aW5jdGlvbiBpcyBtZWFudCB0byBkaXN0aW5ndWlzaCB0aGUgdW5yZWxpYWJsZSwgbGln aHR3ZWlnaHQgU09TIG1lc3NhZ2VzIHRvIGJlIHVzZWQgd2hlbiB1bmRlciBhdHRhY2sgZnJvbSB0 aGUgcmVsaWFibGUgbWVzc2FnaW5nIHJlcXVpcmVkIHRvIGUuZy4gbWFuYWdlIGZpbHRlcnMgYW5k IHJlc291cmNlIGFsaWFzZXMuIFRoZSDigJxzaWduYWxpbmcgc2Vzc2lvbuKAnSBpbiB0aGUNCiBh cmNoaXRlY3R1cmUgZG9jdW1lbnQgaXMgYWN0aXZlIG1lc3NhZ2luZyBiZXR3ZWVuIERPVFMgYWdl bnRzIG92ZXIgdGhlIHNpZ25hbCBjaGFubmVsLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0 eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NClNob3VsZCDigJxG aWx0ZXLigJ0gYmUgbGltaXRlZCB0byB0aGUgdHdvIGFjdGlvbnMgb2YgcmF0ZS1saW1pdGluZyBv ciBkaXNjYXJkaW5nPyZuYnNwOyBJcyBmaWx0ZXIgcmVhbGx5IGludGVuZGVkIHRvIGluY2x1ZGUg YWN0aW9uLCBvciBqdXN0IHRoZSBtYXRjaCBjcml0ZXJpYT88L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SXQgc291bmRzIGxpa2Ug eW914oCZcmUgcmVhbGx5IGFza2luZyB3aGV0aGVyIHdlIHNob3VsZCBsZWF2ZSB0aGUgZGVmaW5p dGlvbiBvZiDigJxmaWx0ZXJpbmfigJ0gdXAgdG8gdGhlIERPVFMgc2VydmVyL21pdGlnYXRvci4g SSB3b3JyeSB0aGF0IGxlYXZpbmcg4oCcZmlsdGVyaW5n4oCdIGxvb3NlbHkgZGVmaW5lZCB3aWxs IGxlYWQgdG8gY29uZnVzaW9uIGZ1cnRoZXIgZG93biB0aGUgbGluZS4gSSB0aGluayB3ZSBuZWVk IGV4cGxpY2l0IGFjdGlvbnM6DQogZGlzY2FyZCBpcyB2ZXJ5IGRpZmZlcmVudCBmcm9tIHJhdGUt bGltaXQuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5BcyBJIHNlZSBp dCwgZmlsdGVyaW5nIGlzIGRpc3RpbmN0IGZyb20gdmVuZG9yIGV4dGVuc2lvbnMgd2hpY2ggbWln aHQgaW5jbHVkZSBjb3VudGVybWVhc3VyZSBzcGVjaWZpY3MuIEkgZG9u4oCZdCB0aGluayBET1RT IGlzIGEgZ2VuZXJhbCBwdXJwb3NlIGludGVyZmFjZSBmb3IgY291bnRlcm1lYXN1cmUgY29uZmln dXJhdGlvbi48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBh Z2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NClNpbWlsYXJseSBmb3Ig4oCcQmxhY2tsaXN0 4oCdOiBpcyBibG9jayB0aGUgb25seSB2YWxpZCBhY3Rpb24gZm9yIGJsYWNrLWxpc3RlZCBhZGRy ZXNzZXM/PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2PlllcywgdGhhdOKAmXMgdGhlIGRpc3Rpbmd1aXNoaW5nIGNoYXJhY3Rlcmlz dGljIG9mIGEgYmxhY2tsaXN0ZWQgc291cmNlLiBBIHdoaXRlbGlzdGVkIHNvdXJjZSBpcyBhbHdh eXMgYWxsb3dlZCB0byBwYXNzLiBUaGUgRE9UUyBjbGllbnQgaGFzIGZ1bGwgY29udHJvbCBvdmVy IHRoZSBibGFjay0vd2hpdGUtbGlzdHMsIHRob3VnaCB0aGUgc2NvcGUgaXMgcmVzdHJpY3RlZCBi eSB0aGUgRE9UUyBzZXJ2ZXIgdG8gcHJlZml4ZXMvcmVzb3VyY2VzDQogYmVsb25naW5nIHRvIHRo ZSBET1RTIGNsaWVudC48L2Rpdj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBh Z2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9 InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4NCjIuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KVGhlIHNlY29uZCBwYXJhZ3JhcGgg c2F5cyDigJxET1RTIGlzIGFuIGFkdmlzb3J5IHByb3RvY29sLuKAnSBJIHRob3VnaHQgdGhpcyBt aWdodCBtZWFuIHRoYXQgKGEpIGEgY2xpZW504oCZcyByZXF1ZXN0IGZvciBhaWQgbWF5IGJlIGln bm9yZWQgYW5kIChiKSBtaXRpZ2F0aW9uIG1heSBiZSBkb25lIHByaW9yIHRvIHJlcXVlc3Qgb3Ig YWZ0ZXIgd2l0aGRyYXdhbC4gV291bGQgdGhhdCBpZGVhIGJlIGFjY3VyYXRlPzwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JIHRo aW5rIChhKSBpcyBjb3JyZWN0LCB0aG91Z2ggaWdub3JpbmcgYSByZXF1ZXN0IHdpdGhvdXQgcHJv dmlkaW5nIGEgcmVhc29uIHdoZW4gYSBzZXJ2aWNlIGFncmVlbWVudCBpcyBpbiBwbGFjZSBzZWVt cyBsaWtlIGEgcG9vciB3YXkgdG8gbWFuYWdlIGEgc2VydmljZS4gSW4gZ2VuZXJhbCBhIERPVFMg cmVxdWVzdCBmb3IgbWl0aWdhdGlvbiBzaG91bGQgcmVzdWx0IGluIG1pdGlnYXRpb24sIGFzc3Vt aW5nIGJ1c2luZXNzIG9yIHNlcnZpY2UNCiBhZ3JlZW1lbnRzIGFyZSBpbiBwbGFjZSwgYnV0IG1p dGlnYXRpbmcgdGhlIGF0dGFjayBtaWdodCBpbnZvbHZlIG1vcmUgdGhhbiBqdXN0IGEmbmJzcDs8 L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkluIGNhbGxpbmcgRE9UUyDi gJxhZHZpc29yeeKAnSBJIHdhcyB0cnlpbmcgdG8gZW1waGFzaXplIHR3byBwb2ludHM6IHRoZSBk aWZmaWN1bHR5IG9mIG1haW50YWluaW5nIHJlbGlhYmxlIG1lc3NhZ2luZyB1bmRlciBhdHRhY2sg Y29uZGl0aW9ucyAod2l0aCB0aGUgY29yb2xsYXJ5IHRoYXQgYSBET1RTIHNlcnZlciBtYXkgbm90 IGJlIGFibGUgdG8gaGVscCBldmVuIGlmIGEgcmVxdWVzdCBnZXRzIHRocm91Z2gpOyBhbmQgdGhl IGZhY3QgdGhhdA0KIERPVFMgaXMgbm90IGEgZ2VuZXJhbCBwdXJwb3NlIG1pdGlnYXRpb24gQVBJ LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+TWF5YmUgSSBzaG91bGQg Y2xhcmlmeSB0aGF0IGZ1cnRoZXIuIEkgYmVsaWV2ZSB0aGUgRE9UUyAqc2lnbmFsIGNoYW5uZWwq IGlzIG5vdCBhIGdlbmVyYWwgcHVycG9zZSBtaXRpZ2F0aW9uIEFQSS4gVGhlIERPVFMgZGF0YSBj aGFubmVsIGNvdWxkIGV2b2x2ZSBpbnRvIHRoYXQgYXMgYSBzb3J0IG9mIERPVFMgY29udHJvbCBw cm90b2NvbCwgaW4gd2hpY2ggdGhlIGltcGFjdCBvZiBhbiBhdHRhY2sgb24gdGhlIGNvbW11bmlj YXRpb24gbGF5ZXINCiBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyIGlzIG5vdCBhIGNvbmNlcm4u PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBX b3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQooTXkgdGhpbmtpbmcgaXMgdGhhdCBhIERPVFMgc2VydmVyIG1heSBrbm93IGJl dHRlciB0aGFuIHRoZSBjbGllbnQgYmFzZWQgb24gYSB3aWRlciBzb3VyY2Ugb2YgdGVsZW1ldHJ5 Lik8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdj5BZ3JlZWQuIE9uY2UgYSBtaXRpZ2F0b3IgYmVnaW5zIGZpbHRlcmlu ZyB0cmFmZmljIGJvdW5kIGZvciB0aGUgZG9tYWluIG9mIHRoZSBET1RTIGNsaWVudCwgdGhlIERP VFMgY2xpZW504oCZcyB2aWV3IGludG8gdGhlIGF0dGFjayBpcyBza2V3ZWQuPC9kaXY+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBz dHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KLSBpbiBHRU4tMDA0LCBjb25z aWRlciBwaWNraW5nIGEgc3BlY2lmaWMgTVRVIHNpemUsIGxpa2UgNTAwIGJ5dGVzLCBiZWNhdXNl IG90aGVyd2lzZSB0aGVyZSBpcyBubyB3YXkgdG8ganVkZ2UgaWYgdGhlIHByb3RvY29sIG1lZXRz IHJlcXVpcmVtZW50cy48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBoYXMgYmVjb21lIG1vcmUgaW1wb3J0YW50IHNpbmNl IHlvdSBzdWdnZXN0ZWQgaXQsIGluIGxpZ2h0IG9mIHRoZSByZWNlbnQgdGhyZWFkIG9uIHRlbGVt ZXRyeS4gZHJhZnQtcmVkZHktZG90cy1zaWduYWwtY2hhbm5lbCBpcyBzdWdnZXN0aW5nIDUwMCBi eXRlcyBpbiB0aGUgZXZlbnQgdGhlIGNsaWVudCBjYW7igJl0IGRpc2Nlcm4gcGF0aCBNVFUuIEni gJltIGNvbWZvcnRhYmxlIHdpdGggdGV4dCB0byB0aGUgZWZmZWN0IHRoYXQgY2xpZW50cw0KIFNI T1VMRCB0cnkgdG8gZGV0ZXJtaW5lIHBhdGggTVRVLCBhbmQgZmFsbCBiYWNrIHRvIDUwMCBieXRl cyBpZiBpdCBjYW7igJl0IGJlIGRpc2NvdmVyZWQuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29y ZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KSW4gMi4yLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCuKApiBzbmlwIC4u LjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0 aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NCk9QLTAwNDogVGhpcyByZXF1aXJlbWVudCBoYXMgc2V2ZXJhbCBpZGVhcyBpbiBpdCwgd2hp Y2ggSSB0aGluayBzaG91bGQgYmUgYnJva2VuIGludG8gbXVsdGlwbGUgcmVxdWlyZW1lbnRzOjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQgMC41aW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IHRleHQtaW5kZW50OiAtMC4yNWluOyIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj4o YSk8c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48L3NwYW4+VGhlIGlkZWEgdGhhdCBtZXNzYWdlcw0KIGJlIGFja25vd2xlZGdlZCB3 aXRoIGEgc3RhdHVzIGNvZGUuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdCAwLjc1aW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IHRleHQtaW5kZW50OiAtMC4yNWluOyIgY2xhc3M9 IiI+DQo8c3BhbiBjbGFzcz0iIj4tPHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3 cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsi IGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PC9zcGFuPkJ1dCBpdCBpcyB1bmNsZWFyDQogd2hldGhlciB0aGUgc3RhdHVzIG11c3Qg YmUgZGVsaXZlcmVkIGltbWVkaWF0ZWx5LCBvciByZXBvcnRlZCBsYXRlci4gSSBleHBlY3QgdGhl cmUgY291bGQgYmUgYW4gaW1tZWRpYXRlIOKAnEkgaGVhciB5b3VyIHJlcXVlc3TigJ0sIHdoaWNo IGRvZXNu4oCZdCBuZWNlc3NhcmlseSBtZWFuIGFueXRoaW5nIGNhbiBiZSBkb25lLiBUaGVyZSBz aG91bGQgYmUgYSB3YXkgZm9yIHRoZSBjbGllbnQgdG8gbGF0ZXIgYXNrLCDigJxob3cgYXJlIHlv dSBkb2luZyB3aXRoDQogdGhhdCByZXF1ZXN0P+KAnTwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JIG1lYW50IHRoaXMgdG8gYmUg bGVzcyByZXN0cmljdGl2ZSB0aGFuIHdoYXQgeW914oCZdmUgZGVzY3JpYmVkLiBUaGVyZSBzaG91 bGQgYmUgc29tZSB3YXkgZm9yIHRoZSBET1RTIGNsaWVudCB0byBkZXRlY3QgdGhhdCBpdHMgbWVz c2FnZXMgYXJlIGJlaW5nIHJlY2VpdmVkL3Byb2Nlc3NlZCBvciBsb3N0LCBhbmQgdGhlIHNhbWUg aXMgdHJ1ZSBmb3IgdGhlIERPVFMgc2VydmVyLiBUaGF0IGRvZXNu4oCZdCBoYXZlIHRvIG1lYW4g YW4gSFRUUC1saWtlDQogbW9kZWwuIEZvciBleGFtcGxlLCBpbiB0aGUgcHJvdG9jb2wgZHJhZnQg TmlrIFRlYWd1ZSBhbmQgSSBoYXZlIHB1dCB0b2dldGhlciwgdGhlIHNpZ25hbCBjaGFubmVsIGlz IG9uZ29pbmcsIHBlcmlvZGljIGNvbW11bmljYXRpb24gYmV0d2VlbiBjbGllbnQgYW5kIHNlcnZl ci4gVGhlIGNsaWVudCBkb2VzIG5vdCBuZWVkIHRvIHNlbmQgYSBzZXBhcmF0ZSBtZXNzYWdlIHRv IGFzayBhYm91dCByZXF1ZXN0IHN0YXR1cywgc2luY2UgdGhlIERPVFMgc2VydmVyDQogd2lsbCBz ZW5kIGl0IGluIGEgZmV3IHNlY29uZHMgYW55d2F5LjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi IHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0IDAuNzVpbjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgdGV4dC1pbmRlbnQ6IC0wLjI1aW47IiBjbGFzcz0iIj4NCjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQgMC41aW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IHRleHQtaW5kZW50OiAtMC4yNWluOyIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj4o Yik8c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+Jm5ic3A7Jm5i c3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48L3NwYW4+V2hldGhlciB0aGUgc2VydmVyDQogTVVTVCBkbyBhcyBpdCBpcyB0b2xkLjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQgMC43NWluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyB0ZXh0LWluZGVudDogLTAuMjVpbjsiIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+LTxz cGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFs OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvc3Bhbj5PbiB0aGlzIHBv aW50LA0KIEkgdGhpbmsgdGhlIOKAnE1VU1QgY2Vhc2UgbWl0aWdhdGlvbiBhY3Rpdml0eeKAnSBp cyB3cm9uZywgc2luY2UgdGhlIHNlcnZlciBtYXkgaGF2ZSBvdGhlciBldmlkZW5jZSBvciBvdGhl ciBjbGllbnRzIHJlcXVlc3RpbmcgdGhlIG1pdGlnYXRpb24uIFRoaXMgaXMgYWNrbm93bGVkZ2Vk IGJ5IHRoZSDigJxtYXkgY29udGludWUgbWl0aWdhdGluZ+KAnSBsYXRlciBpbiB0aGUgcGFyYWdy YXBoLiBTbyBhdCBtaW5pbXVtIHRoZSBNVVNUIGlzIHRvbyBzdHJvbmcuPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoZSBmdWxs IHBocmFzZSBpcyDigJxNVVNUIGNlYXNlIG1pdGlnYXRpb24gYXMgcXVpY2tseSBhcyBwb3NzaWJs ZeKAnSwgYnkgd2hpY2ggSSBtZWFudCB0byBleHByZXNzIHRoZSBpbXBvcnRhbmNlIG9mIGFsbG93 aW5nIHRoZSBzZXJ2ZXIgdG8gbWFpbnRhaW4gdGhlIG1pdGlnYXRpb24gZm9yIGEgc2hvcnQgcGVy aW9kIHRvIHJlZHVjZSB0aGUgaW1wYWN0IG9mIGEgRE9UUyBjbGllbnQgcmFwaWRseSB0b2dnbGlu ZyBtaXRpZ2F0aW9uLiBJdCBzb3VuZHMNCiBsaWtlIHRoZSBkdXJhdGlvbiBvZiB0aGF0IHNob3J0 IHBlcmlvZCBuZWVkcyB0byBiZSBkZWZpbmVkLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXY+SSB0aGluayB0d28gdGhpbmdzIHNob3VsZCBiZSBjbGVhciBpbiB0aGUgZmlu YWwgdGV4dDo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxzcGFuIGNs YXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPjEpIFRo ZSBET1RTIGNsaWVudCBjYW4gY2Vhc2UgdG8gYmUgdGhlIGNhdXNlIGZvciBhIG1pdGlnYXRpb24g YXQgYW55IHRpbWUgYnkgc2VuZGluZyBhIG1pdGlnYXRpb24gdGVybWluYXRpb24gcmVxdWVzdCwg YnV0IGNhbm5vdCBjb25zaWRlciBhIG1pdGlnYXRpb24gdGVybWluYXRlZCB1bnRpbCBjb25maXJt YXRpb24gZnJvbSB0aGUgc2VydmVyLg0KIChNaXRpZ2F0aW9uIGxpZmV0aW1lIGlzIHRoZXJlIHRv IGhhbmRsZSB0aGUgY2FzZXMgd2hlcmUgdGhlIHNlcnZlcuKAmXMgY29uZmlybWF0aW9uIGlzIG5v dCBkZWxpdmVyZWQuKTwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+PHNw YW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+ MikmbmJzcDtPbmNlIGEgRE9UUyBjbGllbnQgdGVsbHMgYSBET1RTIHNlcnZlciB0byBzdG9wIG1p dGlnYXRpbmcsIHRoZSBET1RTIGNsaWVudCBpcyBubyBsb25nZXIgcmVzcG9uc2libGUgZm9yIHRo ZSBtaXRpZ2F0aW9uLiBUaGUgRE9UUyBzZXJ2ZXIvbWl0aWdhdG9yIGNhbiBjb250aW51ZSBtaXRp Z2F0aW5nIGFyYml0cmFyaWx5LCBidXQgYWZ0ZXINCiB0aGUgbWl0aWdhdGlvbiB0ZXJtaW5hdGlv biBncmFjZSBwZXJpb2QgZWxhcHNlcyBhbmQgdGhlIGNsaWVudCBoYXNu4oCZdCByZW5ld2VkIGEg cmVxdWVzdCBmb3IgbWl0aWdhdGlvbiwgYWxsIHJlc3BvbnNpYmlsaXR5IGZvciB0aGUgbWl0aWdh dGlvbiBpcyBib3JuZSBieSB0aGUgRE9UUyBzZXJ2ZXIgZG9tYWluLjwvZGl2Pg0KPGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0IDAuNzVpbjsgZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgdGV4dC1pbmRlbnQ6IC0wLjI1aW47IiBjbGFz cz0iIj4NCjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NCk9QLTAwNi4gSSB3b3VsZCBsaWtlIHRvIHNlZSBhbGwgb2Yg c3BlY2lmaWMgc2NvcGVzIHByZWNpc2VseSBkZWZpbmVkIGFzIHJlcXVpcmVkIG9yIG9wdGlvbmFs LCBidXQgbm90IGFzIGV4YW1wbGVzLjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5ZZXMsIHRoaXMgaXMgYSBnb29kIHN1Z2dlc3Rp b24uPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsg Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCkFsc28sIEnigJltIG5vdCBjbGVhciBvbiB3aGF0IEROUyBuYW1lIGZpbHRl cmluZyBtZWFuczogaXMgdGhpcyBmb3IgZmlsdGVyaW5nIEROUyBwYWNrZXRzLCBvciBmb3IgbG9v a2luZyB1cCB0aGUgbmFtZSBhbmQgZmlsdGVyaW5nIHRoZSBjb3JyZXNwb25kaW5nIGFkZHJlc3Nl cz88L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXY+SXTigJlzIG5vdCBETlMgbmFtZSBmaWx0ZXJpbmcsIGJ1dCBpbmRpY2F0aW5nIHdo aWNoIEZRRE5zIG5lZWQgbWl0aWdhdGlvbi48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHls ZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8 L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0K T1AtMDA4LiBJIGhvcGUgdGhlcmUgaXNu4oCZdCBnb2luZyB0byBiZSBhbiBhcmd1bWVudCBhYm91 dCB0aGlzLCBidXTigKYgSSBiZWxpZXZlIGl0IGlzIG5vdCBhIGNsaWVudCBlcnJvciB0byBhc2sg Zm9yIGEgbWl0aWdhdGlvbiB0aGF0IGNvbmZsaWN0cyB3aXRoIGFub3RoZXIgY2xpZW50IChob3cg Y291bGQgaXQgZXZlbiBrbm93PykuJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsi IGNsYXNzPSIiPlJhdGhlciwgaXQgaXMgdXAgdG8gdGhlIHNlcnZlcg0KIHRvIHdlaWdoIHRoZSB2 YXJpb3VzIHJlcXVlc3RzIGFuZCBhY3QgZm9yIHRoZSBvdmVyYWxsIGdvb2QuIEFzIHBhcmFncmFw aCAyIG9mIHNlY3Rpb24gMiBzYXlzLCDigJxET1RTIGlzIGFuIGFkdmlzb3J5IHByb3RvY29s4oCd Ljwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBX b3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpJIGRvbuKAmXQgZXZlbiB0aGluayBhbiBvdmVybGFw cGluZyBwcmVmaXggcmFuZ2UgaXMgYW4gZXJyb3I7IHJhdGhlciBib3RoIGNsaWVudHMgaGF2ZSBp ZGVudGlmaWVkIHRoZSBzYW1lIGF0dGFjay48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBpcyBhIGZhaXIgY291bnRlcnBv aW50LiDigJxBY3QgZm9yIHRoZSBvdmVyYWxsIGdvb2TigJ0gaXMgdW5mb3J0dW5hdGVseSBub3Qg Y29uY3JldGUgZW5vdWdoIGZvciBhIHJlcXVpcmVtZW50LiBDYXNlcyBsaWtlIHR3byBET1RTIGNs aWVudHMgcmVxdWVzdGluZyBtaXRpZ2F0aW9uIGZvciB0aGUgc2FtZSByZXNvdXJjZXMgYXJlIGVh c3kgdG8gaGFuZGxl4oCUdGhlIHNlcnZlciBqdXN0IGxldHMgdGhlIGxvc2luZyBjbGllbnQga25v dyBtaXRpZ2F0aW9uDQogaXMgYWxyZWFkeSBpbiBwcm9ncmVzc+KAlGJ1dCBwYXJ0aWFsbHkgb3Zl cmxhcHBpbmcgbWl0aWdhdGlvbiByZXF1ZXN0cyBhcmUgaGFyZGVyIHRvIGhhbmRsZS4gRG9lcyB0 aGUgc2VydmVyIG5vdGlmeSBlYWNoIGNsaWVudCB0aGF0IHRoZSBhY3R1YWwgbWl0aWdhdGlvbiBz Y29wZSBpcyBsYXJnZXIgdGhhbiBvcmlnaW5hbGx5IHJlcXVlc3RlZD8mbmJzcDs8L2Rpdj4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi IHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQoyLjU8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDsgLSBEYXRhIG1vZGVsIHJlcXVpcmVtZW50czwvc3Bhbj48bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+DQpJ4oCZbSBub3Qgc3VyZSB3aGF0IHRvIG1ha2Ugb2YgdGhpcyBzZWN0aW9uLiBJIHRoaW5r IEkganVzdCB3YW50IHRvIHJldmlldyB0aGUgZGF0YSBtb2RlbC48L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SeKAmW0gY29tZm9y dGFibGUganVzdCByZW1vdmluZyB0aGlzIHNlY3Rpb24uIFdpdGggRmxlbW1pbmcncyBkcmFmdCBh cHBhcmVudGx5IGV2b2x2aW5nIG1vcmUgdG93YXJkIGluZm9ybWF0aW9uIG1vZGVsLCBkbyB3ZSBu ZWVkIHRvIGRpc2N1c3MgZGF0YSBtb2RlbCBhdCBhbGwgb3V0c2lkZSBvZiB0aGUgc29sdXRpb25z IGRyYWZ0cz88L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PmFuZHJldzwv ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_C94EC833D04D49A7A13B392ACB52BF45arbornet_-- From nobody Mon Feb 20 22:59:28 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18FF1289B0 for ; Mon, 20 Feb 2017 22:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 jZCNScARSIHf for ; Mon, 20 Feb 2017 22:59:20 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3ED129872 for ; Mon, 20 Feb 2017 22:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=69169; q=dns/txt; s=iport; t=1487660360; x=1488869960; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pVmgaEcWiQry0tzOhtzCmvDJx/sDG2bSqAj0jmI1I3c=; b=a5mxTRutovtyWUU+m2rDoHw5a+I630HIRyM+vaLG0nMoFjJ1gdB1Y/sZ HxH0qiYIWCmRN27qIK7MUMtgMe9Quqf0BfTi1S27sBAWMXcReVbJX+qc5 4Mh+wQqT5ZBGMp9y70f/J+wTtODPvxJA2X/9pxvLR6OptL5aL7awtGOeZ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQAd5KtY/4cNJK1VCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvOSlhgQkHjVySFpU0ggoDHwEKhXgCglQ/GAECAQEBAQEBAWI?= =?us-ascii?q?ohHABAQEEAQEYARJBBAcQAgEIEQQBASEBAgQHJwsUCQgCBAENBQgRiVUOsEYri?= =?us-ascii?q?y0BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZMhG+EJwYDAQ0dByiFLwWPSYYXhig?= =?us-ascii?q?BhnODIYd/ggSFG4l4iDSKbwEfOIEAUxU+hEodGYFIdQGIUgEBJAeBA4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,188,1484006400"; d="scan'208,217";a="386390026" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Feb 2017 06:59:17 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v1L6xHA4012792 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Feb 2017 06:59:17 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Feb 2017 00:59:15 -0600 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1210.000; Tue, 21 Feb 2017 00:59:15 -0600 From: "Tirumaleswar Reddy (tireddy)" To: kaname nishizuka , Ehud Doron , "'dots'" Thread-Topic: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . Thread-Index: AdKCER/slEaaT/pbTQCa8ffUgEh/YgEwQ2SQACwcrIAAG9DI0AAafbSAAAQXagAAJ2DGgAABf9DQ Date: Tue, 21 Feb 2017 06:59:15 +0000 Message-ID: <675dbf9cd1134c47847cdb22602c8904@XCH-ALN-017.cisco.com> References: <73716c67d08b4de5b8e6df1394da199f@XCH-RCD-017.cisco.com> <0dd8cd77a95f45aabcc64e30ef0bcd06@XCH-RCD-017.cisco.com> <2c809b8c-d7f7-ea38-d0eb-02a78fca4a15@nttv6.jp> In-Reply-To: <2c809b8c-d7f7-ea38-d0eb-02a78fca4a15@nttv6.jp> 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.52.121] Content-Type: multipart/alternative; boundary="_000_675dbf9cd1134c47847cdb22602c8904XCHALN017ciscocom_" MIME-Version: 1.0 Archived-At: Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 21 Feb 2017 06:59:25 -0000 --_000_675dbf9cd1134c47847cdb22602c8904XCHALN017ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see inline [TR3] From: kaname nishizuka [mailto:kaname@nttv6.jp] Sent: Friday, February 17, 2017 10:07 AM To: Tirumaleswar Reddy (tireddy) ; Ehud Doron ; 'dots' Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 . Hi Tiru, Thanks for your response and clarifications. Please see my response inline[kaname2] On 2017/02/16 21:09, Tirumaleswar Reddy (tireddy) wrote: Hi Kaname, Please see inline [TR2] From: kaname nishizuka [mailto:kaname@nttv6.jp] Sent: Thursday, February 16, 2017 1:22 PM To: Tirumaleswar Reddy (tireddy) ; Ehud Doron ; 'dots' Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 . Hi Tiru, please see inline. On 2017/02/16 13:18, Tirumaleswar Reddy (tireddy) wrote: Hi Kaname, Please see inline [TR] for responses From: kaname nishizuka [mailto:kaname@nttv6.jp] Sent: Wednesday, February 15, 2017 11:27 AM To: Tirumaleswar Reddy (tireddy) ; Ehud Doron ; 'dots' Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 . Hi Tiru, I really appreciate your time and effort. Please see my comments on the drafts. # draft-reddy-dots-signal-channel-07 1. [General] I believe that DOTS request should not be another tool of bloc= king other one's traffic. Is there any validation mechanism of requested ta= rget-ips, target-ports and target-protocols? Even If it is out side of the = DOTS specification, how about returning 4.xx codes when the requested targe= t-* is not a property of the organization. [TR] The validation scope is outside the scope of this draft, 4.xx error co= de is already used in the draft to identity invalid requests. [kaname]OK, understood. 2. [page14] Does one DOTS client and DOTS server peer have only one signal = channel and one data channel? (I'm thinking about a namespace of the "alias= -name") [TR] No, DOTS peers can have more than one signal and data channel but the = recommendation is to use only signal and data channel to reduce connection = setup delay. [kaname] If there are more than one signal and data channel, how can they c= oupled? [TR2] DOTS client authenticate to the DOTS server (see https://tools.ietf.o= rg/html/draft-reddy-dots-signal-channel-07#page-35), the DOTS server knows = the DOTS client identity to couple the signal and data channel sessions. [kaname2] I see. Could I confirm that my understanding is right. The signal and data channel sessions are coupled based on the client certif= ication. So, the same client certification should be used among (D)TLS in s= ignal channel session and TLS in data channel session. [TR3] Yes. If so, how about writing it explicitly in the main part of [draft-reddy-dot= s-data-channel-04]? Now, mutual authentication is described only in 6. Secu= rity Considerations. [TR3] Good point, will update signal channel draft how signal and data chan= nel sessions are coupled using DOTS client identity. NEW: In both DOTS signal and data channel sessions, the DOTS client MUST authenticate itself to the DOTS server (Section 9). The DOTS server couples the DOTS signal and data channel sessions using the DOTS client identity, so the DOTS server can validate whether the aliases conveyed in the mitigation request were indeed created by the same DOTS client using the DOTS data channel session. If the aliases were not created by the DOTS client then the DOTS server returns 4.00 (Bad Request) in the response. One DOTS server will accommodate more than one DOTS client, so is there any= way to know which data channel is belong to which signal channel? Source I= P? I recommend to use only one signal and data channel per one DOTS peer, too. If their are multiple data channels, "DOTS signal" in Fig.5 should specify = according data channel when it refers to "alias-names" of the identifiers. [TR] I did not get the comment. [kaname] Different DOTS clients will be belonging to different customers(or= ganizations). So I think there is a chance of requesting the same "alias-names" from diff= erent customers. Then, will the DOTS server reject conflicted "alias-names" between differen= t customers? [TR] No. or keep them with prefixes like customerA: and customerB:<= same-alias-name> internally? Also, customerA should not use an alias-name o= f customerB. How can the DOTS server check that. [TR2] Same response as above. Aliases do not have global scope, they are sp= ecific to a DOTS client (DOTS server knows the DOTS client identity). [kaname2]OK, I understood. 3. [Page21] How about adding status of "mitigation delete is in progress" l= ike status:1. Here is a life cycle of a mitigation in our environment. Activating and= deleting of mitigation could take several seconds (or minutes). POST. - activating(status=3D1) STATUS AFTER ACTIVATED - attack mitigated (status=3D2) - attack stopped (status=3D3) - attack exceeded capability(status=3D4) DELETE - deleting(status=3D5?) - deleted(RETURN 4.04) [TR] Delete is a confirmable message, DOTS server will send an ACK to ackno= wledge the receipt of the message to avoid retransmissions from the DOTS cl= ient. After the mitigation request is successfully deleted, DOTS server ret= urns 2.02 (Deleted) response code, thus conveying the transient status in t= his case is not necessary. [kaname] As I noted, deleting of mitigation could take several seconds (or = minutes) in real-life. [TR2] Yes, but the DOTS server immediately sends a ACK (acknowledging the r= eceipt of the DELETE message), thus the DOTS client knows the server has re= ceived the Delete request and is processing the request. After deleting the= mitigation (may take several seconds), server sends 2.02 (Delete) response= code. I don't see a problem. -Tiru [kaname2] The same story could be applied to the status:1 (Attack mitigatio= n is in progress) [TR3] No, the DOTS client needs to know the mitigation status and DDOS atta= ck status so that it can withdraw the mitigation request when the DDOS atta= ck stops (see Section 5.3.3.1) and to know whether the DOTS mitigation prov= ider is able to successfully mitigate the attack or is re-directing the cli= ent to an alternate DOTS server. These unsolicited notifications are not required for withdraw because after= validating the DELETE request DOTS server immediately send an ACK or retur= ns an error that the DELETE request was invalid and it is DOTS server respo= nsibility to withdraw the mitigation request from the DDOS mitigator(s) (wh= ich may take several seconds). -Tiru thank you, Kaname If the DOTS client retrieve the status while that time, getting "deleting s= tatus", not "2.02 status", will help operators. 4. [Page25] 5.4 b) I couldn't find "retransmission timeout value" attribute= in the later figures. Is that equivalent to "ack-timeout"? [TR] The initial retransmission timeout value is based on the ack-timeout (= see https://tools.ietf.org/html/rfc7252#section-4.2). [kaname] Thank you, I found the reference. 5. [Page27] "policy-id" in "signal-config" is different from "policy-id" in= "mitigation-scole". How about using "session-id" in this case? [TR] Policy-id is a unique identifier identifying the signal channel sessio= n configuration request. [kaname] "policy-id" in Fig.9 and Fig.15 are totally different. I've got co= nfused when reading the draft because they have the same name. # draft-reddy-dots-data-channel-03 1. [General] Data channel doesn't have heartbeat mechanism. I guess the rea= son is that there is heartbeat mechanism in the signal channel so it is eno= ugh, is that right? [TR] No, the heartbeat mechanism in signal channel cannot be used for data = channel. DOTS signal channel is using the "CoAP ping mechanism". For data c= hannel, TLS heartbeat can be used. I have updated draft. [kaname] OK. I'll see updated draft. 2. [related to Ehud's question 8] I-D.ietf-netmod-acl-model says "ACL is an= ordered list of Access List Entries (ACE)" but I couldn't find a text abou= t how they are ordered. Should we have a operation of changing the order of= ACEs installed in a DOTS server? [TR] PUT can be used by the DOTS client to re-order/update/modify the list = of ACE conveyed to the DOTS server. Updated draft to discuss about PUT. [kaname] OK. I'll see updated draft. thank you, kaname -Tiru thank you, Kaname On 2017/02/14 23:58, Tirumaleswar Reddy (tireddy) wrote: Hi Ehud, Please see inline for responses to comments on draft-reddy-dots-data-channe= l-03 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron Sent: Wednesday, February 8, 2017 7:21 PM To: 'dots' Cc: David Aviv Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-0= 7 and draft-reddy-dots-data-channel-03 . Tiru and authors Hi Attached please find my comments and feedbacks to draft-reddy-dots-signal-c= hannel-07 and draft-reddy-dots-data-channel-03 . Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel = draft-reddy-dots-signal-channel-07 1. General comment: For all signals in the draft, need to add means t= o allow vendor specific attributes as part of all signals transactions 2. General comment: Just for clarity, need to explicitly mention on e= ach figure when it is an example or the actual API 3. Page 3 second paragraph : DOTS should not be limited to "enterpris= e network" only . 4. Page 4 chapter 4: The overall context of the "happy eyeballs" and = its relations (or coexistence) to CoAP is not clear. 5. Page 7 chapter 5.2.1: The need for YANG model cannot be understood= from text. What are the needs for YANG models? What is the relation to the= JSONs in the other chapters in the draft 6. Page 14 figure 5: The mitigation request attributes are right but = not enough. Need to add more telemetry info about the actual attack that it= is required to mitigate, need to consider attributes in draft-doron-dots-t= elemetry-00 as part of the discussion in the WG. 7. Page 15 Life time attribute: More reasonable to have this attribut= e in minutes rather than seconds, bigger default can also suggested 8. Page 15 last paragraph: Not sure that target port or target protoc= ol can define a protected entity. IP, FQDN, URI are the only "stand alone" = attributes , port and protocol are companion attributes. See also figure 9 = . 9. Page 15 last paragraph: The mitigation request is not clear, to wh= ich identifier the text is related ? "policy ID" ? I think the best is ha= ve another attribute to define the priority of mitigation requests 10. Page 21 table: The return status are right but not enough. Need to ad= d more telemetry info about the actual mitigation going on (how much traffi= c was mitigated) and the attack that are mitigated, need to consider attrib= utes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. 11. Page 15 : Need to find the way to bind the target-ips with target-por= t-ranges and target-protocols, meaning that the server needs to understand = the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on = so forth. 12. Page 21 last paragraph: This is very strong point. 13. Page 25 : Regarding attack status, same point about telemetry. 14. Page 25 chapter 5.4: I believe it can valuable to add a short high le= vel description about the proposed API flow, same as you did for 5.3 . 15. Page 27: The necessity of policy_id here is not clear enough, are th= e "Signal Channel Session Configuration" define only "single" DOTS session = or the entire communication between Client and Server for several DOTS requ= est for mitigation? 16. Page 27: Not sure about the reason for "at least one of the attribute= s heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor = MUST be present." Also consider to change to "presented". 17. Page 30 chapter 5.5: Need to specify the overall scenario, in reactio= n to which signal (or API transaction POST of Mitigation Request , unidirec= tional notification from Server as describes in page 23 in page 21 ?) the = redirection occurred ? Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel dr= aft-reddy-dots-data-channel-03 1. General comment: For all signal in the draft, need to add means to= allow vendor specific attributes as part of all signals transactions [TR] Agreed, updated draft. 2. Page 5 second paragraph: Why it is required to configure the DOTS = signal channel session ? [TR] No need to configure DOTS signal channel session, fixed second paragra= ph. 3. Page 8 chapter 3.2.1 : Any reason for not including these identifi= ers in the DOTS signal channel draft ? [TR] Identifiers created for resources in DOTS data channel are used in DOT= S signal channel to request DDOS mitigation. It's the responsibility of DOT= S data channel to create aliases for resources (see https://tools.ietf.org/= html/draft-ietf-dots-requirements-03#section-2.3). The main reason for DOTS= signal channel not creating identifiers is the message size may exceed Pat= h MTU. 4. Page 9 figure 3 : Need to find the way to bind the target-ips with= target-port-ranges and target-protocols, meaning that the server needs to = understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53= and so on so forth. [TR] Yes, it is possible; create different aliases for IP1 TCP port 80 and = IP2 UDP port 53. 5. Page 13 chapter 3.3 : Need to emphasize that filtering rules are r= elevant for both client server direct communication and through a DOTS gate= way. The chapter is a bit confusing. [TR] Thanks, fixed chapter 3.3. 6. Page 14 chapter 3.3 : I am missing the white-list installation, is= it by using the permit action ? [TR] Yes, "permit" action is used for white-list installation; it's define= d in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 7. Page 15 figure 8: For DDoS it is highly valuable to have rate limi= t as an action. Consider adding such action (if already defined need to exp= lain where and how). [TR] Done, updated draft. 8. Page 15 figure 8: Need to consider adding priority to an ACL to su= pport cases when several filtering rules are conflicting. [TR] We are not doing anything new to ACL, ACL an ordered list of Access L= ist Entries (ACE) based on priority. 9. Page 15 : The action field cannot be optional attribute. [TR] As per https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 if t= he action field not specified then "deny" is the default action. 10. Page 16 chapter 3.3.3: Need to add more telemetry info about the actu= al traffic that was blocked (bps, pps and so on), but as I believe this mig= ht be another issue... [TR] Chapter 3.3.3 only discusses telemetry details of number of matches fo= r the installed filtering rules. -Tiru Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 _______________________________________________ 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 --_000_675dbf9cd1134c47847cdb22602c8904XCHALN017ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see inline [TR3= ]

 

From:= kaname nishizuka [mailto:kaname@nttv6.jp]
Sent: Friday, February 17, 2017 10:07 AM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; Ehud Dor= on <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signa= l-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru,

Thanks for your response and clarifications.
Please see my response inline[kaname2]

On 2017/02/16 21:09, Tirumaleswar Reddy (tireddy) wr= ote:

Hi Kaname,=

 

Please see inline [TR2= ]

 

From:= kaname nishizuka [mailto:kaname@nttv6.jp]
Sent: Thursday, February 16, 2017 1:22 PM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; Eh= ud Doron <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <Davi= dA@Radware.com>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signa= l-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru,

please see inline.

On 2017/02/16 13:18, Tirumaleswar Reddy (tireddy) wr= ote:

Hi Kaname,=

 

Please see inline [TR]= for responses

 

From:= kaname nishizuka [mailto:kaname@nttv6.jp]
Sent: Wednesday, February 15, 2017 11:27 AM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; Eh= ud Doron <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <Davi= dA@Radware.com>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signa= l-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru,

I really appreciate your time and effort.
Please see my comments on the drafts.

# draft-reddy-dots-signal-channel-07

1. [General] I believe that DOTS request should not be another tool of bloc= king other one's traffic. Is there any validation mechanism of requested ta= rget-ips, target-ports and target-protocols? Even If it is out side of the = DOTS specification, how about returning 4.xx codes when the requested target-* is not a property of the organizati= on.

[TR] The validation scope is outside the scope of this draft, 4.xx= error code is already used in the draft to identity invalid requests.

[kaname]OK, understood.



2. [page14] Does one = DOTS client and DOTS server peer have only one signal channel and one data = channel? (I'm thinking about a namespace of the "alias-name")

[TR] No, DOTS peers can have more than one signal and data channel= but the recommendation is to use only signal and data channel to reduce co= nnection setup delay.

[kaname] If there are more than one signa= l and data channel, how can they coupled?

 

[TR2] DOTS client auth= enticate to the DOTS server (see https://tools.ietf.org/html/draft-reddy-dots-signal-channel-= 07#page-35), the DOTS server knows the DO= TS client identity to couple the signal and data channel sessions.

 

[kaname2] I see. Could I confirm that my underst= anding is right.
The signal and data channel sessions are coupled based on the client certif= ication. So, the same client certification should be used among (D)TLS in s= ignal channel session and TLS in data channel session.

 

[TR3] Yes.<= /span>


If so, how about writing it explicitly in the main part of [draft-reddy-dot= s-data-channel-04]? Now, mutual authentication is described only in 6. Secu= rity Considerations.

[TR3] Good point, will= update signal channel draft how signal and data channel sessions are coupl= ed using DOTS client identity.

NEW:=

 

   In both DOTS signal and data= channel sessions, the DOTS client MUST

   authenticate itself to the D= OTS server (Section 9).  The DOTS server

   couples the DOTS signal and = data channel sessions using the DOTS

   client identity, so the DOTS= server can validate whether the aliases

   conveyed in the mitigation r= equest were indeed created by the same

   DOTS client using the DOTS d= ata channel session.  If the aliases were

   not created by the DOTS clie= nt then the DOTS server returns 4.00 (Bad

   Request) in the response.

 

 

One DOTS server will accommodate more tha= n one DOTS client, so is there any way to know which data channel is belong= to which signal channel? Source IP?
I recommend to use only one signal and data channel per one DOTS peer, too.=

 

 

If their are multiple= data channels, "DOTS signal" in Fig.5 should specify according d= ata channel when it refers to "alias-names" of the identifiers.

[TR] I did not get the comment.

[kaname] Different DOTS clients will be b= elonging to different customers(organizations).
So I think there is a chance of requesting the same "alias-names"= from different customers.
Then, will the DOTS server reject conflicted "alias-names" betwee= n different customers?

 

[TR] No.

 

or keep them with prefixes like customerA= :<same-alias-name> and customerB:<same-alias-name> internally? = Also, customerA should not use an alias-name of customerB. How can the DOTS server check that.

 

[TR2] Same response as= above. Aliases do not have global scope, they are specific to a DOTS clien= t (DOTS server knows the DOTS client identity).

[kaname2]OK, I understood.



3. [Page21] How about adding status of "mitigation delete is in= progress" like status:1.
    Here is a life cycle of a mitigation in our environment.= Activating and deleting of mitigation could take several seconds (or minut= es).
    POST.
     - activating(status=3D1)
    STATUS AFTER ACTIVATED
     - attack mitigated (status=3D2)
     - attack stopped (status=3D3)
     - attack exceeded capability(status=3D4)
    DELETE
     - deleting(status=3D5?)
     - deleted(RETURN 4.04)



[TR] Delete is a confirmable message, DOTS server will send an ACK= to acknowledge the receipt of the message to avoid retransmissions from th= e DOTS client. After the mitigation request is successfully deleted, DOTS server returns 2.02 (Deleted) response code,= thus conveying the transient status in this case is not necessary.<= o:p>

[kaname] As I noted, deleting of mitigati= on could take several seconds (or minutes) in real-life.<= /p>

 

[TR2] Yes, but the DOT= S server immediately sends a ACK (acknowledging the receipt of the DELETE m= essage), thus the DOTS client knows the server has received the Delete requ= est and is processing the request. After deleting the mitigation (may take several seconds), server sends 2.02 (Del= ete) response code. I don’t see a problem.

 

-Tiru

 

[kaname2] The same story could be applied to the= status:1 (Attack mitigation is in progress)

[TR3] No, the DOTS cli= ent needs to know the mitigation status and DDOS attack status so that it c= an withdraw the mitigation request when the DDOS attack stops (see Section = 5.3.3.1) and to know whether the DOTS mitigation provider is able to successfully mitigate the attack or is re-d= irecting the client to an alternate DOTS server.

These unsolicited noti= fications are not required for withdraw because after validating the DELETE= request DOTS server immediately send an ACK or returns an error that the D= ELETE request was invalid and it is DOTS server responsibility to withdraw the mitigation request from the DDO= S mitigator(s) (which may take several seconds).

 

-Tiru

thank you,
Kaname

If the DOTS client retrieve the status wh= ile that time, getting "deleting status", not "2.02 status&q= uot;, will help operators.


4. [Page25] 5.4 b) I = couldn't find "retransmission timeout value" attribute in the lat= er figures. Is that equivalent to "ack-timeout"?

[TR] The initial retransmission timeout value is based on the ack-= timeout (see https://= tools.ietf.org/html/rfc7252#section-4.2).=

[kaname] Thank you, I found the reference= .


5. [Page27] "pol= icy-id" in "signal-config" is different from "policy-id= " in "mitigation-scole". How about using "session-id&qu= ot; in this case?

[TR] Policy-id is a unique identifier identifying the signal chann= el session configuration request.

[kaname] "policy-id" in Fig.9 a= nd Fig.15 are totally different. I've got confused when reading the draft b= ecause they have the same name.


 

# draft-reddy-dots-da= ta-channel-03

1. [General] Data channel doesn't have heartbeat mechanism. I guess the rea= son is that there is heartbeat mechanism in the signal channel so it is eno= ugh, is that right?

[TR] No, the heartbeat mechanism in signal channel cannot be used = for data channel. DOTS signal channel is using the “CoAP ping mechani= sm”. For data channel, TLS heartbeat can be used. I have updated draft.

[kaname] OK. I'll see updated draft.



2. [related to Ehud's= question 8] I-D.ietf-netmod-acl-model says "ACL is an ordered list of= Access List Entries (ACE)" but I couldn't find a text about how they = are ordered. Should we have a operation of changing the order of ACEs installed in a DOTS server?

[TR] PUT can be used by the DOTS client to re-order/update/modify = the list of ACE conveyed to the DOTS server. Updated draft to discuss about= PUT.

[kaname] OK. I'll see updated draft.


thank you,
kaname


-Tiru


thank you,
Kaname

On 2017/02/14 23:58, Tirumaleswar Reddy (tireddy) wr= ote:

Hi Ehud,

 

Please see inline for = responses to comments on draft-reddy-dots-data-channel-03=

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radw= are.com>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-ch= annel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru and authors Hi

 

Attached please find m= y comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-re= ddy-dots-data-channel-03 .

 

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy= -dots-signal-channel-07

 

1.     &= nbsp; General comment: For all signals in the draft, need= to add means to allow vendor specific attributes as part of all signals tr= ansactions

 

2.     &= nbsp; General comment: Just for clarity, need to explicit= ly mention on each figure when it is an example or the actual API

 

3.     &= nbsp; Page 3 second paragraph : DOTS should not be limite= d to “enterprise network” only

.

4.     &= nbsp; Page 4 chapter 4: The overall context of the “= ;happy eyeballs” and its relations (or coexistence) to CoAP is not cl= ear.  

 

5.     &= nbsp; Page 7 chapter 5.2.1: The need for YANG model canno= t be understood from text. What are the needs for YANG models? What is the = relation to the JSONs in the other chapters in the draft

 

6.     &= nbsp; Page 14 figure 5: The mitigation request attributes= are right but not enough. Need to add more telemetry info about the actual= attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

7.     &= nbsp; Page 15 Life time attribute: More reasonable to have this attribute in minutes rather tha= n seconds, bigger default can also suggested

 

8.     &= nbsp; Page 15 last paragraph: Not sure that target port or target protocol can define a protect= ed entity. IP, FQDN, URI are the only “stand alone” attributes = , port and protocol are companion attributes. See also figure 9 .

 

9.     &= nbsp; Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is relate= d ?   “policy ID” ? I think the best is have another = attribute to define the priority of mitigation requests

 

10.   Page 21 table: The return status are right but not = enough. Need to add more telemetry info about the actual mitigation going o= n (how much traffic was mitigated) and the attack that are mitigated, need = to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

11.   Page 15 : Need to find the way to bind the target-i= ps with target-port-ranges and target-protocols, meani= ng that the server needs to understand the exact scope of attack, e.g. IP1 = TCP port 80, IP2 UDP port 53 and so on so forth.

 

12.   Page 21 last paragraph: This is very strong point.<= o:p>

 

13.   Page 25 : Regarding attack status, same point about= telemetry.

 

14.   Page 25 chapter 5.4: I believe it can valuable to a= dd a short high level description about the proposed API flow, same as you = did for 5.3 .

 

15.   Page 27:  The necessity of policy_id here is n= ot clear enough, are the “Signal Channel Session Configuration”= define only “single” DOTS session or the entire communication = between Client and Server for several DOTS request for mitigation?

 

16.   Page 27: Not sure about the reason for “at le= ast one of the attributes heartbeat-interval or max-retransmit or ack-timeo= ut or ack-random-factor MUST be present.” Also consider to change to = “presented”.

 

17.   Page 30 chapter 5.5: Need to specify the overall sc= enario, in reaction to which signal (or API transaction POST of Mitigation = Request , unidirectional notification from Server as describes in page 23 i= n page 21 ?) the  redirection occurred ?

 

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-d= ots-data-channel-03

 

1.     &= nbsp; General comment: For all signal in the draft, need = to add means to allow vendor specific attributes as part of all signals tra= nsactions

 

[TR] Agreed, updated draft.

 

2.     &= nbsp; Page 5 second paragraph: Why it is required to conf= igure the DOTS signal channel session ?  

 

[TR] No need to config= ure DOTS signal channel session, fixed second paragraph.<= /p>

 

3.     &= nbsp; Page 8 chapter 3.2.1 : Any reason for not including= these identifiers in the DOTS signal channel draft ?

 

[TR] Identifiers creat= ed for resources in DOTS data channel are used in DOTS signal channel to re= quest DDOS mitigation. It’s the responsibility of DOTS data channel t= o create aliases for resources (see https://tools.ietf.org/html/draft-ietf-dots-requirements-03= #section-2.3). The main reason for DOTS s= ignal channel not creating identifiers is the message size may exceed Path MTU.

 

 

4.     &= nbsp; Page 9 figure 3 : Need to find the way to bind the = target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e= .g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

[TR] Yes, it is possib= le; create different aliases for IP1 TCP port 80 and IP2 UDP port 53.

 

 

5.     &= nbsp; Page 13 chapter 3.3 : Need to emphasize that filter= ing rules are relevant for both client server direct communication and thro= ugh a DOTS gateway. The chapter is a bit confusing.

 

[TR] Thanks, fixed cha= pter 3.3.

 

 

6.     &= nbsp; Page 14 chapter 3.3 : I am missing the white-list i= nstallation, is it by using the permit action ?

 

[TR]  Yes, “= ;permit” action is used for white-list installation; it’s defin= ed in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09

 

 

7.     &= nbsp; Page 15 figure 8: For DDoS it is highly valuable to= have rate limit as an action. Consider adding such action (if already defi= ned need to explain where and how).

 

[TR] Done, updated draft.

 

8.     &= nbsp; Page 15 figure 8: Need to consider adding priority = to an ACL to support cases when several filtering rules are conflicting.

 

[TR]  We are not = doing anything new to ACL, ACL an ordered list of Access List Entries (ACE)= based on priority.

 

 

9.     &= nbsp; Page 15 : The action field cannot be optional attri= bute.

 

[TR] As per https:/= /tools.ietf.org/html/draft-ietf-netmod-acl-model-09 if the action field not specified then “deny” is the default action.

 

10.   Page 16 chapter 3.3.3: Need to add more telemetry i= nfo about the actual traffic that was blocked (bps, pps and so on), but as = I believe this might be another issue…

 

[TR] Chapter 3.3.3 onl= y discusses telemetry details of number of matches for the installed filter= ing rules.

 

-Tiru

 

Thanks,

 

Ehud Doron <= span dir=3D"RTL">|  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

 






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

 





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

 




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

 

--_000_675dbf9cd1134c47847cdb22602c8904XCHALN017ciscocom_-- From nobody Tue Feb 21 00:22:40 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175E8129643 for ; Tue, 21 Feb 2017 00:22:39 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 U-SHloAQ1uvn for ; Tue, 21 Feb 2017 00:22:36 -0800 (PST) Received: from mailout1.radware.com (mailout1.radware.com [192.115.180.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10FCB129416 for ; Tue, 21 Feb 2017 00:22:36 -0800 (PST) Received: from ILMB1.corp.radware.com ([169.254.1.237]) by ILCAS1.corp.radware.com ([176.200.120.121]) with mapi id 14.03.0319.002; Tue, 21 Feb 2017 10:22:33 +0200 From: Ehud Doron To: 'dots' Thread-Topic: DOTS Telemetry Thread-Index: AdKIYTXgs9jnVMU+R1WnPYyVGJhdZADtHDpQ Date: Tue, 21 Feb 2017 08:22:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [176.200.121.206] x-tm-as-product-ver: SMEX-11.0.0.4179-8.100.1062-22898.006 x-tm-as-result: No--18.556200-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E58182C4A35A8E498E553AD3D33FA0010117191753ILMB1corpradw_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS Telemetry X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 21 Feb 2017 08:22:39 -0000 --_000_E58182C4A35A8E498E553AD3D33FA0010117191753ILMB1corpradw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All My personal thought about the DOT Telemetry (and I am speaking for myself,= not for the other DOTS Telemetry draft authors) is that in order to build = a viable anti-DoS service, both NOC / SOC teams at client and server side w= ill definitely need some sort of information about the on-going attack bein= g mitigated. No doubt about that. When it comes to operations of DDoS attacks, "life can be complicated" in t= he sense that attacks are not always successfully mitigated and cases of bl= ocking legitimate traffic can be frequent.... Therefore I believe that the = so called "Telemetry for Visibility" is mandatory, for some extent. Meaning= that information about attacks (whether we call it telemetry or use other = terminology) need to be presented to the SOC/NOC teams, and we MUST deal wi= th it as an MVP. I think that what Tiru has suggested in the Signal Channel= draft can be a very good starting point. My concerns are that if such information will not be covered as part of DOT= S standard, we will end up with a lot of vendor extensions and other "out o= f band" proprietary signaling... and I don't think that this is the ultimat= e goal of IETF in general and in particular for DOTS. As per the "Telemetry for Mitigation" below, I have some concerns that this= part might be more complicated and can tend to be aligned with a specific = implementation, thus can be difficult to standardized. Therefore I think th= at this part can be considered in the future phases of DOTS. Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 From: Ehud Doron Sent: Thursday, February 16, 2017 4:44 PM To: 'dots' Subject: DOTS Telemetry All Following the WG last F2F meeting in Seoul, we would like to elaborate the = discussion about the DOTS Telemetry, mainly its general aspects and directi= ves. Up to now, we have two declarations for DOTS Telemetry: 1. The DOTS Requirement draft draft-ietf-dots-requirements-03d define= s : "DDoS attack telemetry: Collected behavioral characteristics defining = the nature of a DDoS attack. " . 2. The DOTS Telemetry draft draft-doron-dots-telemetry-00 defines "= "DOTS Telemetry" is defined as the collection of attributes characterizing = the actual attacks that have been detected and mitigated. The DOTS Telemetr= y is an optional set of attributes that can be signaled in the various DOTS= protocol messages. The DOTS Telemetry can be optionally sent from the DOTS= Client to Server and vice versa. We are now figuring out the general view on the DOTS Telemetry theme and ha= ve mapped two main categorizes of telemetry we believe are most relevant to= DOTS: 1. Telemetry for Visibility - The main objectives of this category is= to allow SOC / NOC teams, on both DOTS Client and Server side, to gain vis= ibility on the overall service provided by facilitating the DOTS signaling.= As perceptible examples, we can suggest the Mitigation Status requirement = (OP-004 from DOTS Requirement draft), attack details, attack BW and PPS, pa= cket / bytes drops and so on. 2. Telemetry for Mitigation - The main objective of this category is = to allow mitigation facilities to improve their detection and mitigation pe= rformance. As perceptible examples, we can suggest the Mitigation Efficacy = requirement (OP-007 from DOTS Requirement draft), traffic baseline in certa= in levels and so on. As part of the WG effort to define the DOTS baseline features (the DOTS MVP= s), we would like to get the WG feedbacks about the abovementioned telemetr= y categories and also about other possible suggested telemetry categories. = We encourage group members from both vendors and service providers to bring= -in their valuable feedbacks and needs on this matter. It is preferable for= us to get feedbacks on the suggested categories as a whole, rather than on= a specific telemetry attribute within a specific category. The main objective is allowing us to be able to direct, and focus, our work= on draft-doron-dots-telemetry-00 according the WG directives and needs. Kindly, we will appreciate any kind of feedbacks, DOTS Telemetry draft authors --_000_E58182C4A35A8E498E553AD3D33FA0010117191753ILMB1corpradw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All<= /p>

 

My personal thought ab= out the DOT Telemetry  (and I am speaking for myself, not for the othe= r DOTS Telemetry draft authors) is that in order to build a viable anti-DoS= service, both NOC / SOC teams at client and server side will definitely need some sort of information about the on= -going attack being mitigated. No doubt about that.

 

When it comes to opera= tions of DDoS attacks, “life can be complicated” in the sense t= hat attacks are not always successfully mitigated and cases of blocking leg= itimate traffic can be frequent…. Therefore I believe that the so called “Telemetry for Visibility” is mandatory, fo= r some extent. Meaning that information about attacks (whether we call it t= elemetry or use other terminology) need to be presented to the SOC/NOC team= s, and we MUST deal with it as an MVP. I think that what Tiru has suggested in the Signal Channel draft can be a very goo= d starting point.

 

My concerns are that i= f such information will not be covered as part of DOTS standard, we will en= d up with a lot of vendor extensions and other “out of band” proprietary= signaling… and I don’t think that this is the ultimate goa= l of IETF in general and in particular for DOTS.  

 

As per the “Tele= metry for Mitigation” below, I have some concerns that this part migh= t be more complicated and can tend to be aligned with a specific implementa= tion, thus can be difficult to standardized. Therefore I think that this part can be considered in the future phases of DOTS. &nb= sp; 

 

Thanks,

Ehud Doron <= span dir=3D"RTL">|  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

From: Ehud Doron
Sent: Thursday, February 16, 2017 4:44 PM
To: 'dots' <dots@ietf.org>
Subject: DOTS Telemetry

 

All

 

Following the WG last F2F meeting in Seoul, we would= like to elaborate the discussion about the DOTS Telemetry, mainly its gene= ral aspects and directives.

 

Up to now, we have two declarations for DOTS Telemet= ry:

1.     &= nbsp; The DOTS Requirement draft= draft-ietf-dots-requirements-03d defines : “DDoS attack telemetry:&n= bsp; Collected behavioral characteristics defining the nature of a DDoS att= ack. “ .

2.     &= nbsp; The DOTS Telemetry draft d= raft-doron-dots-telemetry-00  defines  “"DOTS Telemetr= y" is defined as the collection of attributes characterizing the actua= l attacks that have been detected and mitigated. The DOTS Telemetry is an optional set of attributes that can be signaled in the various DOTS = protocol messages. The DOTS Telemetry can be optionally sent from the DOTS = Client to Server and vice versa.

 

We are now figuring out the general view on the DOTS= Telemetry theme and have mapped two main categorizes of telemetry we believe are most relevant to DOTS:<= /o:p>

 

1.     &= nbsp; Telemetry for Visibilit= y – The main objectives of this category is to allow SOC / NOC te= ams, on both DOTS Client and Server side, to gain visibility on the overall= service provided by facilitating the DOTS signaling. As perceptible examples, we can suggest the Mitigation Status r= equirement (OP-004 from DOTS Requirement draft), attack details, attack BW = and PPS, packet / bytes drops and so on.

 

2.     &= nbsp; Telemetry for Mitigatio= n – The main objective of this category is to allow mitigation fa= cilities to improve their detection and mitigation performance. As percepti= ble examples, we can suggest the Mitigation Efficacy requirement (OP-007 from DOTS Requirement draft), traffic baselin= e in certain levels and so on.  

 

As part of the WG effort to define the DOTS baseline= features (the DOTS MVPs), we would like to get the WG feedbacks about the = abovementioned telemetry categories and also about other possible suggested= telemetry categories. We encourage group members from both vendors and service providers to bring-in their va= luable feedbacks and needs on this matter. It is preferable for us to get f= eedbacks on the suggested categories as a whole, rather than on a specific telemetry= attribute within a specific category.  

  

The main objective is allowing us to be able to dire= ct, and focus, our work on draft-doron-dots-telemetry-00  according th= e WG directives and needs.

 

Kindly, we will appreciate any kind of feedbacks, &n= bsp;

 

DOTS Telemetry draft authors

 

--_000_E58182C4A35A8E498E553AD3D33FA0010117191753ILMB1corpradw_-- From nobody Tue Feb 21 00:53:28 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BC21294A2 for ; Tue, 21 Feb 2017 00:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com 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 7bfSP9KmRQkJ for ; Tue, 21 Feb 2017 00:53:25 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0091.outbound.protection.outlook.com [104.47.40.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E54129416 for ; Tue, 21 Feb 2017 00:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zFvTT2Gmd53acFU3fOo1SSeETDmDXBYn9ueuhtYagKE=; b=IHnG2z+IbZVekIdhgYYj3yemj9JiAdALo4Ihwa7lw1o3itw0wxeKM15pa0RcZ3ln87iz2hf5qv3oHID+N851Iu2RqtGx+5vt9TR0uwT0ES4OnLts2DB8j8kAxZ6Kj/0EAsazWsKzV3ANW4B9lxge4kA3roNZkqdtZ5T1m/p3rU0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; Received: from [172.19.254.106] (49.228.82.190) by CY1PR0101MB1036.prod.exchangelabs.com (10.160.225.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Tue, 21 Feb 2017 08:53:22 +0000 From: Roland Dobbins To: dots Date: Tue, 21 Feb 2017 15:53:02 +0700 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [49.228.82.190] X-ClientProxiedBy: KL1PR0201CA0036.apcprd02.prod.outlook.com (10.167.53.174) To CY1PR0101MB1036.prod.exchangelabs.com (10.160.225.140) X-MS-Office365-Filtering-Correlation-Id: 67ed4b26-a570-4222-9077-08d45a3717ae X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0101MB1036; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 3:hW3smeTfNmGgVHVfGHGJNc6hryiosjtvcftmRxAk1sZlOxq7n4y0cqsa6H/N5hGBMoKbIb2LbJKVf+5BF+n9oUBIk+ttesXdsClo8rJuxBRpo8GFq3KM4HRRCenb1Eev7W0eNmlPtkkELbxzhtA6Lq0Qv/HGR0rX81xXd/w6qHXGlgvhIm+pj3eB34JhwjK978ltpqksCAOvyzswYiaEUC4rqQ1qAKiX74/jvIdCqTDdoasAz+68kgpdxeRW5gM/tw91IFNRMlkTFUshn5xxSQ==; 25:VSZKPrOA8s7ybR52uGio/EosgXMTjvO9Kb/gruUYCyITfgd6tUq/LHnWreF32ekIzUQDPGvIJ/mOT881LOI9p+btmOKDYXfnJQE/Img98RFY88dzYv7iVv7zJFFyBwIR5wn+34sD/O0ip2Rh+57K7Lx4FlRr6u+DNiNB7N78qnFAMmjBA/YSB2rai66cin08Qtm/GcmRK9VzymagzYVrRHIUJQm56VodIw8DWW3pB2H71QfaoqrlmAnCmYaYAym2DnPFqmyuaw7U+2K2P2K6f3Xya19v9xAhSur+2qHXf/omspEtQeYyFCBuhH7xrcKIaYVkmBbCi0mJbSmYqSFRahVdxLX1OVInhxbfobCQO/TQVXYOdRiARyN/hZZMBknOWaQ1gUGyLNgSoPg3Y2rVZx97xlDDUmsxR0LVRT6/mrztd8tsSEav/2Vb66AMSPVYKOTRjFzuMG8ian6k9Ccf+Q== X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 31:nrvLqMeTNXmKG0pdkw3oH2vhq503xd4ZB2VCqeQ4LVw5XDehZgiYd1ql/6brarBaqnjXBna95NAOUhPnMuCNBTkipxqm2RFxAfylIGB+oUUAnIqPjx8fM6+tWKipPit8MJeSTNepWJQ6cTGOnkhEKFzClNEg39juKZokpyrLiwiKhHfJkaaf53pvBvPIOkRsF3J/8WI1sPcvqDQCxh6KV2t1cd9aAZdgA/o+GD9lnqHd87+i5WcjElqQL6C9C5RMalYuqT1USBf93K1OHBIN+A==; 20:sHulxVbIwlyjteMiI6G0rRmxP8xBmfUi5hsK9wmb+mavEYuFJoHr8bG4rJ8zey1XATm0VxY/A30Ets8PJDszrfil/qPto+v1SgNmEtRfZBr4AiP/AOkaTZcWbTgaKbjUknQNPQfkKUB05Y+4GY+6XIuq5bIvmzWNHPVjMssXYT2ZBd4HztfOCCHN15Sj2ewYjcJ6jYUI2mr69Euf8K+9AZqvrWnWuS2YlozGksVH2IVLUF07bVDiFS2bBhK7uqteef0x4kh5aydmCE5pUqCMvvZecT9/q6Zt5v7m/mlKMmLG/hO98Pg3QUTN1AP3UvntcmxnyZAHL/p1BLb7yS3B4LHHJfAUydAHQpMXjLJa7ZfQ5+giLkwTQiwLHNlyR8DJ74Pp8aeoWZctm2pDijq4HeEf28r6d0U7EcTNEdDJVe9igZb3+kdVi+wWU22HfpcEHbvYMmjqp513/+ix3N0T487TttelAaWx12I19tptZAT1Aehiy1DmhZhBSocOL6Bn X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(20161123558025)(6072148); SRVR:CY1PR0101MB1036; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0101MB1036; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 4:H27xFTnUqs2+0MGubRIGNu5Srxz1JXPt0Q6XlsSi3mC5BAj6JpOfLLpQFDgGMHLxkPimw0JRcyH5cAKVuC6pAZi9Q/s5rAxNmJJNDAUcC72xni8GjKH4MGaaZEMZDMHrWOdHBuR0Z7YZ0I8ModE6AN3gk6hxOWHw26lK4QbtU+MNBu6sGUJ4BtrRd4WLIwyiJeZBr2yclC9p0GhEpV92FSJYb6RNNvsatP0m7h6obk/rZdAadlfoIqtS+B+vS39tIE+pnyRMLZRA4qEERiFa8U7DCqmS3x7bZ3M931TgFdL/BAkCX0Gif0E9XltJQImFtFnDlZ2cqpApL4kciXy6wrKsxsTapQd0F733WIHKBqly5FoACHVkZyLk9MGvVuKcXpwiA6anPjGvdARVgAOiG4EsmnT39dYOrFr33PSxuWUELICbd9WnfLX4p/7F87FMYzrpoQOr3lhFpkziqjdrxy88mM69Psg39pnou/cq7PV1U0zleQwV9GGihcCeBtJiAgxQv9TKXpsVaxY71SNyE9S95jOiBmfof1IpCkDrHfgytMMYtY5+vPmMIijg1JI6R8v32jFDKxwjVpwHe1WKCXm5/+MSUxs6CN/4/gsVlR28lHQ6UnT2pvsRyV3zCI+qzRuYebWx3X4Ynlrb5lncf5LB4Wyz7SXiQe0MDteWnjo= X-Forefront-PRVS: 0225B0D5BC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(39450400003)(51444003)(199003)(189002)(24454002)(86362001)(2950100002)(92566002)(6116002)(97736004)(3846002)(229853002)(101416001)(6666003)(6916009)(82746002)(189998001)(53546006)(68736007)(50226002)(450100001)(83716003)(105586002)(50466002)(106356001)(47776003)(305945005)(25786008)(81156014)(42186005)(33656002)(66066001)(81166006)(110136004)(8676002)(5660300001)(2906002)(77096006)(76176999)(90366009)(6486002)(50986999)(53936002)(38730400002)(36756003)(6246003)(5003940100001)(7736002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0101MB1036; H:[172.19.254.106]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0101MB1036; 23:ChvtSri5glG4jxpQeWHid1UhvN5jLaVbS7U6RnU?= =?us-ascii?Q?chjkzsb1kHq6g0xq6Pi4DO3S3OFjdPwZXlWekMXb1YRFjGeYiPFz5n3nj9+u?= =?us-ascii?Q?+XiIAj5tf46q4Y7c9keaaLZvhGQLdf1TK6Wu7l2CjK7lik7hqZcXYcB3Rzhm?= =?us-ascii?Q?IGpRbXu/PuYP6XNrQ2iJXIkz930Xq85n+aMGhf6erztIYiWw1ozC0+Xfr/Nr?= =?us-ascii?Q?nhKWw/f0zY0lzhLUDXFyE9GsJKsWK8MEKcysHvgz207DMijIuPYQvyMgriGp?= =?us-ascii?Q?C8nRfrCrn1L3jKTsJNoZE5sx/abktd1l7f3vtSdNoLqW6Iq5R/lbBh//TOrA?= =?us-ascii?Q?tq51/mlbtd8qWGKYuDpzlORDNGoJTH2Iy5IZ9W5FH6Vji3l4MGRdUNScBa2w?= =?us-ascii?Q?7155HlUCkoA6s3wq6AHKljCpk4NMn6zG6ZHc2CErFS4d8EkqmOdvzmZOzg24?= =?us-ascii?Q?Uvuw+K14D3SmWRipgI3rGzWPk89zjy3LYw13C0UCCd06RuAOZNgcyBN16lCe?= =?us-ascii?Q?vA6xs7fXy2bMcNgUvcex7zO3AqUNE/h1FpW4vUGuK9VjAyS62X0uQDfhdReD?= =?us-ascii?Q?1pl7PJ9HVK83HOUHWjxLFIbmCFUwT35PnftFVmPErORBVI7DmHlU76/Rlhz3?= =?us-ascii?Q?do5cuXcuUc84G+ZmN31V4urNRJAwoZkWW8yIB2Dvy75wcoDiNBhLdMkvrR0p?= =?us-ascii?Q?YMO/GZJMBSZxf5gY9ugpYwr9VY6p16pn4AaCVVqR9+u2sfQI9FMsjgqjhX9b?= =?us-ascii?Q?UeX/ubp2X+kpyXevlnrNOXV8ER+MHrgfeXetJw8BuF43Bg8WPshF58+56bRB?= =?us-ascii?Q?6vQYMTZ65XgaNhWJRx2N4/ZpnLjfnpS7UGRxKZ/14crDVM0iqfsaaW5QIiUZ?= =?us-ascii?Q?PybxNHJKSyX45UqiSUB8jfUTg5bF/gbkhtP5lhIdWXN0+Q7PPkz1QRjx5An9?= =?us-ascii?Q?jhit+7/T8UB11N7oRbde+NpukC2chtrQUeHOWitkaYpjmvUIieZlOhpdkrr/?= =?us-ascii?Q?FR/DA4aao8XsQs1C0pj6MBPaBrVE4NC/vqXKb2joFXOvuZio6M1o0KhE8qmh?= =?us-ascii?Q?x+IigIMjNsrl2NJAia/sBrAvD/RF5IxbR3NjZBHyQeSGVrk/i4+98ZCmYnUI?= =?us-ascii?Q?r/YM5u63w4pe9GsszkI908oxwQlXfzgnqo+rlB/MrCI7MpP7tNjEx0g0SsY8?= =?us-ascii?Q?Dw7acB9jJRl7FyrHGiEGQHWju76g0m6gIrVSCtsfzqZX3++p3I/CtnhM/dLg?= =?us-ascii?Q?sRb2HPf0eH4RUr52Brmxe8GFnheNhb9EHPmr0ysX/?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 6:V7fyyRO/vWw3asl4mF1Rwroq0pLiCNIHP5MQD1pXFyUsDPGrl0LYR9d6IvZe46oUSskDP2Qq+Ggs+1Gby3XW5RGYAQ9NajfFIQWbqFx/a+ub/R+QLi0PNxP0F/sqOXYjuuSQ3XkBSkk1uOLI2VtvNup2r7nY4sl/lyNI1GDF91UQdpo4SX259zEJpBYIMBTd9tpw2e217xEsMQ0R6GFZRN+9FRbusYnyDBr0f7oLw1NuIVkvz+xymImMSznfFDPgoiy3lohEi3wZZoUd8f0e3JeczMbGgCmDMhE8+xyLkyhZnwzg1ESrlSj7q4mrsHNzciQvkeUn99yZbJhpFLksOizvRGW+sh5pTSReChmAVnzxWisCEP4aWXHB/+6bUdVLkDNkHiRRpbXiFdNIgqJGWA==; 5:JoomJ4KclYNwPIasppMJc0Ye7tWMFTVfJMWxipwG3ZwqpGPEoWWDsFIH+N3K3EnLNxlHKzyshySRenQTRbUN3b5iwGglmU5/kHzC9mCHoRfLk4cZRKDce9stTUaV9NCZunQfjk8fWzYmB1K3xcgciQ==; 24:6dSn7PhiQ59kUku2zNDImK8Ub43FMRSHAZC+nipuTY+LXm4xmzUMxf2FopaYzqx2n82avzqYArJFepHoXhlUwBnCu3l13f2Sb/a/oODotrU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 7:ku92B/kHWMz5LUQZ0qFzL2FJorvPy1YLSI0Kx+W48du27HyqW4nZooQHLW/feEyB4EB6OTOrRzsIAQDahiztjeRy5ZgUW5TXRgxDScUden7wQXPnH5UVctob1rZheDdyVyDXAMAYB1NIsyWPKIUvT+yd8+bsxQDS0rYefRxNYuF9QH5zDfdmhjlnf+oPdgEfug5vKiiAoLAFxx1NRxkSsU+ta1H+Bt/fPdHaBrBsJV55lFDqLMdNlfQ98rnRb6cv6AmC/3mJSbUwZBBTv1EJ1CM1Vq5OXJZ3kjQVPrgLIM09VQRUSI5irZQGLumvjqLxzN9TAZnh0orceQMRfOxs7A== X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Feb 2017 08:53:22.1130 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0101MB1036 Archived-At: Subject: Re: [Dots] DOTS Telemetry X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 21 Feb 2017 08:53:26 -0000 On 21 Feb 2017, at 15:22, Ehud Doron wrote: > that in order to build a viable anti-DoS service, Viable DDoS mitigation services exist today, and have for years. Lots of them. > both NOC / SOC teams at client and server side will definitely need > some sort of information about the on-going attack being mitigated. This information is already available, in different forms, and has been for years. > Therefore I believe that the so called "Telemetry for Visibility" is > mandatory, It is *not* mandatory to be included in DOTS, according to the sense of the WG. Currently, we are focusing on the signaling mechanisms, communications models, and MVP functionality which allows bidirectional signaling to take place. That is the MVP. Everything else is extra, above and beyond that. If one reads through the various drafts, meeting minutes, and the considerable discussion which has taken place over the history of the WG, one will see that this has already been discussed in great detail, and that the general sense is that it's best to focus on the immediate, well-bounded task of creating a viable standards-based signaling mechanism first. Let's concentrate on the task at hand, first, and get something out the door that vendors and coders can implement and get some immediate relief out there which will make a measurable positive impact on coordinated DDoS mitigation efforts. We definitely want to ensure that DOTS can be extended in future phases to cover areas which the WG membership deem to be in-scope and important. > Meaning that information about attacks (whether we call it telemetry > or use other terminology) need to be presented to the SOC/NOC teams, > and we MUST deal with it as an MVP. I couldn't disagree more. Telemetry is available and used today. There is no need to re-invent that wheel in the DOTS WG. Status-messaging is enough to get DOTS off the ground in an immediately useful and deployable form. Let's concentrate on that, first. Getting deep into telemetry formats is a significant challenge and one which isn't restricted to the DDoS arena. It's both broader and deeper, and much more generally applicable. Once DOTS Phase I is out there and being adopted, we can then take a look at telemetry, and determine if we need to work with the appropriate WGs to enhance existing standards, or simply adopt them as-is. > My concerns are that if such information will not be covered as part > of DOTS standard, we will end up with a lot of vendor extensions and > other "out of band" proprietary signaling... That is the reality today. The initial intent is to supplement, not replace, those siloed systems. Again, note that readily-extensible, standards-based telemetry formats are already in use today. There is no lack of telemetry formats to choose from. At some point, these additional aspects of the problem-space can be addressed. What we're building with DOTS isn't intended to *replace* extant mechanisms - it is a *new* mechanism which provides capabilities which do not already exist. Standards-based telemetry already exists. Standards-based mitigation assistance signaling *doesn't* already exist. And that's the gap DOTS is intended to address. We have to restrict our scope to something that is well-defined, solves real-world problems, and is achievable in a finite amount of time, or we'll never get anything out the door. > and I don't think that this is the ultimate goal of IETF in general > and in particular for DOTS. We are creating something with DOTS which doesn't already exist - i.e., a standards-based mechanism for organizations to request/provide DDoS mitigation assistance. That is something new and immediately useful. Scope-creep is something we should guard against. Let's not make the perfect the enemy of the merely good, yes? ;> > As per the "Telemetry for Mitigation" below, I have some concerns that > this part might be more complicated and can tend to be aligned with a > specific implementation, thus can be difficult to standardized. Correct. > Therefore I think that this part can be considered in the future > phases of DOTS. Concur 100% - we should take a measured look at these additional areas of the problem space after we've addressed the fundamental challenge of inter- (and intra-) organizational DDoS mitigation assistance signaling/response. ----------------------------------- Roland Dobbins From nobody Tue Feb 21 01:31:14 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBE81298A3 for ; Tue, 21 Feb 2017 01:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 EWp6DX3nq6Jy for ; Tue, 21 Feb 2017 01:31:12 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D3512989C for ; Tue, 21 Feb 2017 01:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3486; q=dns/txt; s=iport; t=1487669472; x=1488879072; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6LpOHBZ3P+Qq2v4jh2IlEIYVqs7yvP0T0kLYs9ksdSU=; b=OUGNhxxphijZfeSfXIqwLYIh5/HnZ88T/ow309iL6iiqu9BEHKnlcL6B lF3183QRxFPAmOkvcsOSkRrGV24ZGjaUJiQLm/tShIdsSORJd5FcLGHCQ ZLi0E+OeJyhNuND4GyBQ8N3y2nSxK8v830kYipAvFoWQzzhnuhwI0n/O0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BTAQBwCKxY/5xdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHg1SKCJIWlTSCDSqFeAIagkE/GAECAQEBAQEBAWIdC4R?= =?us-ascii?q?wAQEBBCMRQw4EAgEIEQQBAQMCIwMCAgIwFAEICAIEEwiJZg6uE4Imi1gBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdgQuFQYRvgxeBGg2DHIJfBY9JjD8BhnOLIIIEU4R?= =?us-ascii?q?IiXiTIwEfOIEAUxUYJoZIdYhUgS+BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,189,1484006400"; d="scan'208";a="211040571" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2017 09:31:10 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v1L9VABI007409 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 21 Feb 2017 09:31:10 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Feb 2017 03:31:10 -0600 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1210.000; Tue, 21 Feb 2017 03:31:10 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "dots@ietf.org" Thread-Topic: New Version Notification for draft-reddy-dots-signal-channel-08.txt Thread-Index: AQHSjCCkIbjO+MzHWE6MQfNQQhzR96FzMYZQ Date: Tue, 21 Feb 2017 09:31:10 +0000 Message-ID: <68781b8926724ea9ad41230aeb94b1a0@XCH-ALN-017.cisco.com> References: <148766749366.32553.4722816219476780947.idtracker@ietfa.amsl.com> In-Reply-To: <148766749366.32553.4722816219476780947.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.52.121] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] New Version Notification for draft-reddy-dots-signal-channel-08.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 21 Feb 2017 09:31:14 -0000 VGhpcyByZXZpc2lvbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVkZHktZG90 cy1zaWduYWwtY2hhbm5lbC0wOCBhZGRyZXNzZXMgY29tbWVudHMgZnJvbSBFaHVkIGFuZCBLYW5h bWUuIA0KDQpNYWpvciBjaGFuZ2VzIGFyZToNCg0KMSlET1RTIG1pdGlnYXRpb24gcmVxdWVzdC9y ZXNwb25zZSBhcmUgbWFya2VkIGFzIG5vbi1jb25maXJtYWJsZSBtZXNzYWdlcy4gUmVxdWVzdHMg bWFya2VkIGJ5IHRoZSBET1RTICBjbGllbnQgYXMgTm9uLWNvbmZpcm1hYmxlIG1lc3NhZ2VzIGFy ZSBzZW50IGF0IHJlZ3VsYXIgaW50ZXJ2YWxzIHVudGlsIGEgcmVzcG9uc2UgaXMgcmVjZWl2ZWQg ZnJvbSB0aGUgRE9UUyBzZXJ2ZXIgKFNlZSBTZWN0aW9uIDUuMyBmb3IgbW9yZSBkZXRhaWxzKS4g DQooVGhhbmtzIHRvIHRoZSBmZWVkYmFjayBmcm9tIEZsZW1taW5nLCBBbmRyZXcgYW5kIEVodWQp Lg0KDQoyKUFkZGVkIHN1cHBvcnQgZm9yIHZlbmRvciBzcGVjaWZpYyBwYXJhbWV0ZXJzLg0KDQoz KUFkZGVkIG5ldyBNaXRpZ2F0aW9uIHN0YXR1cyBwYXJhbWV0ZXJzOiBieXRlc19kcm9wcGVkLCBi cHNfZHJvcHBlZCwgcGt0c19kcm9wcGVkIGFuZCBwcHNfZHJvcHBlZC4NCg0KQ29tbWVudHMgYW5k IHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KDQotVGlydQ0KDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAyMSwgMjAx NyAyOjI4IFBNDQo+IFRvOiBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKSA8cHJhc3BhdGlAY2lz Y28uY29tPjsgTW9oYW1lZCBCb3VjYWRhaXINCj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20+OyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+IDx0aXJlZGR5QGNpc2NvLmNvbT4N Cj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yZWRkeS1kb3Rz LXNpZ25hbC1jaGFubmVsLTA4LnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1yZWRkeS1kb3RzLXNpZ25hbC1jaGFubmVsLTA4LnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQgcG9zdGVkIHRvIHRoZQ0K PiBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtcmVkZHktZG90cy1zaWduYWwt Y2hhbm5lbA0KPiBSZXZpc2lvbjoJMDgNCj4gVGl0bGU6CQlEaXN0cmlidXRlZCBEZW5pYWwtb2Yt U2VydmljZSBPcGVuIFRocmVhdCBTaWduYWxpbmcgKERPVFMpDQo+IFNpZ25hbCBDaGFubmVsDQo+ IERvY3VtZW50IGRhdGU6CTIwMTctMDItMjENCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Np b24NCj4gUGFnZXM6CQk0Ng0KPiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJlZGR5LWRvdHMtc2lnbmFsLQ0KPiBjaGFubmVsLTA4LnR4 dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtcmVkZHktZG90cy1zaWduYWwtY2hhbm5lbC8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS1kb3RzLXNpZ25hbC1jaGFubmVsLTA4DQo+ IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt cmVkZHktZG90cy1zaWduYWwtY2hhbm5lbC0NCj4gMDgNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBU aGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIG1lY2hhbmlzbSB0aGF0IGEgRE9UUyBjbGllbnQgY2Fu IHVzZSB0bw0KPiAgICBzaWduYWwgdGhhdCBhIG5ldHdvcmsgaXMgdW5kZXIgYSBEaXN0cmlidXRl ZCBEZW5pYWwtb2YtU2VydmljZSAoRERvUykNCj4gICAgYXR0YWNrIHRvIGFuIHVwc3RyZWFtIERP VFMgc2VydmVyIHNvIHRoYXQgYXBwcm9wcmlhdGUgbWl0aWdhdGlvbg0KPiAgICBhY3Rpb25zIGFy ZSB1bmRlcnRha2VuIChpbmNsdWRpbmcsIGJsYWNraG9sZSwgZHJvcCwgcmF0ZS1saW1pdCwgb3IN Cj4gICAgYWRkIHRvIHdhdGNoIGxpc3QpIG9uIHRoZSBzdXNwZWN0IHRyYWZmaWMuICBUaGUgZG9j dW1lbnQgc3BlY2lmaWVzDQo+ICAgIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsIGluY2x1ZGluZyBI YXBweSBFeWViYWxscyBjb25zaWRlcmF0aW9ucy4gIFRoZQ0KPiAgICBzcGVjaWZpY2F0aW9uIG9m IHRoZSBET1RTIGRhdGEgY2hhbm5lbCBpcyBlbGFib3JhdGVkIGluIGEgY29tcGFuaW9uDQo+ICAg IGRvY3VtZW50Lg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue Feb 21 12:39:58 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80DE129490 for ; Tue, 21 Feb 2017 12:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 BjB0cM58huR1 for ; Tue, 21 Feb 2017 12:39:54 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB4F12944C for ; Tue, 21 Feb 2017 12:39:54 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v1LKdrgv009575 for ; Tue, 21 Feb 2017 15:39:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1487709593; bh=gDn8mp6tcWveeIzRFhD3FukIpxqMjIiMoamzZdg/k8Q=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=ShvPbXSd+2Nn9JDVS5dKoos1DfWVGvccVi5sSFhcn14QzEbyikaFavhLfN17+pyd+ NfiWAvECeEnAeLw0wBH+vUOfSS0mFECgQCp4YnSPeWuOk2RwLib59lgyMw/C6AUGxb 4uZXhcHMIZNNiZiWk47enmMIx69Kis3ecfpu/zic= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v1LKdmhC027330 for ; Tue, 21 Feb 2017 15:39:48 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0319.002; Tue, 21 Feb 2017 15:39:48 -0500 From: "Roman D. Danyliw" To: "dots@ietf.org" Thread-Topic: Reminder: DOTS Virtual Interim Meeting, 2/22/2017 Thread-Index: AdKMgbQg30WXCPfHQ2qsDxgw2Lhgag== Date: Tue, 21 Feb 2017 20:39:47 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104F07F33@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Reminder: DOTS Virtual Interim Meeting, 2/22/2017 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 21 Feb 2017 20:39:56 -0000 Hello WG! A reminder that tomorrow (Wednesday, February 22) we will have a virtual in= terim meeting. I hope that you can join us. Date/Time =3D=3D=3D=3D=3D=3D=3D=3D Wednesday, February 22, 2017 3:00 - 4:30 PM UTC Start time in select local time zones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D San Francisco, USA Wed, February 22, 2017 at 7:00:00 am PST UTC-8 hours=20 New York, USA Wed, February 22, 2017 at 10:00:00 am EST UTC-5 hours=20 London, UK Wed, February 22, 2017 at 3:00:00 pm GMT UTC =20 UTC (GMT) Wed, February 22, 2017 at 3:00:00 pm =20 New Delhi, India Wed, February 22, 2017 at 8:30:00 pm IST UTC+5:30 hour= s=20 Berlin, Germany Wed, February 22, 2017 at 4:00:00 pm CET UTC+1 hour =20 Bangkok, Thailand Wed, February 22, 2017 at 10:00:00 pm ICT UTC+7 hours=20 Beijing, China Wed, February 22, 2017 at 11:00:00 pm CST UTC+8 hours Agenda =3D=3D=3D=3D=3D=3D https://datatracker.ietf.org/meeting/interim-2017-dots-01/agenda/dots/ Meeting Materials =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D https://datatracker.ietf.org/meeting/interim-2017-dots-01/session/dots WebEx Information =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Meeting URL: https://ietf.webex.com/ietf/j.php?MTID=3Dm16c3d7c775e02a7b3b8e12dc7753c778 Meeting number: 646 802 945 Meeting password: PVNMU3yM =20 Dial-in Numbers: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 646 802 945 From nobody Tue Feb 21 13:19:55 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA4F129CDA for ; Tue, 21 Feb 2017 13:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 zRjzG10dtJiZ for ; Tue, 21 Feb 2017 13:19:51 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25568129517 for ; Tue, 21 Feb 2017 13:19:51 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Tue, 21 Feb 2017 16:19:49 -0500 From: Dave Dolson To: "Mortensen, Andrew" Thread-Topic: feedback on draft-ietf-dots-requirements Thread-Index: AdJCw56N3It0vvnJSvSfOG8E2IPZ9BI48yMAADWyNkA= Date: Tue, 21 Feb 2017 21:19:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E987051D4D8wtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] feedback on draft-ietf-dots-requirements X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 21 Feb 2017 21:19:53 -0000 --_000_E8355113905631478EFF04F5AA706E987051D4D8wtlexchp1sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBmZWVsIHNvbWUgZGlzY29ubmVjdC4gTWF5YmUgZm9sa3MgY291bGQgc2hhcmUgdGhlaXIgdmll d3Mgb24gdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6DQoNCg0KMS4gICAgICAgSXMgYSBkb3RzIHNp Z25hbC1jaGFubmVsIHJlcXVlc3QgYSBjb21tYW5kIG9yIGFuIGFkdmlzb3J5PyBJLmUuLCBNVVNU IHRoZSBzZXJ2ZXIgbWl0aWdhdGUsIG9yIGRvZXMgdGhlIHNlcnZlciBzaW1wbHkgY29uc2lkZXIg aXQgYSBkYXRhLXBvaW50IGluIHRoZSBvbmdvaW5nIGJhdHRsZT8NCltNeSBvcGluaW9uOiBhZHZp c29yeTsgdGhlIGNsaWVudCBpcyBub3QgYWx3YXlzIHJpZ2h0IG9yIHRydXN0d29ydGh5LCBvciBt aXRpZ2F0aW9uIGlzIG5vdCBhbHdheXMgYXZhaWxhYmxlXQ0KDQoNCjIuICAgICAgIElzIHRoZXJl IGEgcXVlc3Rpb24gb2Ygb3ZlcmxhcHBpbmcgcmVzb3VyY2VzPyBJLmUuLCBNYXkgZGlmZmVyZW50 IGNsaWVudHMgYXNrIGZvciBtaXRpZ2F0aW9uIG9mIHRoZSBzYW1lIHNjb3BlPyAoSWYgbm90LCBo b3cgaXMgb3duZXJzaGlwIG9mIHJlc291cmNlcyBkZXRlcm1pbmVkPykNCltNeSBvcGluaW9uOiB0 aGVyZSBpcyBvd25lcnNoaXAsIHNvIG92ZXJsYXAgaXMgbm90IHBvc3NpYmxlLiBOZWdvdGlhdGVk IGluIGRhdGEgY2hhbm5lbC5dDQoNCg0KMy4gICAgICAgSXMgYSBzZXNzaW9uIHJlcXVpcmVkIChs aWtlIERpYW1ldGVyKT8gT3IgY2FuIGVhY2ggcmVxdWVzdCBzdGFuZCBhbG9uZSAobGlrZSBETlMp Pw0KW015IG9waW5pb246IHNlc3Npb24gaXMgbm90IHJlcXVpcmVkLCBhbmQgYnkgaXRzIGNvbXBs ZXhpdHkgaGFybWZ1bC5dDQoNCg0KLURhdmUNCg0KDQoNCkZyb206IE1vcnRlbnNlbiwgQW5kcmV3 IFttYWlsdG86YW1vcnRlbnNlbkBhcmJvci5uZXRdDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDIw LCAyMDE3IDE6MzEgUE0NClRvOiBEYXZlIERvbHNvbg0KQ2M6IGRvdHNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBmZWVkYmFjayBvbiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzDQoNClRoYW5r cywgRGF2ZS4gVGhpcyBpcyB2ZXJ5IGhlbHBmdWwuIE15IChleHRyZW1lbHkgdGFyZHkpIHJlc3Bv bnNlcyBhcmUgaW5saW5lLiBJ4oCZdmUgc25pcHBlZCBtb3N0IG9mIHRoZSBtaW5vciByZXBocmFz aW5nIHN1Z2dlc3Rpb25zLiBBbGwgY29tbWVudHMgYXJlIG1lIHNwZWFraW5nIGZvciBteXNlbGYs IG5vdCBuZWNlc3NhcmlseSBmb3IgdGhlIG90aGVyIHJlcXVpcmVtZW50cyBkcmFmdCBlZGl0b3Jz Lg0KDQpJ4oCZdmUgb3BlbmVkIGlzc3VlcyBvbiBnaXRodWIgZm9yIG1vc3Qgb2YgdGhlc2UgY29t bWVudHMuDQoNCk9uIE5vdiAyNiwgMjAxNiwgYXQgOTozMSBQTSwgRGF2ZSBEb2xzb24gPGRkb2xz b25Ac2FuZHZpbmUuY29tPG1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbT4+IHdyb3RlOg0KDQri gKZzbmlwLi4uDQoxLjINCuKApnNuaXAuLi4NCkZvciDigJxjb3VudGVybWVhc3VyZeKAnSwgdGhp cyBzb3VuZHMgbGlrZSBvbmx5IHBhY2tldCBmaWx0ZXJpbmcuIElzIHRoYXQgYWNjdXJhdGUgYW5k IGNvbXBsZXRlPyBDb3VsZCB0YXItcGl0IG9yIHJvdXRpbmcgY2hhbmdlcyBiZSBpbmNsdWRlZCBp biBjb3VudGVybWVhc3VyZXM/DQoNCkkgZG9u4oCZdCB3YW50IHRoZSBkb2N1bWVudCB0byByZXN0 cmljdCB0aGUgZGVmaW5pdGlvbiBvZiBjb3VudGVybWVhc3VyZSwgYnV0IEnigJltIGFsc28gbm90 IGtlZW4gdG8gZW5zaHJpbmUgc3BlY2lmaWMgdHlwZXMgb2YgY291bnRlcm1lYXN1cmUsIGVpdGhl ci4gSeKAmWxsIHJldmlzZSB0byBtYWtlIGl0IGNsZWFyZXIuDQoNCg0KSXMg4oCcc2lnbmFsIGNo YW5uZWzigJ0gaW50ZW5kZWQgdG8gYmUgdGhlIHNhbWUgdGhpbmcgYXMgdGhlIOKAnHNlc3Npb27i gJ0gbWVudGlvbmVkIGluIHRoZSBhcmNoaXRlY3R1cmU/IEkgdGhpbmsgc28sIGFuZCB0ZXJtaW5v bG9neSBzaG91bGQgYmUgbWFkZSBjb25zaXN0ZW50IGJldHdlZW4gdGhlIGRvY3MuIElmIG5vdCwg SSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBjaGFubmVsIGFuZCBz ZXNzaW9uLg0KDQpTcGVha2luZyBmb3IgbXlzZWxmLCB0aGUg4oCcY2hhbm5lbOKAnSBkaXN0aW5j dGlvbiBpcyBtZWFudCB0byBkaXN0aW5ndWlzaCB0aGUgdW5yZWxpYWJsZSwgbGlnaHR3ZWlnaHQg U09TIG1lc3NhZ2VzIHRvIGJlIHVzZWQgd2hlbiB1bmRlciBhdHRhY2sgZnJvbSB0aGUgcmVsaWFi bGUgbWVzc2FnaW5nIHJlcXVpcmVkIHRvIGUuZy4gbWFuYWdlIGZpbHRlcnMgYW5kIHJlc291cmNl IGFsaWFzZXMuIFRoZSDigJxzaWduYWxpbmcgc2Vzc2lvbuKAnSBpbiB0aGUgYXJjaGl0ZWN0dXJl IGRvY3VtZW50IGlzIGFjdGl2ZSBtZXNzYWdpbmcgYmV0d2VlbiBET1RTIGFnZW50cyBvdmVyIHRo ZSBzaWduYWwgY2hhbm5lbC4NCg0KDQpTaG91bGQg4oCcRmlsdGVy4oCdIGJlIGxpbWl0ZWQgdG8g dGhlIHR3byBhY3Rpb25zIG9mIHJhdGUtbGltaXRpbmcgb3IgZGlzY2FyZGluZz8gIElzIGZpbHRl ciByZWFsbHkgaW50ZW5kZWQgdG8gaW5jbHVkZSBhY3Rpb24sIG9yIGp1c3QgdGhlIG1hdGNoIGNy aXRlcmlhPw0KDQpJdCBzb3VuZHMgbGlrZSB5b3XigJlyZSByZWFsbHkgYXNraW5nIHdoZXRoZXIg d2Ugc2hvdWxkIGxlYXZlIHRoZSBkZWZpbml0aW9uIG9mIOKAnGZpbHRlcmluZ+KAnSB1cCB0byB0 aGUgRE9UUyBzZXJ2ZXIvbWl0aWdhdG9yLiBJIHdvcnJ5IHRoYXQgbGVhdmluZyDigJxmaWx0ZXJp bmfigJ0gbG9vc2VseSBkZWZpbmVkIHdpbGwgbGVhZCB0byBjb25mdXNpb24gZnVydGhlciBkb3du IHRoZSBsaW5lLiBJIHRoaW5rIHdlIG5lZWQgZXhwbGljaXQgYWN0aW9uczogZGlzY2FyZCBpcyB2 ZXJ5IGRpZmZlcmVudCBmcm9tIHJhdGUtbGltaXQuDQoNCkFzIEkgc2VlIGl0LCBmaWx0ZXJpbmcg aXMgZGlzdGluY3QgZnJvbSB2ZW5kb3IgZXh0ZW5zaW9ucyB3aGljaCBtaWdodCBpbmNsdWRlIGNv dW50ZXJtZWFzdXJlIHNwZWNpZmljcy4gSSBkb27igJl0IHRoaW5rIERPVFMgaXMgYSBnZW5lcmFs IHB1cnBvc2UgaW50ZXJmYWNlIGZvciBjb3VudGVybWVhc3VyZSBjb25maWd1cmF0aW9uLg0KDQpT aW1pbGFybHkgZm9yIOKAnEJsYWNrbGlzdOKAnTogaXMgYmxvY2sgdGhlIG9ubHkgdmFsaWQgYWN0 aW9uIGZvciBibGFjay1saXN0ZWQgYWRkcmVzc2VzPw0KDQpZZXMsIHRoYXTigJlzIHRoZSBkaXN0 aW5ndWlzaGluZyBjaGFyYWN0ZXJpc3RpYyBvZiBhIGJsYWNrbGlzdGVkIHNvdXJjZS4gQSB3aGl0 ZWxpc3RlZCBzb3VyY2UgaXMgYWx3YXlzIGFsbG93ZWQgdG8gcGFzcy4gVGhlIERPVFMgY2xpZW50 IGhhcyBmdWxsIGNvbnRyb2wgb3ZlciB0aGUgYmxhY2stL3doaXRlLWxpc3RzLCB0aG91Z2ggdGhl IHNjb3BlIGlzIHJlc3RyaWN0ZWQgYnkgdGhlIERPVFMgc2VydmVyIHRvIHByZWZpeGVzL3Jlc291 cmNlcyBiZWxvbmdpbmcgdG8gdGhlIERPVFMgY2xpZW50Lg0KDQoyLg0KVGhlIHNlY29uZCBwYXJh Z3JhcGggc2F5cyDigJxET1RTIGlzIGFuIGFkdmlzb3J5IHByb3RvY29sLuKAnSBJIHRob3VnaHQg dGhpcyBtaWdodCBtZWFuIHRoYXQgKGEpIGEgY2xpZW504oCZcyByZXF1ZXN0IGZvciBhaWQgbWF5 IGJlIGlnbm9yZWQgYW5kIChiKSBtaXRpZ2F0aW9uIG1heSBiZSBkb25lIHByaW9yIHRvIHJlcXVl c3Qgb3IgYWZ0ZXIgd2l0aGRyYXdhbC4gV291bGQgdGhhdCBpZGVhIGJlIGFjY3VyYXRlPw0KDQpJ IHRoaW5rIChhKSBpcyBjb3JyZWN0LCB0aG91Z2ggaWdub3JpbmcgYSByZXF1ZXN0IHdpdGhvdXQg cHJvdmlkaW5nIGEgcmVhc29uIHdoZW4gYSBzZXJ2aWNlIGFncmVlbWVudCBpcyBpbiBwbGFjZSBz ZWVtcyBsaWtlIGEgcG9vciB3YXkgdG8gbWFuYWdlIGEgc2VydmljZS4gSW4gZ2VuZXJhbCBhIERP VFMgcmVxdWVzdCBmb3IgbWl0aWdhdGlvbiBzaG91bGQgcmVzdWx0IGluIG1pdGlnYXRpb24sIGFz c3VtaW5nIGJ1c2luZXNzIG9yIHNlcnZpY2UgYWdyZWVtZW50cyBhcmUgaW4gcGxhY2UsIGJ1dCBt aXRpZ2F0aW5nIHRoZSBhdHRhY2sgbWlnaHQgaW52b2x2ZSBtb3JlIHRoYW4ganVzdCBhDQoNCklu IGNhbGxpbmcgRE9UUyDigJxhZHZpc29yeeKAnSBJIHdhcyB0cnlpbmcgdG8gZW1waGFzaXplIHR3 byBwb2ludHM6IHRoZSBkaWZmaWN1bHR5IG9mIG1haW50YWluaW5nIHJlbGlhYmxlIG1lc3NhZ2lu ZyB1bmRlciBhdHRhY2sgY29uZGl0aW9ucyAod2l0aCB0aGUgY29yb2xsYXJ5IHRoYXQgYSBET1RT IHNlcnZlciBtYXkgbm90IGJlIGFibGUgdG8gaGVscCBldmVuIGlmIGEgcmVxdWVzdCBnZXRzIHRo cm91Z2gpOyBhbmQgdGhlIGZhY3QgdGhhdCBET1RTIGlzIG5vdCBhIGdlbmVyYWwgcHVycG9zZSBt aXRpZ2F0aW9uIEFQSS4NCg0KTWF5YmUgSSBzaG91bGQgY2xhcmlmeSB0aGF0IGZ1cnRoZXIuIEkg YmVsaWV2ZSB0aGUgRE9UUyAqc2lnbmFsIGNoYW5uZWwqIGlzIG5vdCBhIGdlbmVyYWwgcHVycG9z ZSBtaXRpZ2F0aW9uIEFQSS4gVGhlIERPVFMgZGF0YSBjaGFubmVsIGNvdWxkIGV2b2x2ZSBpbnRv IHRoYXQgYXMgYSBzb3J0IG9mIERPVFMgY29udHJvbCBwcm90b2NvbCwgaW4gd2hpY2ggdGhlIGlt cGFjdCBvZiBhbiBhdHRhY2sgb24gdGhlIGNvbW11bmljYXRpb24gbGF5ZXIgYmV0d2VlbiBjbGll bnQgYW5kIHNlcnZlciBpcyBub3QgYSBjb25jZXJuLg0KDQoNCihNeSB0aGlua2luZyBpcyB0aGF0 IGEgRE9UUyBzZXJ2ZXIgbWF5IGtub3cgYmV0dGVyIHRoYW4gdGhlIGNsaWVudCBiYXNlZCBvbiBh IHdpZGVyIHNvdXJjZSBvZiB0ZWxlbWV0cnkuKQ0KDQpBZ3JlZWQuIE9uY2UgYSBtaXRpZ2F0b3Ig YmVnaW5zIGZpbHRlcmluZyB0cmFmZmljIGJvdW5kIGZvciB0aGUgZG9tYWluIG9mIHRoZSBET1RT IGNsaWVudCwgdGhlIERPVFMgY2xpZW504oCZcyB2aWV3IGludG8gdGhlIGF0dGFjayBpcyBza2V3 ZWQuDQoNCg0KLSBpbiBHRU4tMDA0LCBjb25zaWRlciBwaWNraW5nIGEgc3BlY2lmaWMgTVRVIHNp emUsIGxpa2UgNTAwIGJ5dGVzLCBiZWNhdXNlIG90aGVyd2lzZSB0aGVyZSBpcyBubyB3YXkgdG8g anVkZ2UgaWYgdGhlIHByb3RvY29sIG1lZXRzIHJlcXVpcmVtZW50cy4NCg0KVGhpcyBoYXMgYmVj b21lIG1vcmUgaW1wb3J0YW50IHNpbmNlIHlvdSBzdWdnZXN0ZWQgaXQsIGluIGxpZ2h0IG9mIHRo ZSByZWNlbnQgdGhyZWFkIG9uIHRlbGVtZXRyeS4gZHJhZnQtcmVkZHktZG90cy1zaWduYWwtY2hh bm5lbCBpcyBzdWdnZXN0aW5nIDUwMCBieXRlcyBpbiB0aGUgZXZlbnQgdGhlIGNsaWVudCBjYW7i gJl0IGRpc2Nlcm4gcGF0aCBNVFUuIEnigJltIGNvbWZvcnRhYmxlIHdpdGggdGV4dCB0byB0aGUg ZWZmZWN0IHRoYXQgY2xpZW50cyBTSE9VTEQgdHJ5IHRvIGRldGVybWluZSBwYXRoIE1UVSwgYW5k IGZhbGwgYmFjayB0byA1MDAgYnl0ZXMgaWYgaXQgY2Fu4oCZdCBiZSBkaXNjb3ZlcmVkLg0KDQoN CkluIDIuMiwNCuKApiBzbmlwIC4uLg0KT1AtMDA0OiBUaGlzIHJlcXVpcmVtZW50IGhhcyBzZXZl cmFsIGlkZWFzIGluIGl0LCB3aGljaCBJIHRoaW5rIHNob3VsZCBiZSBicm9rZW4gaW50byBtdWx0 aXBsZSByZXF1aXJlbWVudHM6DQooYSkgICAgVGhlIGlkZWEgdGhhdCBtZXNzYWdlcyBiZSBhY2tu b3dsZWRnZWQgd2l0aCBhIHN0YXR1cyBjb2RlLg0KLSAgICAgICAgICBCdXQgaXQgaXMgdW5jbGVh ciB3aGV0aGVyIHRoZSBzdGF0dXMgbXVzdCBiZSBkZWxpdmVyZWQgaW1tZWRpYXRlbHksIG9yIHJl cG9ydGVkIGxhdGVyLiBJIGV4cGVjdCB0aGVyZSBjb3VsZCBiZSBhbiBpbW1lZGlhdGUg4oCcSSBo ZWFyIHlvdXIgcmVxdWVzdOKAnSwgd2hpY2ggZG9lc27igJl0IG5lY2Vzc2FyaWx5IG1lYW4gYW55 dGhpbmcgY2FuIGJlIGRvbmUuIFRoZXJlIHNob3VsZCBiZSBhIHdheSBmb3IgdGhlIGNsaWVudCB0 byBsYXRlciBhc2ssIOKAnGhvdyBhcmUgeW91IGRvaW5nIHdpdGggdGhhdCByZXF1ZXN0P+KAnQ0K DQpJIG1lYW50IHRoaXMgdG8gYmUgbGVzcyByZXN0cmljdGl2ZSB0aGFuIHdoYXQgeW914oCZdmUg ZGVzY3JpYmVkLiBUaGVyZSBzaG91bGQgYmUgc29tZSB3YXkgZm9yIHRoZSBET1RTIGNsaWVudCB0 byBkZXRlY3QgdGhhdCBpdHMgbWVzc2FnZXMgYXJlIGJlaW5nIHJlY2VpdmVkL3Byb2Nlc3NlZCBv ciBsb3N0LCBhbmQgdGhlIHNhbWUgaXMgdHJ1ZSBmb3IgdGhlIERPVFMgc2VydmVyLiBUaGF0IGRv ZXNu4oCZdCBoYXZlIHRvIG1lYW4gYW4gSFRUUC1saWtlIG1vZGVsLiBGb3IgZXhhbXBsZSwgaW4g dGhlIHByb3RvY29sIGRyYWZ0IE5payBUZWFndWUgYW5kIEkgaGF2ZSBwdXQgdG9nZXRoZXIsIHRo ZSBzaWduYWwgY2hhbm5lbCBpcyBvbmdvaW5nLCBwZXJpb2RpYyBjb21tdW5pY2F0aW9uIGJldHdl ZW4gY2xpZW50IGFuZCBzZXJ2ZXIuIFRoZSBjbGllbnQgZG9lcyBub3QgbmVlZCB0byBzZW5kIGEg c2VwYXJhdGUgbWVzc2FnZSB0byBhc2sgYWJvdXQgcmVxdWVzdCBzdGF0dXMsIHNpbmNlIHRoZSBE T1RTIHNlcnZlciB3aWxsIHNlbmQgaXQgaW4gYSBmZXcgc2Vjb25kcyBhbnl3YXkuDQoNCg0KKGIp ICAgV2hldGhlciB0aGUgc2VydmVyIE1VU1QgZG8gYXMgaXQgaXMgdG9sZC4NCi0gICAgICAgICAg T24gdGhpcyBwb2ludCwgSSB0aGluayB0aGUg4oCcTVVTVCBjZWFzZSBtaXRpZ2F0aW9uIGFjdGl2 aXR54oCdIGlzIHdyb25nLCBzaW5jZSB0aGUgc2VydmVyIG1heSBoYXZlIG90aGVyIGV2aWRlbmNl IG9yIG90aGVyIGNsaWVudHMgcmVxdWVzdGluZyB0aGUgbWl0aWdhdGlvbi4gVGhpcyBpcyBhY2tu b3dsZWRnZWQgYnkgdGhlIOKAnG1heSBjb250aW51ZSBtaXRpZ2F0aW5n4oCdIGxhdGVyIGluIHRo ZSBwYXJhZ3JhcGguIFNvIGF0IG1pbmltdW0gdGhlIE1VU1QgaXMgdG9vIHN0cm9uZy4NCg0KVGhl IGZ1bGwgcGhyYXNlIGlzIOKAnE1VU1QgY2Vhc2UgbWl0aWdhdGlvbiBhcyBxdWlja2x5IGFzIHBv c3NpYmxl4oCdLCBieSB3aGljaCBJIG1lYW50IHRvIGV4cHJlc3MgdGhlIGltcG9ydGFuY2Ugb2Yg YWxsb3dpbmcgdGhlIHNlcnZlciB0byBtYWludGFpbiB0aGUgbWl0aWdhdGlvbiBmb3IgYSBzaG9y dCBwZXJpb2QgdG8gcmVkdWNlIHRoZSBpbXBhY3Qgb2YgYSBET1RTIGNsaWVudCByYXBpZGx5IHRv Z2dsaW5nIG1pdGlnYXRpb24uIEl0IHNvdW5kcyBsaWtlIHRoZSBkdXJhdGlvbiBvZiB0aGF0IHNo b3J0IHBlcmlvZCBuZWVkcyB0byBiZSBkZWZpbmVkLg0KDQpJIHRoaW5rIHR3byB0aGluZ3Mgc2hv dWxkIGJlIGNsZWFyIGluIHRoZSBmaW5hbCB0ZXh0Og0KDQoxKSBUaGUgRE9UUyBjbGllbnQgY2Fu IGNlYXNlIHRvIGJlIHRoZSBjYXVzZSBmb3IgYSBtaXRpZ2F0aW9uIGF0IGFueSB0aW1lIGJ5IHNl bmRpbmcgYSBtaXRpZ2F0aW9uIHRlcm1pbmF0aW9uIHJlcXVlc3QsIGJ1dCBjYW5ub3QgY29uc2lk ZXIgYSBtaXRpZ2F0aW9uIHRlcm1pbmF0ZWQgdW50aWwgY29uZmlybWF0aW9uIGZyb20gdGhlIHNl cnZlci4gKE1pdGlnYXRpb24gbGlmZXRpbWUgaXMgdGhlcmUgdG8gaGFuZGxlIHRoZSBjYXNlcyB3 aGVyZSB0aGUgc2VydmVy4oCZcyBjb25maXJtYXRpb24gaXMgbm90IGRlbGl2ZXJlZC4pDQoNCjIp IE9uY2UgYSBET1RTIGNsaWVudCB0ZWxscyBhIERPVFMgc2VydmVyIHRvIHN0b3AgbWl0aWdhdGlu ZywgdGhlIERPVFMgY2xpZW50IGlzIG5vIGxvbmdlciByZXNwb25zaWJsZSBmb3IgdGhlIG1pdGln YXRpb24uIFRoZSBET1RTIHNlcnZlci9taXRpZ2F0b3IgY2FuIGNvbnRpbnVlIG1pdGlnYXRpbmcg YXJiaXRyYXJpbHksIGJ1dCBhZnRlciB0aGUgbWl0aWdhdGlvbiB0ZXJtaW5hdGlvbiBncmFjZSBw ZXJpb2QgZWxhcHNlcyBhbmQgdGhlIGNsaWVudCBoYXNu4oCZdCByZW5ld2VkIGEgcmVxdWVzdCBm b3IgbWl0aWdhdGlvbiwgYWxsIHJlc3BvbnNpYmlsaXR5IGZvciB0aGUgbWl0aWdhdGlvbiBpcyBi b3JuZSBieSB0aGUgRE9UUyBzZXJ2ZXIgZG9tYWluLg0KDQoNCk9QLTAwNi4gSSB3b3VsZCBsaWtl IHRvIHNlZSBhbGwgb2Ygc3BlY2lmaWMgc2NvcGVzIHByZWNpc2VseSBkZWZpbmVkIGFzIHJlcXVp cmVkIG9yIG9wdGlvbmFsLCBidXQgbm90IGFzIGV4YW1wbGVzLg0KDQpZZXMsIHRoaXMgaXMgYSBn b29kIHN1Z2dlc3Rpb24uDQoNCg0KQWxzbywgSeKAmW0gbm90IGNsZWFyIG9uIHdoYXQgRE5TIG5h bWUgZmlsdGVyaW5nIG1lYW5zOiBpcyB0aGlzIGZvciBmaWx0ZXJpbmcgRE5TIHBhY2tldHMsIG9y IGZvciBsb29raW5nIHVwIHRoZSBuYW1lIGFuZCBmaWx0ZXJpbmcgdGhlIGNvcnJlc3BvbmRpbmcg YWRkcmVzc2VzPw0KDQpJdOKAmXMgbm90IEROUyBuYW1lIGZpbHRlcmluZywgYnV0IGluZGljYXRp bmcgd2hpY2ggRlFETnMgbmVlZCBtaXRpZ2F0aW9uLg0KDQoNCg0KT1AtMDA4LiBJIGhvcGUgdGhl cmUgaXNu4oCZdCBnb2luZyB0byBiZSBhbiBhcmd1bWVudCBhYm91dCB0aGlzLCBidXTigKYgSSBi ZWxpZXZlIGl0IGlzIG5vdCBhIGNsaWVudCBlcnJvciB0byBhc2sgZm9yIGEgbWl0aWdhdGlvbiB0 aGF0IGNvbmZsaWN0cyB3aXRoIGFub3RoZXIgY2xpZW50IChob3cgY291bGQgaXQgZXZlbiBrbm93 PykuIFJhdGhlciwgaXQgaXMgdXAgdG8gdGhlIHNlcnZlciB0byB3ZWlnaCB0aGUgdmFyaW91cyBy ZXF1ZXN0cyBhbmQgYWN0IGZvciB0aGUgb3ZlcmFsbCBnb29kLiBBcyBwYXJhZ3JhcGggMiBvZiBz ZWN0aW9uIDIgc2F5cywg4oCcRE9UUyBpcyBhbiBhZHZpc29yeSBwcm90b2NvbOKAnS4NCkkgZG9u 4oCZdCBldmVuIHRoaW5rIGFuIG92ZXJsYXBwaW5nIHByZWZpeCByYW5nZSBpcyBhbiBlcnJvcjsg cmF0aGVyIGJvdGggY2xpZW50cyBoYXZlIGlkZW50aWZpZWQgdGhlIHNhbWUgYXR0YWNrLg0KDQpU aGlzIGlzIGEgZmFpciBjb3VudGVycG9pbnQuIOKAnEFjdCBmb3IgdGhlIG92ZXJhbGwgZ29vZOKA nSBpcyB1bmZvcnR1bmF0ZWx5IG5vdCBjb25jcmV0ZSBlbm91Z2ggZm9yIGEgcmVxdWlyZW1lbnQu IENhc2VzIGxpa2UgdHdvIERPVFMgY2xpZW50cyByZXF1ZXN0aW5nIG1pdGlnYXRpb24gZm9yIHRo ZSBzYW1lIHJlc291cmNlcyBhcmUgZWFzeSB0byBoYW5kbGXigJR0aGUgc2VydmVyIGp1c3QgbGV0 cyB0aGUgbG9zaW5nIGNsaWVudCBrbm93IG1pdGlnYXRpb24gaXMgYWxyZWFkeSBpbiBwcm9ncmVz c+KAlGJ1dCBwYXJ0aWFsbHkgb3ZlcmxhcHBpbmcgbWl0aWdhdGlvbiByZXF1ZXN0cyBhcmUgaGFy ZGVyIHRvIGhhbmRsZS4gRG9lcyB0aGUgc2VydmVyIG5vdGlmeSBlYWNoIGNsaWVudCB0aGF0IHRo ZSBhY3R1YWwgbWl0aWdhdGlvbiBzY29wZSBpcyBsYXJnZXIgdGhhbiBvcmlnaW5hbGx5IHJlcXVl c3RlZD8NCg0KDQoyLjUgIC0gRGF0YSBtb2RlbCByZXF1aXJlbWVudHMNCknigJltIG5vdCBzdXJl IHdoYXQgdG8gbWFrZSBvZiB0aGlzIHNlY3Rpb24uIEkgdGhpbmsgSSBqdXN0IHdhbnQgdG8gcmV2 aWV3IHRoZSBkYXRhIG1vZGVsLg0KDQpJ4oCZbSBjb21mb3J0YWJsZSBqdXN0IHJlbW92aW5nIHRo aXMgc2VjdGlvbi4gV2l0aCBGbGVtbWluZydzIGRyYWZ0IGFwcGFyZW50bHkgZXZvbHZpbmcgbW9y ZSB0b3dhcmQgaW5mb3JtYXRpb24gbW9kZWwsIGRvIHdlIG5lZWQgdG8gZGlzY3VzcyBkYXRhIG1v ZGVsIGF0IGFsbCBvdXRzaWRlIG9mIHRoZSBzb2x1dGlvbnMgZHJhZnRzPw0KDQphbmRyZXcNCg== --_000_E8355113905631478EFF04F5AA706E987051D4D8wtlexchp1sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFw aCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdp bi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFy Z2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uYXBwbGUt Y29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9 DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1p ZDoxNjUyNTYxOTczOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoxNzAwODMxNjYwIDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4 NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30N CkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE3NzEzOTMzMDY7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNDExMjA3NDYwIC0xNDcwMDQwMjMyIDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6NTsNCglt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZmVlbCBzb21lIGRpc2Nv bm5lY3QuIE1heWJlIGZvbGtzIGNvdWxkIHNoYXJlIHRoZWlyIHZpZXdzIG9uIHRoZSBmb2xsb3dp bmcgcXVlc3Rpb25zOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SXMgYSBkb3RzIHNpZ25hbC1jaGFubmVsIHJlcXVlc3QgYSBjb21tYW5k IG9yIGFuIGFkdmlzb3J5PyBJLmUuLCBNVVNUIHRoZSBzZXJ2ZXIgbWl0aWdhdGUsIG9yIGRvZXMg dGhlIHNlcnZlciBzaW1wbHkgY29uc2lkZXIgaXQgYSBkYXRhLXBvaW50IGluIHRoZQ0KIG9uZ29p bmcgYmF0dGxlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bTXkgb3BpbmlvbjogYWR2 aXNvcnk7IHRoZSBjbGllbnQgaXMgbm90IGFsd2F5cyByaWdodCBvciB0cnVzdHdvcnRoeSwgb3Ig bWl0aWdhdGlvbiBpcyBub3QgYWx3YXlzIGF2YWlsYWJsZV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklzIHRoZXJlIGEgcXVlc3Rpb24g b2Ygb3ZlcmxhcHBpbmcgcmVzb3VyY2VzPyBJLmUuLCBNYXkgZGlmZmVyZW50IGNsaWVudHMgYXNr IGZvciBtaXRpZ2F0aW9uIG9mIHRoZSBzYW1lIHNjb3BlPyAoSWYgbm90LCBob3cgaXMgb3duZXJz aGlwIG9mIHJlc291cmNlcw0KIGRldGVybWluZWQ/KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5bTXkgb3BpbmlvbjogdGhlcmUgaXMgb3duZXJzaGlwLCBzbyBvdmVybGFwIGlzIG5vdCBw b3NzaWJsZS4gTmVnb3RpYXRlZCBpbiBkYXRhIGNoYW5uZWwuXTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXMgYSBzZXNzaW9uIHJlcXVp cmVkIChsaWtlIERpYW1ldGVyKT8gT3IgY2FuIGVhY2ggcmVxdWVzdCBzdGFuZCBhbG9uZSAobGlr ZSBETlMpPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bTXkgb3Bpbmlvbjogc2Vzc2lv biBpcyBub3QgcmVxdWlyZWQsIGFuZCBieSBpdHMgY29tcGxleGl0eSBoYXJtZnVsLl08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tRGF2ZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTW9ydGVuc2VuLCBBbmRyZXcgW21haWx0bzphbW9y dGVuc2VuQGFyYm9yLm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDIw LCAyMDE3IDE6MzEgUE08YnI+DQo8Yj5Ubzo8L2I+IERhdmUgRG9sc29uPGJyPg0KPGI+Q2M6PC9i PiBkb3RzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBmZWVkYmFjayBvbiBkcmFm dC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmtzLCBEYXZlLiBUaGlzIGlzIHZlcnkgaGVscGZ1bC4gTXkgKGV4 dHJlbWVseSB0YXJkeSkgcmVzcG9uc2VzIGFyZSBpbmxpbmUuIEnigJl2ZSBzbmlwcGVkIG1vc3Qg b2YgdGhlIG1pbm9yIHJlcGhyYXNpbmcgc3VnZ2VzdGlvbnMuIEFsbCBjb21tZW50cyBhcmUgbWUg c3BlYWtpbmcgZm9yIG15c2VsZiwgbm90IG5lY2Vzc2FyaWx5IGZvciB0aGUgb3RoZXIgcmVxdWly ZW1lbnRzIGRyYWZ0IGVkaXRvcnMuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPknigJl2ZSBvcGVuZWQgaXNzdWVzIG9uIGdpdGh1YiBmb3IgbW9zdCBvZiB0 aGVzZSBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBOb3YgMjYsIDIwMTYsIGF0IDk6MzEgUE0sIERhdmUgRG9s c29uICZsdDs8YSBocmVmPSJtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20iPmRkb2xzb25Ac2Fu ZHZpbmUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKApnNuaXAuLi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjEuMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+4oCmc25pcC4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIOKAnGNv dW50ZXJtZWFzdXJl4oCdLCB0aGlzIHNvdW5kcyBsaWtlIG9ubHkgcGFja2V0IGZpbHRlcmluZy4g SXMgdGhhdCBhY2N1cmF0ZSBhbmQgY29tcGxldGU/IENvdWxkIHRhci1waXQgb3Igcm91dGluZyBj aGFuZ2VzIGJlIGluY2x1ZGVkIGluIGNvdW50ZXJtZWFzdXJlcz88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBkb27igJl0IHdhbnQgdGhlIGRvY3VtZW50IHRvIHJlc3RyaWN0IHRoZSBkZWZp bml0aW9uIG9mIGNvdW50ZXJtZWFzdXJlLCBidXQgSeKAmW0gYWxzbyBub3Qga2VlbiB0byBlbnNo cmluZSBzcGVjaWZpYyB0eXBlcyBvZiBjb3VudGVybWVhc3VyZSwgZWl0aGVyLiBJ4oCZbGwgcmV2 aXNlIHRvIG1ha2UgaXQgY2xlYXJlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JcyDigJxzaWduYWwgY2hh bm5lbOKAnSBpbnRlbmRlZCB0byBiZSB0aGUgc2FtZSB0aGluZyBhcyB0aGUg4oCcc2Vzc2lvbuKA nSBtZW50aW9uZWQgaW4gdGhlIGFyY2hpdGVjdHVyZT8gSSB0aGluayBzbywgYW5kIHRlcm1pbm9s b2d5IHNob3VsZCBiZSBtYWRlIGNvbnNpc3RlbnQgYmV0d2VlbiB0aGUgZG9jcy4NCiBJZiBub3Qs IEkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gY2hhbm5lbCBhbmQg c2Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNwZWFraW5nIGZvciBteXNlbGYsIHRoZSDigJxjaGFubmVs4oCdIGRpc3Rp bmN0aW9uIGlzIG1lYW50IHRvIGRpc3Rpbmd1aXNoIHRoZSB1bnJlbGlhYmxlLCBsaWdodHdlaWdo dCBTT1MgbWVzc2FnZXMgdG8gYmUgdXNlZCB3aGVuIHVuZGVyIGF0dGFjayBmcm9tIHRoZSByZWxp YWJsZSBtZXNzYWdpbmcgcmVxdWlyZWQgdG8gZS5nLiBtYW5hZ2UgZmlsdGVycyBhbmQgcmVzb3Vy Y2UgYWxpYXNlcy4gVGhlIOKAnHNpZ25hbGluZw0KIHNlc3Npb27igJ0gaW4gdGhlIGFyY2hpdGVj dHVyZSBkb2N1bWVudCBpcyBhY3RpdmUgbWVzc2FnaW5nIGJldHdlZW4gRE9UUyBhZ2VudHMgb3Zl ciB0aGUgc2lnbmFsIGNoYW5uZWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TaG91bGQg4oCcRmlsdGVy 4oCdIGJlIGxpbWl0ZWQgdG8gdGhlIHR3byBhY3Rpb25zIG9mIHJhdGUtbGltaXRpbmcgb3IgZGlz Y2FyZGluZz8mbmJzcDsgSXMgZmlsdGVyIHJlYWxseSBpbnRlbmRlZCB0byBpbmNsdWRlIGFjdGlv biwgb3IganVzdCB0aGUgbWF0Y2ggY3JpdGVyaWE/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBzb3Vu ZHMgbGlrZSB5b3XigJlyZSByZWFsbHkgYXNraW5nIHdoZXRoZXIgd2Ugc2hvdWxkIGxlYXZlIHRo ZSBkZWZpbml0aW9uIG9mIOKAnGZpbHRlcmluZ+KAnSB1cCB0byB0aGUgRE9UUyBzZXJ2ZXIvbWl0 aWdhdG9yLiBJIHdvcnJ5IHRoYXQgbGVhdmluZyDigJxmaWx0ZXJpbmfigJ0gbG9vc2VseSBkZWZp bmVkIHdpbGwgbGVhZCB0byBjb25mdXNpb24gZnVydGhlciBkb3duIHRoZSBsaW5lLiBJIHRoaW5r IHdlIG5lZWQgZXhwbGljaXQNCiBhY3Rpb25zOiBkaXNjYXJkIGlzIHZlcnkgZGlmZmVyZW50IGZy b20gcmF0ZS1saW1pdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QXMgSSBzZWUgaXQsIGZpbHRlcmluZyBpcyBkaXN0aW5jdCBmcm9tIHZlbmRv ciBleHRlbnNpb25zIHdoaWNoIG1pZ2h0IGluY2x1ZGUgY291bnRlcm1lYXN1cmUgc3BlY2lmaWNz LiBJIGRvbuKAmXQgdGhpbmsgRE9UUyBpcyBhIGdlbmVyYWwgcHVycG9zZSBpbnRlcmZhY2UgZm9y IGNvdW50ZXJtZWFzdXJlIGNvbmZpZ3VyYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5TaW1pbGFybHkgZm9yIOKAnEJsYWNrbGlzdOKAnTogaXMgYmxvY2sgdGhlIG9ubHkgdmFsaWQg YWN0aW9uIGZvciBibGFjay1saXN0ZWQgYWRkcmVzc2VzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVz LCB0aGF04oCZcyB0aGUgZGlzdGluZ3Vpc2hpbmcgY2hhcmFjdGVyaXN0aWMgb2YgYSBibGFja2xp c3RlZCBzb3VyY2UuIEEgd2hpdGVsaXN0ZWQgc291cmNlIGlzIGFsd2F5cyBhbGxvd2VkIHRvIHBh c3MuIFRoZSBET1RTIGNsaWVudCBoYXMgZnVsbCBjb250cm9sIG92ZXIgdGhlIGJsYWNrLS93aGl0 ZS1saXN0cywgdGhvdWdoIHRoZSBzY29wZSBpcyByZXN0cmljdGVkIGJ5IHRoZSBET1RTIHNlcnZl ciB0byBwcmVmaXhlcy9yZXNvdXJjZXMNCiBiZWxvbmdpbmcgdG8gdGhlIERPVFMgY2xpZW50Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Mi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSBzZWNvbmQgcGFyYWdy YXBoIHNheXMg4oCcRE9UUyBpcyBhbiBhZHZpc29yeSBwcm90b2NvbC7igJ0gSSB0aG91Z2h0IHRo aXMgbWlnaHQgbWVhbiB0aGF0IChhKSBhIGNsaWVudOKAmXMgcmVxdWVzdCBmb3IgYWlkIG1heSBi ZSBpZ25vcmVkIGFuZCAoYikgbWl0aWdhdGlvbiBtYXkgYmUgZG9uZSBwcmlvcg0KIHRvIHJlcXVl c3Qgb3IgYWZ0ZXIgd2l0aGRyYXdhbC4gV291bGQgdGhhdCBpZGVhIGJlIGFjY3VyYXRlPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSB0aGluayAoYSkgaXMgY29ycmVjdCwgdGhvdWdoIGlnbm9yaW5nIGEg cmVxdWVzdCB3aXRob3V0IHByb3ZpZGluZyBhIHJlYXNvbiB3aGVuIGEgc2VydmljZSBhZ3JlZW1l bnQgaXMgaW4gcGxhY2Ugc2VlbXMgbGlrZSBhIHBvb3Igd2F5IHRvIG1hbmFnZSBhIHNlcnZpY2Uu IEluIGdlbmVyYWwgYSBET1RTIHJlcXVlc3QgZm9yIG1pdGlnYXRpb24gc2hvdWxkIHJlc3VsdCBp biBtaXRpZ2F0aW9uLCBhc3N1bWluZw0KIGJ1c2luZXNzIG9yIHNlcnZpY2UgYWdyZWVtZW50cyBh cmUgaW4gcGxhY2UsIGJ1dCBtaXRpZ2F0aW5nIHRoZSBhdHRhY2sgbWlnaHQgaW52b2x2ZSBtb3Jl IHRoYW4ganVzdCBhJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkluIGNhbGxpbmcgRE9UUyDigJxhZHZpc29yeeKAnSBJIHdhcyB0cnlp bmcgdG8gZW1waGFzaXplIHR3byBwb2ludHM6IHRoZSBkaWZmaWN1bHR5IG9mIG1haW50YWluaW5n IHJlbGlhYmxlIG1lc3NhZ2luZyB1bmRlciBhdHRhY2sgY29uZGl0aW9ucyAod2l0aCB0aGUgY29y b2xsYXJ5IHRoYXQgYSBET1RTIHNlcnZlciBtYXkgbm90IGJlIGFibGUgdG8gaGVscCBldmVuIGlm IGEgcmVxdWVzdCBnZXRzIHRocm91Z2gpOyBhbmQNCiB0aGUgZmFjdCB0aGF0IERPVFMgaXMgbm90 IGEgZ2VuZXJhbCBwdXJwb3NlIG1pdGlnYXRpb24gQVBJLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXliZSBJIHNob3VsZCBjbGFyaWZ5IHRo YXQgZnVydGhlci4gSSBiZWxpZXZlIHRoZSBET1RTICpzaWduYWwgY2hhbm5lbCogaXMgbm90IGEg Z2VuZXJhbCBwdXJwb3NlIG1pdGlnYXRpb24gQVBJLiBUaGUgRE9UUyBkYXRhIGNoYW5uZWwgY291 bGQgZXZvbHZlIGludG8gdGhhdCBhcyBhIHNvcnQgb2YgRE9UUyBjb250cm9sIHByb3RvY29sLCBp biB3aGljaCB0aGUgaW1wYWN0IG9mIGFuIGF0dGFjayBvbiB0aGUgY29tbXVuaWNhdGlvbg0KIGxh eWVyIGJldHdlZW4gY2xpZW50IGFuZCBzZXJ2ZXIgaXMgbm90IGEgY29uY2Vybi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+KE15IHRoaW5raW5nIGlzIHRoYXQgYSBET1RTIHNlcnZlciBtYXkga25v dyBiZXR0ZXIgdGhhbiB0aGUgY2xpZW50IGJhc2VkIG9uIGEgd2lkZXIgc291cmNlIG9mIHRlbGVt ZXRyeS4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFncmVlZC4gT25jZSBhIG1pdGlnYXRvciBiZWdpbnMgZmlsdGVy aW5nIHRyYWZmaWMgYm91bmQgZm9yIHRoZSBkb21haW4gb2YgdGhlIERPVFMgY2xpZW50LCB0aGUg RE9UUyBjbGllbnTigJlzIHZpZXcgaW50byB0aGUgYXR0YWNrIGlzIHNrZXdlZC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+LSBpbiBHRU4tMDA0LCBjb25zaWRlciBwaWNraW5nIGEgc3Bl Y2lmaWMgTVRVIHNpemUsIGxpa2UgNTAwIGJ5dGVzLCBiZWNhdXNlIG90aGVyd2lzZSB0aGVyZSBp cyBubyB3YXkgdG8ganVkZ2UgaWYgdGhlIHByb3RvY29sIG1lZXRzIHJlcXVpcmVtZW50cy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoaXMgaGFzIGJlY29tZSBtb3JlIGltcG9ydGFudCBzaW5jZSB5b3Ug c3VnZ2VzdGVkIGl0LCBpbiBsaWdodCBvZiB0aGUgcmVjZW50IHRocmVhZCBvbiB0ZWxlbWV0cnku IGRyYWZ0LXJlZGR5LWRvdHMtc2lnbmFsLWNoYW5uZWwgaXMgc3VnZ2VzdGluZyA1MDAgYnl0ZXMg aW4gdGhlIGV2ZW50IHRoZSBjbGllbnQgY2Fu4oCZdCBkaXNjZXJuIHBhdGggTVRVLiBJ4oCZbSBj b21mb3J0YWJsZSB3aXRoIHRleHQgdG8gdGhlDQogZWZmZWN0IHRoYXQgY2xpZW50cyBTSE9VTEQg dHJ5IHRvIGRldGVybWluZSBwYXRoIE1UVSwgYW5kIGZhbGwgYmFjayB0byA1MDAgYnl0ZXMgaWYg aXQgY2Fu4oCZdCBiZSBkaXNjb3ZlcmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5J biAyLjIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igKYgc25pcCAuLi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T1AtMDA0OiBUaGlzIHJl cXVpcmVtZW50IGhhcyBzZXZlcmFsIGlkZWFzIGluIGl0LCB3aGljaCBJIHRoaW5rIHNob3VsZCBi ZSBicm9rZW4gaW50byBtdWx0aXBsZSByZXF1aXJlbWVudHM6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+KGEpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUNCiBpZGVhIHRoYXQgbWVzc2Fn ZXMgYmUgYWNrbm93bGVkZ2VkIHdpdGggYSBzdGF0dXMgY29kZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi43NWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+QnV0DQogaXQgaXMgdW5jbGVhciB3aGV0aGVyIHRoZSBzdGF0dXMgbXVz dCBiZSBkZWxpdmVyZWQgaW1tZWRpYXRlbHksIG9yIHJlcG9ydGVkIGxhdGVyLiBJIGV4cGVjdCB0 aGVyZSBjb3VsZCBiZSBhbiBpbW1lZGlhdGUg4oCcSSBoZWFyIHlvdXIgcmVxdWVzdOKAnSwgd2hp Y2ggZG9lc27igJl0IG5lY2Vzc2FyaWx5IG1lYW4gYW55dGhpbmcgY2FuIGJlIGRvbmUuIFRoZXJl IHNob3VsZCBiZSBhIHdheSBmb3IgdGhlIGNsaWVudCB0byBsYXRlciBhc2ssIOKAnGhvdyBhcmUN CiB5b3UgZG9pbmcgd2l0aCB0aGF0IHJlcXVlc3Q/4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG1l YW50IHRoaXMgdG8gYmUgbGVzcyByZXN0cmljdGl2ZSB0aGFuIHdoYXQgeW914oCZdmUgZGVzY3Jp YmVkLiBUaGVyZSBzaG91bGQgYmUgc29tZSB3YXkgZm9yIHRoZSBET1RTIGNsaWVudCB0byBkZXRl Y3QgdGhhdCBpdHMgbWVzc2FnZXMgYXJlIGJlaW5nIHJlY2VpdmVkL3Byb2Nlc3NlZCBvciBsb3N0 LCBhbmQgdGhlIHNhbWUgaXMgdHJ1ZSBmb3IgdGhlIERPVFMgc2VydmVyLiBUaGF0IGRvZXNu4oCZ dCBoYXZlIHRvDQogbWVhbiBhbiBIVFRQLWxpa2UgbW9kZWwuIEZvciBleGFtcGxlLCBpbiB0aGUg cHJvdG9jb2wgZHJhZnQgTmlrIFRlYWd1ZSBhbmQgSSBoYXZlIHB1dCB0b2dldGhlciwgdGhlIHNp Z25hbCBjaGFubmVsIGlzIG9uZ29pbmcsIHBlcmlvZGljIGNvbW11bmljYXRpb24gYmV0d2VlbiBj bGllbnQgYW5kIHNlcnZlci4gVGhlIGNsaWVudCBkb2VzIG5vdCBuZWVkIHRvIHNlbmQgYSBzZXBh cmF0ZSBtZXNzYWdlIHRvIGFzayBhYm91dCByZXF1ZXN0IHN0YXR1cywNCiBzaW5jZSB0aGUgRE9U UyBzZXJ2ZXIgd2lsbCBzZW5kIGl0IGluIGEgZmV3IHNlY29uZHMgYW55d2F5LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4oYik8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldoZXRoZXINCiB0aGUgc2VydmVyIE1VU1QgZG8gYXMg aXQgaXMgdG9sZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi43NWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVu dDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T24NCiB0aGlzIHBv aW50LCBJIHRoaW5rIHRoZSDigJxNVVNUIGNlYXNlIG1pdGlnYXRpb24gYWN0aXZpdHnigJ0gaXMg d3JvbmcsIHNpbmNlIHRoZSBzZXJ2ZXIgbWF5IGhhdmUgb3RoZXIgZXZpZGVuY2Ugb3Igb3RoZXIg Y2xpZW50cyByZXF1ZXN0aW5nIHRoZSBtaXRpZ2F0aW9uLiBUaGlzIGlzIGFja25vd2xlZGdlZCBi eSB0aGUg4oCcbWF5IGNvbnRpbnVlIG1pdGlnYXRpbmfigJ0gbGF0ZXIgaW4gdGhlIHBhcmFncmFw aC4gU28gYXQgbWluaW11bSB0aGUgTVVTVCBpcw0KIHRvbyBzdHJvbmcuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZnVsbCBw aHJhc2UgaXMg4oCcTVVTVCBjZWFzZSBtaXRpZ2F0aW9uIGFzIHF1aWNrbHkgYXMgcG9zc2libGXi gJ0sIGJ5IHdoaWNoIEkgbWVhbnQgdG8gZXhwcmVzcyB0aGUgaW1wb3J0YW5jZSBvZiBhbGxvd2lu ZyB0aGUgc2VydmVyIHRvIG1haW50YWluIHRoZSBtaXRpZ2F0aW9uIGZvciBhIHNob3J0IHBlcmlv ZCB0byByZWR1Y2UgdGhlIGltcGFjdCBvZiBhIERPVFMgY2xpZW50IHJhcGlkbHkgdG9nZ2xpbmcg bWl0aWdhdGlvbi4NCiBJdCBzb3VuZHMgbGlrZSB0aGUgZHVyYXRpb24gb2YgdGhhdCBzaG9ydCBw ZXJpb2QgbmVlZHMgdG8gYmUgZGVmaW5lZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0d28gdGhpbmdzIHNob3VsZCBiZSBjbGVh ciBpbiB0aGUgZmluYWwgdGV4dDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+MSkgVGhlIERPVFMgY2xpZW50IGNhbiBjZWFzZSB0byBiZSB0aGUg Y2F1c2UgZm9yIGEgbWl0aWdhdGlvbiBhdCBhbnkgdGltZSBieSBzZW5kaW5nIGEgbWl0aWdhdGlv biB0ZXJtaW5hdGlvbiByZXF1ZXN0LCBidXQgY2Fubm90IGNvbnNpZGVyIGEgbWl0aWdhdGlvbiB0 ZXJtaW5hdGVkIHVudGlsIGNvbmZpcm1hdGlvbiBmcm9tIHRoZSBzZXJ2ZXIuIChNaXRpZ2F0aW9u IGxpZmV0aW1lIGlzIHRoZXJlIHRvIGhhbmRsZQ0KIHRoZSBjYXNlcyB3aGVyZSB0aGUgc2VydmVy 4oCZcyBjb25maXJtYXRpb24gaXMgbm90IGRlbGl2ZXJlZC4pPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIpJm5ic3A7T25jZSBhIERPVFMgY2xp ZW50IHRlbGxzIGEgRE9UUyBzZXJ2ZXIgdG8gc3RvcCBtaXRpZ2F0aW5nLCB0aGUgRE9UUyBjbGll bnQgaXMgbm8gbG9uZ2VyIHJlc3BvbnNpYmxlIGZvciB0aGUgbWl0aWdhdGlvbi4gVGhlIERPVFMg c2VydmVyL21pdGlnYXRvciBjYW4gY29udGludWUgbWl0aWdhdGluZyBhcmJpdHJhcmlseSwgYnV0 IGFmdGVyIHRoZSBtaXRpZ2F0aW9uIHRlcm1pbmF0aW9uIGdyYWNlIHBlcmlvZA0KIGVsYXBzZXMg YW5kIHRoZSBjbGllbnQgaGFzbuKAmXQgcmVuZXdlZCBhIHJlcXVlc3QgZm9yIG1pdGlnYXRpb24s IGFsbCByZXNwb25zaWJpbGl0eSBmb3IgdGhlIG1pdGlnYXRpb24gaXMgYm9ybmUgYnkgdGhlIERP VFMgc2VydmVyIGRvbWFpbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PUC0wMDYuIEkgd291bGQgbGlrZSB0 byBzZWUgYWxsIG9mIHNwZWNpZmljIHNjb3BlcyBwcmVjaXNlbHkgZGVmaW5lZCBhcyByZXF1aXJl ZCBvciBvcHRpb25hbCwgYnV0IG5vdCBhcyBleGFtcGxlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgdGhpcyBpcyBhIGdv b2Qgc3VnZ2VzdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BbHNvLCBJ4oCZbSBub3QgY2xlYXIgb24g d2hhdCBETlMgbmFtZSBmaWx0ZXJpbmcgbWVhbnM6IGlzIHRoaXMgZm9yIGZpbHRlcmluZyBETlMg cGFja2V0cywgb3IgZm9yIGxvb2tpbmcgdXAgdGhlIG5hbWUgYW5kIGZpbHRlcmluZyB0aGUgY29y cmVzcG9uZGluZyBhZGRyZXNzZXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdOKAmXMgbm90IEROUyBuYW1lIGZpbHRlcmluZywg YnV0IGluZGljYXRpbmcgd2hpY2ggRlFETnMgbmVlZCBtaXRpZ2F0aW9uLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T1AtMDA4LiBJIGhvcGUg dGhlcmUgaXNu4oCZdCBnb2luZyB0byBiZSBhbiBhcmd1bWVudCBhYm91dCB0aGlzLCBidXTigKYg SSBiZWxpZXZlIGl0IGlzIG5vdCBhIGNsaWVudCBlcnJvciB0byBhc2sgZm9yIGEgbWl0aWdhdGlv biB0aGF0IGNvbmZsaWN0cyB3aXRoIGFub3RoZXIgY2xpZW50IChob3cgY291bGQNCiBpdCBldmVu IGtub3c/KS4mbmJzcDtSYXRoZXIsIGl0IGlzIHVwIHRvIHRoZSBzZXJ2ZXIgdG8gd2VpZ2ggdGhl IHZhcmlvdXMgcmVxdWVzdHMgYW5kIGFjdCBmb3IgdGhlIG92ZXJhbGwgZ29vZC4gQXMgcGFyYWdy YXBoIDIgb2Ygc2VjdGlvbiAyIHNheXMsIOKAnERPVFMgaXMgYW4gYWR2aXNvcnkgcHJvdG9jb2zi gJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgZG9u4oCZdCBldmVuIHRoaW5r IGFuIG92ZXJsYXBwaW5nIHByZWZpeCByYW5nZSBpcyBhbiBlcnJvcjsgcmF0aGVyIGJvdGggY2xp ZW50cyBoYXZlIGlkZW50aWZpZWQgdGhlIHNhbWUgYXR0YWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhpcyBpcyBhIGZhaXIgY291bnRlcnBvaW50LiDigJxBY3QgZm9yIHRoZSBvdmVyYWxsIGdvb2Ti gJ0gaXMgdW5mb3J0dW5hdGVseSBub3QgY29uY3JldGUgZW5vdWdoIGZvciBhIHJlcXVpcmVtZW50 LiBDYXNlcyBsaWtlIHR3byBET1RTIGNsaWVudHMgcmVxdWVzdGluZyBtaXRpZ2F0aW9uIGZvciB0 aGUgc2FtZSByZXNvdXJjZXMgYXJlIGVhc3kgdG8gaGFuZGxl4oCUdGhlIHNlcnZlciBqdXN0IGxl dHMgdGhlIGxvc2luZw0KIGNsaWVudCBrbm93IG1pdGlnYXRpb24gaXMgYWxyZWFkeSBpbiBwcm9n cmVzc+KAlGJ1dCBwYXJ0aWFsbHkgb3ZlcmxhcHBpbmcgbWl0aWdhdGlvbiByZXF1ZXN0cyBhcmUg aGFyZGVyIHRvIGhhbmRsZS4gRG9lcyB0aGUgc2VydmVyIG5vdGlmeSBlYWNoIGNsaWVudCB0aGF0 IHRoZSBhY3R1YWwgbWl0aWdhdGlvbiBzY29wZSBpcyBsYXJnZXIgdGhhbiBvcmlnaW5hbGx5IHJl cXVlc3RlZD8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Mi41PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7IC0gRGF0YSBtb2RlbCByZXF1aXJlbWVu dHM8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5J4oCZbSBub3Qgc3VyZSB3 aGF0IHRvIG1ha2Ugb2YgdGhpcyBzZWN0aW9uLiBJIHRoaW5rIEkganVzdCB3YW50IHRvIHJldmll dyB0aGUgZGF0YSBtb2RlbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIGNvbWZvcnRhYmxlIGp1 c3QgcmVtb3ZpbmcgdGhpcyBzZWN0aW9uLiBXaXRoIEZsZW1taW5nJ3MgZHJhZnQgYXBwYXJlbnRs eSBldm9sdmluZyBtb3JlIHRvd2FyZCBpbmZvcm1hdGlvbiBtb2RlbCwgZG8gd2UgbmVlZCB0byBk aXNjdXNzIGRhdGEgbW9kZWwgYXQgYWxsIG91dHNpZGUgb2YgdGhlIHNvbHV0aW9ucyBkcmFmdHM/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFu ZHJldzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E8355113905631478EFF04F5AA706E987051D4D8wtlexchp1sandvi_-- From nobody Tue Feb 21 14:04:51 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D52129D1F for ; Tue, 21 Feb 2017 14:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 AJLLeyOxxo2z for ; Tue, 21 Feb 2017 14:04:49 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03EFE1294AE for ; Tue, 21 Feb 2017 14:04:49 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Tue, 21 Feb 2017 17:04:47 -0500 From: Dave Dolson To: "Tirumaleswar Reddy (tireddy)" , "dots@ietf.org" Thread-Topic: New Version Notification for draft-reddy-dots-signal-channel-08.txt Thread-Index: AQHSjCCkIbjO+MzHWE6MQfNQQhzR96FzMYZQgADQiUA= Date: Tue, 21 Feb 2017 22:04:47 +0000 Message-ID: References: <148766749366.32553.4722816219476780947.idtracker@ietfa.amsl.com> <68781b8926724ea9ad41230aeb94b1a0@XCH-ALN-017.cisco.com> In-Reply-To: <68781b8926724ea9ad41230aeb94b1a0@XCH-ALN-017.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] New Version Notification for draft-reddy-dots-signal-channel-08.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 21 Feb 2017 22:04:50 -0000 On the topic of "Happy Eyeballs" (although I think this is a misnomer), I believe the intent would be to use the same policy-id in each of the tran= sports, to detect duplicates at the server, correct? The document should say so. (Or if not, explain how duplicates are to be de= tected.) Also, has thought been given to preventing replay attacks? E.g., malicious= ly asking for mitigation by replaying a captured mitigation request? -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (= tireddy) Sent: Tuesday, February 21, 2017 4:31 AM To: dots@ietf.org Subject: Re: [Dots] New Version Notification for draft-reddy-dots-signal-ch= annel-08.txt This revision https://tools.ietf.org/html/draft-reddy-dots-signal-channel-0= 8 addresses comments from Ehud and Kaname.=20 Major changes are: 1)DOTS mitigation request/response are marked as non-confirmable messages. = Requests marked by the DOTS client as Non-confirmable messages are sent at= regular intervals until a response is received from the DOTS server (See S= ection 5.3 for more details).=20 (Thanks to the feedback from Flemming, Andrew and Ehud). 2)Added support for vendor specific parameters. 3)Added new Mitigation status parameters: bytes_dropped, bps_dropped, pkts_= dropped and pps_dropped. Comments and suggestions are welcome. -Tiru > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, February 21, 2017 2:28 PM > To: Prashanth Patil (praspati) ; Mohamed Boucadair > ; Tirumaleswar Reddy (tireddy) > > Subject: New Version Notification for draft-reddy-dots-signal-channel-08.= txt >=20 >=20 > A new version of I-D, draft-reddy-dots-signal-channel-08.txt > has been successfully submitted by Tirumaleswar Reddy and posted to the > IETF repository. >=20 > Name: draft-reddy-dots-signal-channel > Revision: 08 > Title: Distributed Denial-of-Service Open Threat Signaling (DOTS) > Signal Channel > Document date: 2017-02-21 > Group: Individual Submission > Pages: 46 > URL: https://www.ietf.org/internet-drafts/draft-reddy-dots-sig= nal- > channel-08.txt > Status: https://datatracker.ietf.org/doc/draft-reddy-dots-signal-= channel/ > Htmlized: https://tools.ietf.org/html/draft-reddy-dots-signal-chann= el-08 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-dots-sign= al-channel- > 08 >=20 > Abstract: > This document specifies a mechanism that a DOTS client can use to > signal that a network is under a Distributed Denial-of-Service (DDoS) > attack to an upstream DOTS server so that appropriate mitigation > actions are undertaken (including, blackhole, drop, rate-limit, or > add to watch list) on the suspect traffic. The document specifies > the DOTS signal channel including Happy Eyeballs considerations. The > specification of the DOTS data channel is elaborated in a companion > document. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Feb 21 19:38:55 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651B9129573 for ; Tue, 21 Feb 2017 19:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 ulIwJl5cbqUF for ; Tue, 21 Feb 2017 19:38:49 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 613E9129560 for ; Tue, 21 Feb 2017 19:38:48 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id C43C725F6B7; Wed, 22 Feb 2017 12:38:46 +0900 (JST) Received: from SR2-nishizuka.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 03A4C759011; Wed, 22 Feb 2017 12:38:46 +0900 (JST) To: "Tirumaleswar Reddy (tireddy)" , Ehud Doron , 'dots' References: <73716c67d08b4de5b8e6df1394da199f@XCH-RCD-017.cisco.com> <0dd8cd77a95f45aabcc64e30ef0bcd06@XCH-RCD-017.cisco.com> <2c809b8c-d7f7-ea38-d0eb-02a78fca4a15@nttv6.jp> <675dbf9cd1134c47847cdb22602c8904@XCH-ALN-017.cisco.com> From: kaname nishizuka Message-ID: Date: Wed, 22 Feb 2017 12:38:45 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <675dbf9cd1134c47847cdb22602c8904@XCH-ALN-017.cisco.com> Content-Type: multipart/alternative; boundary="------------D37DF423C244820247652536" Archived-At: Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 03:38:53 -0000 This is a multi-part message in MIME format. --------------D37DF423C244820247652536 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Tiru, On 2017/02/21 15:59, Tirumaleswar Reddy (tireddy) wrote: > > Please see inline [TR3] > > *From:*kaname nishizuka [mailto:kaname@nttv6.jp] > *Sent:* Friday, February 17, 2017 10:07 AM > *To:* Tirumaleswar Reddy (tireddy) ; Ehud Doron ; 'dots' > *Cc:* David Aviv > *Subject:* Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Hi Tiru, > > Thanks for your response and clarifications. > Please see my response inline[kaname2] > > On 2017/02/16 21:09, Tirumaleswar Reddy (tireddy) wrote: > > Hi Kaname, > > Please see inline [TR2] > > *From:*kaname nishizuka [mailto:kaname@nttv6.jp] > *Sent:* Thursday, February 16, 2017 1:22 PM > *To:* Tirumaleswar Reddy (tireddy) ; Ehud Doron ; 'dots' > *Cc:* David Aviv > *Subject:* Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Hi Tiru, > > please see inline. > > On 2017/02/16 13:18, Tirumaleswar Reddy (tireddy) wrote: > > Hi Kaname, > > Please see inline [TR] for responses > > *From:*kaname nishizuka [mailto:kaname@nttv6.jp] > *Sent:* Wednesday, February 15, 2017 11:27 AM > *To:* Tirumaleswar Reddy (tireddy) ; Ehud Doron ; 'dots' > *Cc:* David Aviv > *Subject:* Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Hi Tiru, > > I really appreciate your time and effort. > Please see my comments on the drafts. > > # draft-reddy-dots-signal-channel-07 > > 1. [General] I believe that DOTS request should not be another tool of blocking other one's traffic. Is there any validation mechanism of requested target-ips, target-ports and target-protocols? Even If it is out side of the DOTS specification, how about returning 4.xx codes when the requested target-* is not a property of the organization. > > [TR] The validation scope is outside the scope of this draft, 4.xx error code is already used in the draft to identity invalid requests. > > [kaname]OK, understood. > > > > 2. [page14] Does one DOTS client and DOTS server peer have only one signal channel and one data channel? (I'm thinking about a namespace of the "alias-name") > > [TR] No, DOTS peers can have more than one signal and data channel but the recommendation is to use only signal and data channel to reduce connection setup delay. > > [kaname] If there are more than one signal and data channel, how can they coupled? > > [TR2] DOTS client authenticate to the DOTS server (see https://tools.ietf.org/html/draft-reddy-dots-signal-channel-07#page-35), the DOTS server knows the DOTS client identity to couple the signal and data channel sessions. > > [kaname2] I see. Could I confirm that my understanding is right. > The signal and data channel sessions are coupled based on the client certification. So, the same client certification should be used among (D)TLS in signal channel session and TLS in data channel session. > > [TR3] Yes. > > > If so, how about writing it explicitly in the main part of [draft-reddy-dots-data-channel-04]? Now, mutual authentication is described only in 6. Security Considerations. > > [TR3] Good point, will update signal channel draft how signal and data channel sessions are coupled using DOTS client identity. > > NEW: > > In both DOTS signal and data channel sessions, the DOTS client MUST > > authenticate itself to the DOTS server (Section 9). The DOTS server > > couples the DOTS signal and data channel sessions using the DOTS > > client identity, so the DOTS server can validate whether the aliases > > conveyed in the mitigation request were indeed created by the same > > DOTS client using the DOTS data channel session. If the aliases were > > not created by the DOTS client then the DOTS server returns 4.00 (Bad > > Request) in the response. > [kaname3] I'm OK with the new text. It's clear to me now. thank you, Kaname > One DOTS server will accommodate more than one DOTS client, so is there any way to know which data channel is belong to which signal channel? Source IP? > I recommend to use only one signal and data channel per one DOTS peer, too. > > If their are multiple data channels, "DOTS signal" in Fig.5 should specify according data channel when it refers to "alias-names" of the identifiers. > > [TR] I did not get the comment. > > [kaname] Different DOTS clients will be belonging to different customers(organizations). > So I think there is a chance of requesting the same "alias-names" from different customers. > Then, will the DOTS server reject conflicted "alias-names" between different customers? > > [TR] No. > > or keep them with prefixes like customerA: and customerB: internally? Also, customerA should not use an alias-name of customerB. How can the DOTS server check that. > > [TR2] Same response as above. Aliases do not have global scope, they are specific to a DOTS client (DOTS server knows the DOTS client identity). > > [kaname2]OK, I understood. > > > > 3. [Page21] How about adding status of "mitigation delete is in progress" like status:1. > Here is a life cycle of a mitigation in our environment. Activating and deleting of mitigation could take several seconds (or minutes). > POST. > - activating(status=1) > STATUS AFTER ACTIVATED > - attack mitigated (status=2) > - attack stopped (status=3) > - attack exceeded capability(status=4) > DELETE > - deleting(status=5?) > - deleted(RETURN 4.04) > > > > [TR] Delete is a confirmable message, DOTS server will send an ACK to acknowledge the receipt of the message to avoid retransmissions from the DOTS client. After the mitigation request is successfully deleted, DOTS server returns 2.02 (Deleted) response code, thus conveying the transient status in this case is not necessary. > > [kaname] As I noted, deleting of mitigation could take several seconds (or minutes) in real-life. > > [TR2] Yes, but the DOTS server immediately sends a ACK (acknowledging the receipt of the DELETE message), thus the DOTS client knows the server has received the Delete request and is processing the request. After deleting the mitigation (may take several seconds), server sends 2.02 (Delete) response code. I don’t see a problem. > > -Tiru > > [kaname2] The same story could be applied to the status:1 (Attack mitigation is in progress) > > [TR3] No, the DOTS client needs to know the mitigation status and DDOS attack status so that it can withdraw the mitigation request when the DDOS attack stops (see Section 5.3.3.1) and to know whether the DOTS mitigation provider is able to successfully mitigate the attack or is re-directing the client to an alternate DOTS server. > > These unsolicited notifications are not required for withdraw because after validating the DELETE request DOTS server immediately send an ACK or returns an error that the DELETE request was invalid and it is DOTS server responsibility to withdraw the mitigation request from the DDOS mitigator(s) (which may take several seconds). > > -Tiru > > thank you, > Kaname > > If the DOTS client retrieve the status while that time, getting "deleting status", not "2.02 status", will help operators. > > > 4. [Page25] 5.4 b) I couldn't find "retransmission timeout value" attribute in the later figures. Is that equivalent to "ack-timeout"? > > [TR] The initial retransmission timeout value is based on the ack-timeout (see https://tools.ietf.org/html/rfc7252#section-4.2). > > [kaname] Thank you, I found the reference. > > > 5. [Page27] "policy-id" in "signal-config" is different from "policy-id" in "mitigation-scole". How about using "session-id" in this case? > > [TR] Policy-id is a unique identifier identifying the signal channel session configuration request. > > [kaname] "policy-id" in Fig.9 and Fig.15 are totally different. I've got confused when reading the draft because they have the same name. > > > # draft-reddy-dots-data-channel-03 > > 1. [General] Data channel doesn't have heartbeat mechanism. I guess the reason is that there is heartbeat mechanism in the signal channel so it is enough, is that right? > > [TR] No, the heartbeat mechanism in signal channel cannot be used for data channel. DOTS signal channel is using the “CoAP ping mechanism”. For data channel, TLS heartbeat can be used. I have updated draft. > > [kaname] OK. I'll see updated draft. > > > > 2. [related to Ehud's question 8] I-D.ietf-netmod-acl-model says "ACL is an ordered list of Access List Entries (ACE)" but I couldn't find a text about how they are ordered. Should we have a operation of changing the order of ACEs installed in a DOTS server? > > [TR] PUT can be used by the DOTS client to re-order/update/modify the list of ACE conveyed to the DOTS server. Updated draft to discuss about PUT. > > [kaname] OK. I'll see updated draft. > > > thank you, > kaname > > > -Tiru > > > thank you, > Kaname > > On 2017/02/14 23:58, Tirumaleswar Reddy (tireddy) wrote: > > Hi Ehud, > > Please see inline for responses to comments on draft-reddy-dots-data-channel-03 > > *From:* Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Ehud Doron > *Sent:* Wednesday, February 8, 2017 7:21 PM > *To:* 'dots' > *Cc:* David Aviv > *Subject:* [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Tiru and authors Hi > > Attached please find my comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > *_Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel draft-reddy-dots-signal-channel-07_* > > 1.General comment: For all signals in the draft, need to add means to allow vendor specific attributes as part of all signals transactions > > 2.General comment: Just for clarity, need to explicitly mention on each figure when it is an example or the actual API > > 3.Page 3 second paragraph : DOTS should not be limited to “enterprise network” only > > . > > 4.Page 4 chapter 4: The overall context of the “happy eyeballs” and its relations (or coexistence) to CoAP is not clear. > > 5.Page 7 chapter 5.2.1: The need for YANG model cannot be understood from text. What are the needs for YANG models? What is the relation to the JSONs in the other chapters in the draft > > 6.Page 14 figure 5: The mitigation request attributes are right but not enough. Need to add more telemetry info about the actual attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. > > 7.Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested > > 8.Page 15 last paragraph: Not sure that target port or target protocol can define a protected entity. IP, FQDN, URI are the only “stand alone” attributes , port and protocol are companion attributes. See also figure 9 . > > 9.Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is related ? “policy ID” ? I think the best is have another attribute to define the priority of mitigation requests > > 10.Page 21 table: The return status are right but not enough. Need to add more telemetry info about the actual mitigation going on (how much traffic was mitigated) and the attack that are mitigated, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. > > 11.Page 15 : Need to find the way to bind the target-ip*s* with target-port-range*s* and target-protocol*s*, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth. > > 12.Page 21 last paragraph: This is very strong point. > > 13.Page 25 : Regarding attack status, same point about telemetry. > > 14.Page 25 chapter 5.4: I believe it can valuable to add a short high level description about the proposed API flow, same as you did for 5.3 . > > 15.Page 27: The necessity of policy_id here is not clear enough, are the “Signal Channel Session Configuration” define only “single” DOTS session or the entire communication between Client and Server for several DOTS request for mitigation? > > 16.Page 27: Not sure about the reason for “at least one of the attributes heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor MUST be present.” Also consider to change to “presented”. > > 17.Page 30 chapter 5.5: Need to specify the overall scenario, in reaction to which signal (or API transaction POST of Mitigation Request , unidirectional notification from Server as describes in page 23 in page 21 ?) the redirection occurred ? > > *_Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel draft-reddy-dots-data-channel-03_* > > 1.General comment: For all signal in the draft, need to add means to allow vendor specific attributes as part of all signals transactions > > [TR] Agreed, updated draft. > > 2.Page 5 second paragraph: Why it is required to configure the DOTS signal channel session ? > > [TR] No need to configure DOTS signal channel session, fixed second paragraph. > > 3.Page 8 chapter 3.2.1 : Any reason for not including these identifiers in the DOTS signal channel draft ? > > [TR] Identifiers created for resources in DOTS data channel are used in DOTS signal channel to request DDOS mitigation. It’s the responsibility of DOTS data channel to create aliases for resources (see https://tools.ietf.org/html/draft-ietf-dots-requirements-03#section-2.3). The main reason for DOTS signal channel not creating identifiers is the message size may exceed Path MTU. > > 4.Page 9 figure 3 : Need to find the way to bind the target-ip*s* with target-port-range*s* and target-protocol*s*, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth. > > [TR] Yes, it is possible; create different aliases for IP1 TCP port 80 and IP2 UDP port 53. > > 5.Page 13 chapter 3.3 : Need to emphasize that filtering rules are relevant for both client server direct communication and through a DOTS gateway. The chapter is a bit confusing. > > [TR] Thanks, fixed chapter 3.3. > > 6.Page 14 chapter 3.3 : I am missing the white-list installation, is it by using the permit action ? > > [TR] Yes, “permit” action is used for white-list installation; it’s defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 > > 7.Page 15 figure 8: For DDoS it is highly valuable to have rate limit as an action. Consider adding such action (if already defined need to explain where and how). > > [TR] Done, updated draft. > > 8.Page 15 figure 8: Need to consider adding priority to an ACL to support cases when several filtering rules are conflicting. > > [TR] We are not doing anything new to ACL, ACL an ordered list of Access List Entries (ACE) based on priority. > > 9.Page 15 : The action field cannot be optional attribute. > > [TR] As per https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09if the action field not specified then “deny” is the default action. > > 10.Page 16 chapter 3.3.3: Need to add more telemetry info about the actual traffic that was blocked (bps, pps and so on), but as I believe this might be another issue… > > [TR] Chapter 3.3.3 only discusses telemetry details of number of matches for the installed filtering rules. > > -Tiru > > Thanks, > > ** > > *Ehud Doron *| Senior Architect, *Radware* CTO office | *M:*+972-54-7575503 | *T:* +972-72-3917120 > > > > > > > _______________________________________________ > > 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 > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------D37DF423C244820247652536 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Tiru,


On 2017/02/21 15:59, Tirumaleswar Reddy (tireddy) wrote:

Please see inline [TR3]

 

From: kaname nishizuka [mailto:kaname@nttv6.jp]
Sent: Friday, February 17, 2017 10:07 AM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; Ehud Doron <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru,

Thanks for your response and clarifications.
Please see my response inline[kaname2]

On 2017/02/16 21:09, Tirumaleswar Reddy (tireddy) wrote:

Hi Kaname,

 

Please see inline [TR2]

 

From: kaname nishizuka [mailto:kaname@nttv6.jp]
Sent: Thursday, February 16, 2017 1:22 PM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; Ehud Doron <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru,

please see inline.

On 2017/02/16 13:18, Tirumaleswar Reddy (tireddy) wrote:

Hi Kaname,

 

Please see inline [TR] for responses

 

From: kaname nishizuka [mailto:kaname@nttv6.jp]
Sent: Wednesday, February 15, 2017 11:27 AM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; Ehud Doron <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru,

I really appreciate your time and effort.
Please see my comments on the drafts.

# draft-reddy-dots-signal-channel-07

1. [General] I believe that DOTS request should not be another tool of blocking other one's traffic. Is there any validation mechanism of requested target-ips, target-ports and target-protocols? Even If it is out side of the DOTS specification, how about returning 4.xx codes when the requested target-* is not a property of the organization.

[TR] The validation scope is outside the scope of this draft, 4.xx error code is already used in the draft to identity invalid requests.

[kaname]OK, understood.



2. [page14] Does one DOTS client and DOTS server peer have only one signal channel and one data channel? (I'm thinking about a namespace of the "alias-name")

[TR] No, DOTS peers can have more than one signal and data channel but the recommendation is to use only signal and data channel to reduce connection setup delay.

[kaname] If there are more than one signal and data channel, how can they coupled?

 

[TR2] DOTS client authenticate to the DOTS server (see https://tools.ietf.org/html/draft-reddy-dots-signal-channel-07#page-35), the DOTS server knows the DOTS client identity to couple the signal and data channel sessions.

 

[kaname2] I see. Could I confirm that my understanding is right.
The signal and data channel sessions are coupled based on the client certification. So, the same client certification should be used among (D)TLS in signal channel session and TLS in data channel session.

 

[TR3] Yes.


If so, how about writing it explicitly in the main part of [draft-reddy-dots-data-channel-04]? Now, mutual authentication is described only in 6. Security Considerations.

[TR3] Good point, will update signal channel draft how signal and data channel sessions are coupled using DOTS client identity.

NEW:

 

   In both DOTS signal and data channel sessions, the DOTS client MUST

   authenticate itself to the DOTS server (Section 9).  The DOTS server

   couples the DOTS signal and data channel sessions using the DOTS

   client identity, so the DOTS server can validate whether the aliases

   conveyed in the mitigation request were indeed created by the same

   DOTS client using the DOTS data channel session.  If the aliases were

   not created by the DOTS client then the DOTS server returns 4.00 (Bad

   Request) in the response.

 

 

[kaname3] I'm OK with the new text. It's clear to me now.

thank you,
Kaname

One DOTS server will accommodate more than one DOTS client, so is there any way to know which data channel is belong to which signal channel? Source IP?
I recommend to use only one signal and data channel per one DOTS peer, too.

 

 

If their are multiple data channels, "DOTS signal" in Fig.5 should specify according data channel when it refers to "alias-names" of the identifiers.

[TR] I did not get the comment.

[kaname] Different DOTS clients will be belonging to different customers(organizations).
So I think there is a chance of requesting the same "alias-names" from different customers.
Then, will the DOTS server reject conflicted "alias-names" between different customers?

 

[TR] No.

 

or keep them with prefixes like customerA:<same-alias-name> and customerB:<same-alias-name> internally? Also, customerA should not use an alias-name of customerB. How can the DOTS server check that.

 

[TR2] Same response as above. Aliases do not have global scope, they are specific to a DOTS client (DOTS server knows the DOTS client identity).

[kaname2]OK, I understood.



3. [Page21] How about adding status of "mitigation delete is in progress" like status:1.
    Here is a life cycle of a mitigation in our environment. Activating and deleting of mitigation could take several seconds (or minutes).
    POST.
     - activating(status=1)
    STATUS AFTER ACTIVATED
     - attack mitigated (status=2)
     - attack stopped (status=3)
     - attack exceeded capability(status=4)
    DELETE
     - deleting(status=5?)
     - deleted(RETURN 4.04)



[TR] Delete is a confirmable message, DOTS server will send an ACK to acknowledge the receipt of the message to avoid retransmissions from the DOTS client. After the mitigation request is successfully deleted, DOTS server returns 2.02 (Deleted) response code, thus conveying the transient status in this case is not necessary.

[kaname] As I noted, deleting of mitigation could take several seconds (or minutes) in real-life.

 

[TR2] Yes, but the DOTS server immediately sends a ACK (acknowledging the receipt of the DELETE message), thus the DOTS client knows the server has received the Delete request and is processing the request. After deleting the mitigation (may take several seconds), server sends 2.02 (Delete) response code. I don’t see a problem.

 

-Tiru

 

[kaname2] The same story could be applied to the status:1 (Attack mitigation is in progress)

[TR3] No, the DOTS client needs to know the mitigation status and DDOS attack status so that it can withdraw the mitigation request when the DDOS attack stops (see Section 5.3.3.1) and to know whether the DOTS mitigation provider is able to successfully mitigate the attack or is re-directing the client to an alternate DOTS server.

These unsolicited notifications are not required for withdraw because after validating the DELETE request DOTS server immediately send an ACK or returns an error that the DELETE request was invalid and it is DOTS server responsibility to withdraw the mitigation request from the DDOS mitigator(s) (which may take several seconds).

 

-Tiru

thank you,
Kaname

If the DOTS client retrieve the status while that time, getting "deleting status", not "2.02 status", will help operators.


4. [Page25] 5.4 b) I couldn't find "retransmission timeout value" attribute in the later figures. Is that equivalent to "ack-timeout"?

[TR] The initial retransmission timeout value is based on the ack-timeout (see https://tools.ietf.org/html/rfc7252#section-4.2).

[kaname] Thank you, I found the reference.


5. [Page27] "policy-id" in "signal-config" is different from "policy-id" in "mitigation-scole". How about using "session-id" in this case?

[TR] Policy-id is a unique identifier identifying the signal channel session configuration request.

[kaname] "policy-id" in Fig.9 and Fig.15 are totally different. I've got confused when reading the draft because they have the same name.


 

# draft-reddy-dots-data-channel-03

1. [General] Data channel doesn't have heartbeat mechanism. I guess the reason is that there is heartbeat mechanism in the signal channel so it is enough, is that right?

[TR] No, the heartbeat mechanism in signal channel cannot be used for data channel. DOTS signal channel is using the “CoAP ping mechanism”. For data channel, TLS heartbeat can be used. I have updated draft.

[kaname] OK. I'll see updated draft.



2. [related to Ehud's question 8] I-D.ietf-netmod-acl-model says "ACL is an ordered list of Access List Entries (ACE)" but I couldn't find a text about how they are ordered. Should we have a operation of changing the order of ACEs installed in a DOTS server?

[TR] PUT can be used by the DOTS client to re-order/update/modify the list of ACE conveyed to the DOTS server. Updated draft to discuss about PUT.

[kaname] OK. I'll see updated draft.


thank you,
kaname


-Tiru


thank you,
Kaname

On 2017/02/14 23:58, Tirumaleswar Reddy (tireddy) wrote:

Hi Ehud,

 

Please see inline for responses to comments on draft-reddy-dots-data-channel-03

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru and authors Hi

 

Attached please find my comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

 

Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy-dots-signal-channel-07

 

1.       General comment: For all signals in the draft, need to add means to allow vendor specific attributes as part of all signals transactions

 

2.       General comment: Just for clarity, need to explicitly mention on each figure when it is an example or the actual API

 

3.       Page 3 second paragraph : DOTS should not be limited to “enterprise network” only

.

4.       Page 4 chapter 4: The overall context of the “happy eyeballs” and its relations (or coexistence) to CoAP is not clear.  

 

5.       Page 7 chapter 5.2.1: The need for YANG model cannot be understood from text. What are the needs for YANG models? What is the relation to the JSONs in the other chapters in the draft

 

6.       Page 14 figure 5: The mitigation request attributes are right but not enough. Need to add more telemetry info about the actual attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG.

 

7.       Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested

 

8.       Page 15 last paragraph: Not sure that target port or target protocol can define a protected entity. IP, FQDN, URI are the only “stand alone” attributes , port and protocol are companion attributes. See also figure 9 .

 

9.       Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is related ?   “policy ID” ? I think the best is have another attribute to define the priority of mitigation requests

 

10.   Page 21 table: The return status are right but not enough. Need to add more telemetry info about the actual mitigation going on (how much traffic was mitigated) and the attack that are mitigated, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG.

 

11.   Page 15 : Need to find the way to bind the target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

12.   Page 21 last paragraph: This is very strong point.

 

13.   Page 25 : Regarding attack status, same point about telemetry.

 

14.   Page 25 chapter 5.4: I believe it can valuable to add a short high level description about the proposed API flow, same as you did for 5.3 .

 

15.   Page 27:  The necessity of policy_id here is not clear enough, are the “Signal Channel Session Configuration” define only “single” DOTS session or the entire communication between Client and Server for several DOTS request for mitigation?

 

16.   Page 27: Not sure about the reason for “at least one of the attributes heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor MUST be present.” Also consider to change to “presented”.

 

17.   Page 30 chapter 5.5: Need to specify the overall scenario, in reaction to which signal (or API transaction POST of Mitigation Request , unidirectional notification from Server as describes in page 23 in page 21 ?) the  redirection occurred ?

 

 

Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-dots-data-channel-03

 

1.       General comment: For all signal in the draft, need to add means to allow vendor specific attributes as part of all signals transactions

 

[TR] Agreed, updated draft.

 

2.       Page 5 second paragraph: Why it is required to configure the DOTS signal channel session ?  

 

[TR] No need to configure DOTS signal channel session, fixed second paragraph.

 

3.       Page 8 chapter 3.2.1 : Any reason for not including these identifiers in the DOTS signal channel draft ?

 

[TR] Identifiers created for resources in DOTS data channel are used in DOTS signal channel to request DDOS mitigation. It’s the responsibility of DOTS data channel to create aliases for resources (see https://tools.ietf.org/html/draft-ietf-dots-requirements-03#section-2.3). The main reason for DOTS signal channel not creating identifiers is the message size may exceed Path MTU.

 

 

4.       Page 9 figure 3 : Need to find the way to bind the target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

[TR] Yes, it is possible; create different aliases for IP1 TCP port 80 and IP2 UDP port 53.

 

 

5.       Page 13 chapter 3.3 : Need to emphasize that filtering rules are relevant for both client server direct communication and through a DOTS gateway. The chapter is a bit confusing.

 

[TR] Thanks, fixed chapter 3.3.

 

 

6.       Page 14 chapter 3.3 : I am missing the white-list installation, is it by using the permit action ?

 

[TR]  Yes, “permit” action is used for white-list installation; it’s defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09

 

 

7.       Page 15 figure 8: For DDoS it is highly valuable to have rate limit as an action. Consider adding such action (if already defined need to explain where and how).

 

[TR] Done, updated draft.

 

8.       Page 15 figure 8: Need to consider adding priority to an ACL to support cases when several filtering rules are conflicting.

 

[TR]  We are not doing anything new to ACL, ACL an ordered list of Access List Entries (ACE) based on priority.

 

 

9.       Page 15 : The action field cannot be optional attribute.

 

[TR] As per https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 if the action field not specified then “deny” is the default action.

 

10.   Page 16 chapter 3.3.3: Need to add more telemetry info about the actual traffic that was blocked (bps, pps and so on), but as I believe this might be another issue…

 

[TR] Chapter 3.3.3 only discusses telemetry details of number of matches for the installed filtering rules.

 

-Tiru

 

Thanks,

 

Ehud Doron |  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

 






_______________________________________________
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

 



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

--------------D37DF423C244820247652536-- From nobody Tue Feb 21 21:56:17 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDA8129619 for ; Tue, 21 Feb 2017 21:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nasa.gov 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 X03jVmUhB2Ve for ; Tue, 21 Feb 2017 21:56:14 -0800 (PST) Received: from ndjsvnpf101.ndc.nasa.gov (NDJSVNPF101.ndc.nasa.gov [198.117.1.151]) (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 2B2C912961D for ; Tue, 21 Feb 2017 21:56:14 -0800 (PST) X-Comment: SPF check N/A for local connections - client-ip=198.117.1.198; helo=ndjsppt104.ndc.nasa.gov; envelope-from=gilbert.j.clark@nasa.gov; receiver=dots@ietf.org DKIM-Filter: OpenDKIM Filter v2.11.0 ndjsvnpf101.ndc.nasa.gov C80C840000B4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nasa.gov; s=letsgomars; t=1487742972; bh=3Eh1uJTmxECk4JFR+x68fiI8gVqNxg0O06o6PLxij4U=; h=From:To:Subject:Date:References:In-Reply-To:From; b=CSWtHGUZ3HbhEcry6yFYftlTLxEVr3nPc0FLMPaYwh0t8jwlGUXvyUW89CAF2H22l 6YK1XK+gUFl5UNGyehfNrAQw78RdPpvslXWuDwt0vGzInGkQJfmdABAfYARSqdbI11 fDpx4pXyIMIqDLuOLGYWqLsXgINoGLMiGy8xYsOIwMX/2tzj6g0MjJopQsYdlwexbP Oi5vw90SR0V6sSEyLEEHopPyP3lnt/Bk8XBcLMAYsw+f95aOgtC8j11rAJrHz3FLa6 HXNbHTj4Mp97N+Czjzid1SC1dry3PwbhepBiNOIz021KCGL6Jk9Ny6FkKJtepWE+Vg L5ciFoY7sBEAQ== Received: from ndjsppt104.ndc.nasa.gov (ndjsppt104.ndc.nasa.gov [198.117.1.198]) by ndjsvnpf101.ndc.nasa.gov (Postfix) with ESMTP id C80C840000B4; Tue, 21 Feb 2017 23:56:12 -0600 (CST) Received: from pps.filterd (ndjsppt104.ndc.nasa.gov [127.0.0.1]) by ndjsppt104.ndc.nasa.gov (8.16.0.20/8.16.0.20) with SMTP id v1M5kM9C001085; Tue, 21 Feb 2017 23:56:12 -0600 Received: from ndjscht109.ndc.nasa.gov (ndjscht109-pub.ndc.nasa.gov [198.117.1.209]) by ndjsppt104.ndc.nasa.gov with ESMTP id 28s1es0gsr-1; Tue, 21 Feb 2017 23:56:12 -0600 Received: from NDJSMBX201.ndc.nasa.gov ([169.254.4.228]) by NDJSCHT109.ndc.nasa.gov ([198.117.1.179]) with mapi id 14.03.0319.002; Tue, 21 Feb 2017 23:56:12 -0600 From: "Clark, Gilbert J. (GRC-LCA0)" To: "Roman D. Danyliw" , "Mortensen, Andrew" , "dots@ietf.org" Thread-Topic: use of restconf for the data channel? Thread-Index: AQHShUvelq2Fax0X1U+DAQQ/dairhqFqKpDAgApPffE= Date: Wed, 22 Feb 2017 05:56:11 +0000 Message-ID: <5AE9F2D3F5799545818A4795DA145E7103BC588B@NDJSMBX201.ndc.nasa.gov> References: <6AE56175-DBE7-4CD9-BA4E-5DCA88E901D8@arbor.net>, <359EC4B99E040048A7131E0F4E113AFC0104F01D17@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0104F01D17@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.118.191.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-22_03:, , signatures=0 Archived-At: Subject: Re: [Dots] use of restconf for the data channel? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 05:56:15 -0000 Hi:=0A= =0A= My strongest objection to both NETCONF and RESTCONF were in the context of = their consideration for use in the signal channel.=0A= =0A= I wouldn't personally vote to see NETCONF, specifically, used in either cha= nnel. NETCONF can involve substantial implementation complexity to support= capabilities that, in the case of DOTS, seem to me to be of marginal utili= ty at best.=0A= =0A= The use of RESTCONF seems a little more reasonable to me here since many of= those implementation requirements are relaxed. =0A= =0A= I will note that adoption of RESTCONF will inflict a 100+ page not-yet-RFC = as (additional) required reading for anyone who wishes to implement a DOTS = data channel from scratch. Also, note that the use of RESTCONF would intro= duce a dependency on something that is still in development, and that there= fore most likely hasn't yet been very well tested and / or may be subject t= o change.=0A= =0A= Just offering some clarification on my original opinion(s), for what that's= worth.=0A= =0A= -Gilbert=0A= _________________________________=0A= From: Dots [dots-bounces@ietf.org] on behalf of Roman D. Danyliw [rdd@cert.= org]=0A= Sent: Wednesday, February 15, 2017 9:51 AM=0A= To: Mortensen, Andrew; dots@ietf.org=0A= Subject: Re: [Dots] use of restconf for the data channel?=0A= =0A= > Subject: [Dots] use of restconf for the data channel?=0A= > [snip]=0A= >=0A= > Since RESTCONF is now a concrete proposal, it seems=0A= > worthwhile continuing the debate ahead of the interim=0A= > meeting. Are there specific concerns in the WG=0A= > regarding the use ...=0A= =0A= This discussion topic is one we need to resolve. We can start here on the = list but I'll also add a slot to the interim meeting to continue the conver= sation.=0A= =0A= Roman=0A= =0A= _______________________________________________=0A= Dots mailing list=0A= Dots@ietf.org=0A= https://www.ietf.org/mailman/listinfo/dots=0A= From nobody Tue Feb 21 23:17:55 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C891294BC for ; Tue, 21 Feb 2017 23:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 3hf9Gu-AdIfC for ; Tue, 21 Feb 2017 23:17:52 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402F3129444 for ; Tue, 21 Feb 2017 23:17:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2748; q=dns/txt; s=iport; t=1487747872; x=1488957472; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7xHgjU4J3HlpMhoqbqT3oQcBjodj7mygRkyYf1lNLgI=; b=ldhxmrqhb+shy8VjzaOKOTl2z3a0nwTeF03tJvAMHYDl7RhpbkFBKQ8h sl+RyMPdG0nzLvZFglgtEWMXk6Bmdjyw9wepPoA/m/Da/CNkwiZjK3PA8 QpLVxDmxn3v74wWLF9bc2Cm2N34EA9nKQ8CErlQlNPOYTqr9y6ZkXcBXT I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAQDNOa1Y/4cNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHjVySFpU0gg0fC4V4AoJ0PxgBAgEBAQEBAQFiKIRwAQE?= =?us-ascii?q?BBAEBODQXBAIBCBEEAQEfCQcnCxQJCAIEARIIiW0OsH+LQQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2GTIRvijkFnAsBhnOLJJEYkyQBHziBAFQVPoZJdYktgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,193,1484006400"; d="scan'208";a="215144417" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Feb 2017 07:17:51 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v1M7Hpx2017388 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Feb 2017 07:17:51 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.1210.3; Wed, 22 Feb 2017 01:17:50 -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.1210.000; Wed, 22 Feb 2017 01:17:50 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Clark, Gilbert J. (GRC-LCA0)" , "Roman D. Danyliw" , "Mortensen, Andrew" , "dots@ietf.org" Thread-Topic: use of restconf for the data channel? Thread-Index: AQHShUvelq2Fax0X1U+DAQQ/dairhqFqKpDAgApPffGAADEigA== Date: Wed, 22 Feb 2017 07:17:50 +0000 Message-ID: References: <6AE56175-DBE7-4CD9-BA4E-5DCA88E901D8@arbor.net>, <359EC4B99E040048A7131E0F4E113AFC0104F01D17@marathon> <5AE9F2D3F5799545818A4795DA145E7103BC588B@NDJSMBX201.ndc.nasa.gov> In-Reply-To: <5AE9F2D3F5799545818A4795DA145E7103BC588B@NDJSMBX201.ndc.nasa.gov> 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.21.188] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] use of restconf for the data channel? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 07:17:54 -0000 NETCONF and RESTCONF are not both suitable for DOTS signal channel. But for DOTS data channel RESTCONF is suitable and RESTCONF is already an R= FC https://tools.ietf.org/html/rfc8040.=20 Various products in the market already use RESTCONF (e.g. confd 6.3 http://= www.tail-f.com/management-agent/)=20 -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Clark, Gilbert J. = (GRC- > LCA0) > Sent: Wednesday, February 22, 2017 11:26 AM > To: Roman D. Danyliw ; Mortensen, Andrew > ; dots@ietf.org > Subject: Re: [Dots] use of restconf for the data channel? >=20 > Hi: >=20 > My strongest objection to both NETCONF and RESTCONF were in the context > of their consideration for use in the signal channel. >=20 > I wouldn't personally vote to see NETCONF, specifically, used in either c= hannel. > NETCONF can involve substantial implementation complexity to support > capabilities that, in the case of DOTS, seem to me to be of marginal util= ity at > best. >=20 > The use of RESTCONF seems a little more reasonable to me here since many = of > those implementation requirements are relaxed. >=20 > I will note that adoption of RESTCONF will inflict a 100+ page not-yet-RF= C as > (additional) required reading for anyone who wishes to implement a DOTS > data channel from scratch. Also, note that the use of RESTCONF would > introduce a dependency on something that is still in development, and tha= t > therefore most likely hasn't yet been very well tested and / or may be su= bject > to change. >=20 > Just offering some clarification on my original opinion(s), for what that= 's > worth. >=20 > -Gilbert > _________________________________ > From: Dots [dots-bounces@ietf.org] on behalf of Roman D. Danyliw > [rdd@cert.org] > Sent: Wednesday, February 15, 2017 9:51 AM > To: Mortensen, Andrew; dots@ietf.org > Subject: Re: [Dots] use of restconf for the data channel? >=20 > > Subject: [Dots] use of restconf for the data channel? > > [snip] > > > > Since RESTCONF is now a concrete proposal, it seems worthwhile > > continuing the debate ahead of the interim meeting. Are there > > specific concerns in the WG regarding the use ... >=20 > This discussion topic is one we need to resolve. We can start here on th= e list > but I'll also add a slot to the interim meeting to continue the conversat= ion. >=20 > Roman >=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 From nobody Wed Feb 22 00:54:49 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B28E1293DF for ; Wed, 22 Feb 2017 00:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 XgUJ7XCeHBD4 for ; Wed, 22 Feb 2017 00:54:45 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF769129691 for ; Wed, 22 Feb 2017 00:54:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHN89930; Wed, 22 Feb 2017 08:54:40 +0000 (GMT) Received: from SZXEMA419-HUB.china.huawei.com (10.82.72.37) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 22 Feb 2017 08:53:00 +0000 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.53]) by SZXEMA419-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0235.001; Wed, 22 Feb 2017 16:52:57 +0800 From: "Xialiang (Frank)" To: Dave Dolson Thread-Topic: New Version Notification for draft-reddy-dots-signal-channel-08.txt Thread-Index: AQHSjCCkIbjO+MzHWE6MQfNQQhzR96FzMYZQgADQiUCAALZxkA== Date: Wed, 22 Feb 2017 08:52:56 +0000 Message-ID: References: <148766749366.32553.4722816219476780947.idtracker@ietfa.amsl.com> <68781b8926724ea9ad41230aeb94b1a0@XCH-ALN-017.cisco.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58AD51D2.0051, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.53, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 49163911a9e61dfd23d68d7f568bc8b8 Archived-At: Cc: "dots@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [Dots] New Version Notification for draft-reddy-dots-signal-channel-08.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 08:54:48 -0000 SGkgRGF2ZSwNClBsZWFzZSBzZWUgbXkgcG9pbnRzIGlubGluZToNCg0KLS0tLS3Tyrz+1K28/i0t LS0tDQq3orz+yMs6IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gRGF2 ZSBEb2xzb24NCreiy83KsbzkOiAyMDE3xOoy1MIyMsjVIDY6MDUNCsrVvP7IyzogVGlydW1hbGVz d2FyIFJlZGR5ICh0aXJlZGR5KTsgZG90c0BpZXRmLm9yZw0K1vfM4jogUmU6IFtEb3RzXSBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJlZGR5LWRvdHMtc2lnbmFsLWNoYW5uZWwt MDgudHh0DQoNCk9uIHRoZSB0b3BpYyBvZiAiSGFwcHkgRXllYmFsbHMiIChhbHRob3VnaCBJIHRo aW5rIHRoaXMgaXMgYSBtaXNub21lciksIEkgYmVsaWV2ZSB0aGUgaW50ZW50IHdvdWxkIGJlIHRv IHVzZSB0aGUgc2FtZSBwb2xpY3ktaWQgaW4gZWFjaCBvZiB0aGUgdHJhbnNwb3J0cywgdG8gZGV0 ZWN0IGR1cGxpY2F0ZXMgYXQgdGhlIHNlcnZlciwgY29ycmVjdD8NClRoZSBkb2N1bWVudCBzaG91 bGQgc2F5IHNvLiAoT3IgaWYgbm90LCBleHBsYWluIGhvdyBkdXBsaWNhdGVzIGFyZSB0byBiZSBk ZXRlY3RlZC4pDQpbRnJhbmtdOiB0aGUgbWFpbiBnb2FsIG9mICJIYXBweSBFeWViYWxscyIgaXMg dG8gbWluaW1pemUgdGhlIHRyYW5zcG9ydCBjb25uZWN0aW9uIHNldHVwIGRlbGF5Lg0KDQpBbHNv LCBoYXMgdGhvdWdodCBiZWVuIGdpdmVuIHRvIHByZXZlbnRpbmcgcmVwbGF5IGF0dGFja3M/ICBF LmcuLCBtYWxpY2lvdXNseSBhc2tpbmcgZm9yIG1pdGlnYXRpb24gYnkgcmVwbGF5aW5nIGEgY2Fw dHVyZWQgbWl0aWdhdGlvbiByZXF1ZXN0Pw0KW0ZyYW5rXTogRE9UUyByZXF1aXJlbWVudHMgZHJh ZnQgbWVudGlvbmVkIHRoaXMgcG9pbnQgYWxyZWFkeSAoU0VDLTAwMykuIEkgYWdyZWVzIHNvbWUg bWV0aG9kcyB0byBhdm9pZCBpdCBzaG91bGQgYmUgZGVzY3JpYmVkIGluIHRoZSBzaWduYWwgY2hh bm5lbCBkcmFmdC4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRG90cyBb bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRpcnVtYWxlc3dhciBS ZWRkeSAodGlyZWRkeSkNClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDIxLCAyMDE3IDQ6MzEgQU0N ClRvOiBkb3RzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RvdHNdIE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtcmVkZHktZG90cy1zaWduYWwtY2hhbm5lbC0wOC50eHQNCg0KVGhp cyByZXZpc2lvbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVkZHktZG90cy1z aWduYWwtY2hhbm5lbC0wOCBhZGRyZXNzZXMgY29tbWVudHMgZnJvbSBFaHVkIGFuZCBLYW5hbWUu IA0KDQpNYWpvciBjaGFuZ2VzIGFyZToNCg0KMSlET1RTIG1pdGlnYXRpb24gcmVxdWVzdC9yZXNw b25zZSBhcmUgbWFya2VkIGFzIG5vbi1jb25maXJtYWJsZSBtZXNzYWdlcy4gUmVxdWVzdHMgbWFy a2VkIGJ5IHRoZSBET1RTICBjbGllbnQgYXMgTm9uLWNvbmZpcm1hYmxlIG1lc3NhZ2VzIGFyZSBz ZW50IGF0IHJlZ3VsYXIgaW50ZXJ2YWxzIHVudGlsIGEgcmVzcG9uc2UgaXMgcmVjZWl2ZWQgZnJv bSB0aGUgRE9UUyBzZXJ2ZXIgKFNlZSBTZWN0aW9uIDUuMyBmb3IgbW9yZSBkZXRhaWxzKS4gDQoN CihUaGFua3MgdG8gdGhlIGZlZWRiYWNrIGZyb20gRmxlbW1pbmcsIEFuZHJldyBhbmQgRWh1ZCku DQoNCjIpQWRkZWQgc3VwcG9ydCBmb3IgdmVuZG9yIHNwZWNpZmljIHBhcmFtZXRlcnMuDQoNCjMp QWRkZWQgbmV3IE1pdGlnYXRpb24gc3RhdHVzIHBhcmFtZXRlcnM6IGJ5dGVzX2Ryb3BwZWQsIGJw c19kcm9wcGVkLCBwa3RzX2Ryb3BwZWQgYW5kIHBwc19kcm9wcGVkLg0KDQpDb21tZW50cyBhbmQg c3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNCi1UaXJ1DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDIxLCAyMDE3 IDI6MjggUE0NCj4gVG86IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpIDxwcmFzcGF0aUBjaXNj by5jb20+OyBNb2hhbWVkIEJvdWNhZGFpciANCj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20+OyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIA0KPiA8dGlyZWRkeUBjaXNjby5jb20+ DQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+IGRyYWZ0LXJlZGR5 LWRvdHMtc2lnbmFsLWNoYW5uZWwtMDgudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LXJlZGR5LWRvdHMtc2lnbmFsLWNoYW5uZWwtMDgudHh0DQo+IGhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGlydW1hbGVzd2FyIFJlZGR5IGFuZCBwb3N0ZWQgdG8g DQo+IHRoZSBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtcmVkZHktZG90cy1z aWduYWwtY2hhbm5lbA0KPiBSZXZpc2lvbjoJMDgNCj4gVGl0bGU6CQlEaXN0cmlidXRlZCBEZW5p YWwtb2YtU2VydmljZSBPcGVuIFRocmVhdCBTaWduYWxpbmcgKERPVFMpDQo+IFNpZ25hbCBDaGFu bmVsDQo+IERvY3VtZW50IGRhdGU6CTIwMTctMDItMjENCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCj4gUGFnZXM6CQk0Ng0KPiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJlZGR5LWRvdHMtc2lnbmFsLQ0KPiBjaGFubmVs LTA4LnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtcmVkZHktZG90cy1zaWduYWwtY2hhbm5lbC8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS1kb3RzLXNpZ25hbC1jaGFubmVs LTA4DQo+IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtcmVkZHktZG90cy1zaWduYWwtY2hhbm5lbC0NCj4gMDgNCj4gDQo+IEFic3RyYWN0Og0K PiAgICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIG1lY2hhbmlzbSB0aGF0IGEgRE9UUyBjbGll bnQgY2FuIHVzZSB0bw0KPiAgICBzaWduYWwgdGhhdCBhIG5ldHdvcmsgaXMgdW5kZXIgYSBEaXN0 cmlidXRlZCBEZW5pYWwtb2YtU2VydmljZSAoRERvUykNCj4gICAgYXR0YWNrIHRvIGFuIHVwc3Ry ZWFtIERPVFMgc2VydmVyIHNvIHRoYXQgYXBwcm9wcmlhdGUgbWl0aWdhdGlvbg0KPiAgICBhY3Rp b25zIGFyZSB1bmRlcnRha2VuIChpbmNsdWRpbmcsIGJsYWNraG9sZSwgZHJvcCwgcmF0ZS1saW1p dCwgb3INCj4gICAgYWRkIHRvIHdhdGNoIGxpc3QpIG9uIHRoZSBzdXNwZWN0IHRyYWZmaWMuICBU aGUgZG9jdW1lbnQgc3BlY2lmaWVzDQo+ICAgIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsIGluY2x1 ZGluZyBIYXBweSBFeWViYWxscyBjb25zaWRlcmF0aW9ucy4gIFRoZQ0KPiAgICBzcGVjaWZpY2F0 aW9uIG9mIHRoZSBET1RTIGRhdGEgY2hhbm5lbCBpcyBlbGFib3JhdGVkIGluIGEgY29tcGFuaW9u DQo+ICAgIGRvY3VtZW50Lg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+IHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEb3RzIG1haWxpbmcgbGlzdA0K RG90c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3Rz DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEb3Rz IG1haWxpbmcgbGlzdA0KRG90c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kb3RzDQo= From nobody Wed Feb 22 00:55:17 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F09F12969D for ; Wed, 22 Feb 2017 00:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 rjowJ_-_yqsw for ; Wed, 22 Feb 2017 00:55:12 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B8B41293DF for ; Wed, 22 Feb 2017 00:55:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4700; q=dns/txt; s=iport; t=1487753712; x=1488963312; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=eo/VAJjpRkdVGOTHuGcZ0sl9trDyz4wr0g3WMG0MoFo=; b=RdlC7BmrXhE5dRQUeXpHh530BrBQOvCp5S3isi+tfHYth1i1Uw+MOFai t3c5VxLUviDgxcMRXTOi6BYpDaIh1fp/wi7as5JXwoUXJ7KnR6ioOS6Mf atG/cVKPh+3/DX9I6xPwq0Dtka22GgrmWCWwiZtLxSQXs6GT7zrS6aHs5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAQDfUK1Y/5pdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHjVyRWpU0gg0fC4V4AoJ0PxgBAgEBAQEBAQFiKIRwAQE?= =?us-ascii?q?BAwEBATg0CQcHBAIBCA4DBAEBHwkHJwsUCQgCBAESCIllCA6xIItFAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYZMhG+DF4EaDYV7BY9JjEIBhnOLJIIEU4RJiXiINYp?= =?us-ascii?q?vAR84gQBUFRgmhkl1AYd8AQYfgQqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,193,1484006400"; d="scan'208";a="388730380" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2017 08:55:11 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v1M8tBJR023016 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Feb 2017 08:55:11 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.1210.3; Wed, 22 Feb 2017 02:55:10 -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.1210.000; Wed, 22 Feb 2017 02:55:10 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Dave Dolson , "dots@ietf.org" Thread-Topic: New Version Notification for draft-reddy-dots-signal-channel-08.txt Thread-Index: AQHSjCCkIbjO+MzHWE6MQfNQQhzR96FzMYZQgADQiUCAAJ2nMA== Date: Wed, 22 Feb 2017 08:55:10 +0000 Message-ID: <213d4ddabdb1441495ce430aa7da8d69@XCH-RCD-017.cisco.com> References: <148766749366.32553.4722816219476780947.idtracker@ietfa.amsl.com> <68781b8926724ea9ad41230aeb94b1a0@XCH-ALN-017.cisco.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.21.188] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] New Version Notification for draft-reddy-dots-signal-channel-08.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 08:55:14 -0000 > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Wednesday, February 22, 2017 3:35 AM > To: Tirumaleswar Reddy (tireddy) ; dots@ietf.org > Subject: RE: New Version Notification for draft-reddy-dots-signal-channel= - > 08.txt >=20 > On the topic of "Happy Eyeballs" (although I think this is a misnomer),=20 Why "Happy Eyeballs" is used by most browsers today https://tools.ietf.org/= html/rfc6555 and MIF WG is also using "Happy Eyeballs" technique (see https= ://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-11).=20 > I believe > the intent would be to use the same policy-id in each of the transports, = to > detect duplicates at the server, correct? No. The use of "Happy Eyeballs" is test and pick a transport using which TL= S or DTLS session can be established with the DOTS server (UDP has higher p= recedence than TCP). Once the session is established on a specific transport, there is no need t= o send the mitigation request on both the transports. > The document should say so. (Or if not, explain how duplicates are to be > detected.) >=20 >=20 > Also, has thought been given to preventing replay attacks? E.g., malicio= usly > asking for mitigation by replaying a captured mitigation request? DTLS is capable of detecting replay attacks, see https://tools.ietf.org/htm= l/rfc6347#section-3.3. I will update the draft to say Replay Detection usin= g DTLS is mandatory for DOTS agents. -Tiru >=20 >=20 >=20 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy > (tireddy) > Sent: Tuesday, February 21, 2017 4:31 AM > To: dots@ietf.org > Subject: Re: [Dots] New Version Notification for draft-reddy-dots-signal- > channel-08.txt >=20 > This revision https://tools.ietf.org/html/draft-reddy-dots-signal-channel= -08 > addresses comments from Ehud and Kaname. >=20 > Major changes are: >=20 > 1)DOTS mitigation request/response are marked as non-confirmable > messages. Requests marked by the DOTS client as Non-confirmable messages > are sent at regular intervals until a response is received from the DOTS = server > (See Section 5.3 for more details). >=20 > (Thanks to the feedback from Flemming, Andrew and Ehud). >=20 > 2)Added support for vendor specific parameters. >=20 > 3)Added new Mitigation status parameters: bytes_dropped, bps_dropped, > pkts_dropped and pps_dropped. >=20 > Comments and suggestions are welcome. >=20 > -Tiru >=20 >=20 > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Tuesday, February 21, 2017 2:28 PM > > To: Prashanth Patil (praspati) ; Mohamed Boucadair > > ; Tirumaleswar Reddy (tireddy) > > > > Subject: New Version Notification for > > draft-reddy-dots-signal-channel-08.txt > > > > > > A new version of I-D, draft-reddy-dots-signal-channel-08.txt > > has been successfully submitted by Tirumaleswar Reddy and posted to > > the IETF repository. > > > > Name: draft-reddy-dots-signal-channel > > Revision: 08 > > Title: Distributed Denial-of-Service Open Threat Signaling (DOTS) > > Signal Channel > > Document date: 2017-02-21 > > Group: Individual Submission > > Pages: 46 > > URL: https://www.ietf.org/internet-drafts/draft-reddy-dots-s= ignal- > > channel-08.txt > > Status: https://datatracker.ietf.org/doc/draft-reddy-dots-signa= l- > channel/ > > Htmlized: https://tools.ietf.org/html/draft-reddy-dots-signal-cha= nnel-08 > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-dots-si= gnal- > channel- > > 08 > > > > Abstract: > > This document specifies a mechanism that a DOTS client can use to > > signal that a network is under a Distributed Denial-of-Service (DDoS= ) > > attack to an upstream DOTS server so that appropriate mitigation > > actions are undertaken (including, blackhole, drop, rate-limit, or > > add to watch list) on the suspect traffic. The document specifies > > the DOTS signal channel including Happy Eyeballs considerations. Th= e > > specification of the DOTS data channel is elaborated in a companion > > document. > > > > > > > > > > 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.i= etf.org. > > > > The IETF Secretariat >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Feb 22 01:04:16 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF501293DF for ; Wed, 22 Feb 2017 01:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6zFPAaA7TBZT for ; Wed, 22 Feb 2017 01:04:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD62A129698 for ; Wed, 22 Feb 2017 01:04:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHN91695; Wed, 22 Feb 2017 09:04:09 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 22 Feb 2017 09:03:51 +0000 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.53]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Wed, 22 Feb 2017 17:03:47 +0800 From: "Xialiang (Frank)" To: Dave Dolson Thread-Topic: feedback on draft-ietf-dots-requirements Thread-Index: AdJCw56N3It0vvnJSvSfOG8E2IPZ9BI48yMAADWyNkAAGrhBIA== Date: Wed, 22 Feb 2017 09:03:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12B0C6CB9SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0208.58AD5409.0540, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.53, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2d5dc9f869a00690c3f88ac4003fc913 Archived-At: Cc: "Mortensen, Andrew" , "dots@ietf.org" Subject: Re: [Dots] feedback on draft-ietf-dots-requirements X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 09:04:15 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12B0C6CB9SZXEMA502MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2ZSwNClBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lOg0KDQrlj5Hku7bkuro6IERv dHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBEYXZlIERvbHNvbg0K5Y+R 6YCB5pe26Ze0OiAyMDE35bm0MuaciDIy5pelIDU6MjANCuaUtuS7tuS6ujogTW9ydGVuc2VuLCBB bmRyZXcNCuaKhOmAgTogZG90c0BpZXRmLm9yZw0K5Li76aKYOiBSZTogW0RvdHNdIGZlZWRiYWNr IG9uIGRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMNCg0KSSBmZWVsIHNvbWUgZGlzY29ubmVj dC4gTWF5YmUgZm9sa3MgY291bGQgc2hhcmUgdGhlaXIgdmlld3Mgb24gdGhlIGZvbGxvd2luZyBx dWVzdGlvbnM6DQoNCg0KMS4gICAgICAgSXMgYSBkb3RzIHNpZ25hbC1jaGFubmVsIHJlcXVlc3Qg YSBjb21tYW5kIG9yIGFuIGFkdmlzb3J5PyBJLmUuLCBNVVNUIHRoZSBzZXJ2ZXIgbWl0aWdhdGUs IG9yIGRvZXMgdGhlIHNlcnZlciBzaW1wbHkgY29uc2lkZXIgaXQgYSBkYXRhLXBvaW50IGluIHRo ZSBvbmdvaW5nIGJhdHRsZT8NCltNeSBvcGluaW9uOiBhZHZpc29yeTsgdGhlIGNsaWVudCBpcyBu b3QgYWx3YXlzIHJpZ2h0IG9yIHRydXN0d29ydGh5LCBvciBtaXRpZ2F0aW9uIGlzIG5vdCBhbHdh eXMgYXZhaWxhYmxlXQ0KW0ZyYW5rXTogSSBzaGFyZSB0aGUgc2FtZSBpZGVhIHdpdGggeW91LiBG b3IgZXhhbXBsZSwgaW4gT1AtMDA0LCBJIGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgRE9UUyBzZXJ2 ZXIgTVVTVCBjZWFzZSBtaXRpZ2F0aW9uIEFTQVAgaW4gcmVzcG9uc2UgdG8gRE9UUyBjbGllbnTi gJlzIHdpdGhkcmF3IHJlcXVlc3Q/DQoNCg0KMi4gICAgICAgSXMgdGhlcmUgYSBxdWVzdGlvbiBv ZiBvdmVybGFwcGluZyByZXNvdXJjZXM/IEkuZS4sIE1heSBkaWZmZXJlbnQgY2xpZW50cyBhc2sg Zm9yIG1pdGlnYXRpb24gb2YgdGhlIHNhbWUgc2NvcGU/IChJZiBub3QsIGhvdyBpcyBvd25lcnNo aXAgb2YgcmVzb3VyY2VzIGRldGVybWluZWQ/KQ0KW015IG9waW5pb246IHRoZXJlIGlzIG93bmVy c2hpcCwgc28gb3ZlcmxhcCBpcyBub3QgcG9zc2libGUuIE5lZ290aWF0ZWQgaW4gZGF0YSBjaGFu bmVsLl0NCltGcmFua106IGFncmVlLg0KDQoNCjMuICAgICAgIElzIGEgc2Vzc2lvbiByZXF1aXJl ZCAobGlrZSBEaWFtZXRlcik/IE9yIGNhbiBlYWNoIHJlcXVlc3Qgc3RhbmQgYWxvbmUgKGxpa2Ug RE5TKT8NCltNeSBvcGluaW9uOiBzZXNzaW9uIGlzIG5vdCByZXF1aXJlZCwgYW5kIGJ5IGl0cyBj b21wbGV4aXR5IGhhcm1mdWwuXQ0KW0ZyYW5rXTogRE9UUyBhcmNoaXRlY3R1cmUgZHJhZnQgaGFz IHRoZSBkZWZpbml0aW9uIGFib3V0IERPVFMgc2lnbmFsaW5nIHNlc3Npb24uIEkgdGhpbmsgaXTi gJlzIHVzZWZ1bCBzaW5jZSBET1RTIHByb3RvY29sIGhhcyBzb21lIGtpbmRzIG9mIHRyYW5zYWN0 aW9uIGZlYXR1cmUuDQoNCg0KLURhdmUNCg0KDQoNCkZyb206IE1vcnRlbnNlbiwgQW5kcmV3IFtt YWlsdG86YW1vcnRlbnNlbkBhcmJvci5uZXRdDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDIwLCAy MDE3IDE6MzEgUE0NClRvOiBEYXZlIERvbHNvbg0KQ2M6IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRv dHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogZmVlZGJhY2sgb24gZHJhZnQtaWV0Zi1kb3RzLXJl cXVpcmVtZW50cw0KDQpUaGFua3MsIERhdmUuIFRoaXMgaXMgdmVyeSBoZWxwZnVsLiBNeSAoZXh0 cmVtZWx5IHRhcmR5KSByZXNwb25zZXMgYXJlIGlubGluZS4gSeKAmXZlIHNuaXBwZWQgbW9zdCBv ZiB0aGUgbWlub3IgcmVwaHJhc2luZyBzdWdnZXN0aW9ucy4gQWxsIGNvbW1lbnRzIGFyZSBtZSBz cGVha2luZyBmb3IgbXlzZWxmLCBub3QgbmVjZXNzYXJpbHkgZm9yIHRoZSBvdGhlciByZXF1aXJl bWVudHMgZHJhZnQgZWRpdG9ycy4NCg0KSeKAmXZlIG9wZW5lZCBpc3N1ZXMgb24gZ2l0aHViIGZv ciBtb3N0IG9mIHRoZXNlIGNvbW1lbnRzLg0KDQpPbiBOb3YgMjYsIDIwMTYsIGF0IDk6MzEgUE0s IERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5lLmNvbTxtYWlsdG86ZGRvbHNvbkBzYW5kdmlu ZS5jb20+PiB3cm90ZToNCg0K4oCmc25pcC4uLg0KMS4yDQrigKZzbmlwLi4uDQpGb3Ig4oCcY291 bnRlcm1lYXN1cmXigJ0sIHRoaXMgc291bmRzIGxpa2Ugb25seSBwYWNrZXQgZmlsdGVyaW5nLiBJ cyB0aGF0IGFjY3VyYXRlIGFuZCBjb21wbGV0ZT8gQ291bGQgdGFyLXBpdCBvciByb3V0aW5nIGNo YW5nZXMgYmUgaW5jbHVkZWQgaW4gY291bnRlcm1lYXN1cmVzPw0KDQpJIGRvbuKAmXQgd2FudCB0 aGUgZG9jdW1lbnQgdG8gcmVzdHJpY3QgdGhlIGRlZmluaXRpb24gb2YgY291bnRlcm1lYXN1cmUs IGJ1dCBJ4oCZbSBhbHNvIG5vdCBrZWVuIHRvIGVuc2hyaW5lIHNwZWNpZmljIHR5cGVzIG9mIGNv dW50ZXJtZWFzdXJlLCBlaXRoZXIuIEnigJlsbCByZXZpc2UgdG8gbWFrZSBpdCBjbGVhcmVyLg0K DQpJcyDigJxzaWduYWwgY2hhbm5lbOKAnSBpbnRlbmRlZCB0byBiZSB0aGUgc2FtZSB0aGluZyBh cyB0aGUg4oCcc2Vzc2lvbuKAnSBtZW50aW9uZWQgaW4gdGhlIGFyY2hpdGVjdHVyZT8gSSB0aGlu ayBzbywgYW5kIHRlcm1pbm9sb2d5IHNob3VsZCBiZSBtYWRlIGNvbnNpc3RlbnQgYmV0d2VlbiB0 aGUgZG9jcy4gSWYgbm90LCBJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUgZGlmZmVyZW5jZSBiZXR3 ZWVuIGNoYW5uZWwgYW5kIHNlc3Npb24uDQoNClNwZWFraW5nIGZvciBteXNlbGYsIHRoZSDigJxj aGFubmVs4oCdIGRpc3RpbmN0aW9uIGlzIG1lYW50IHRvIGRpc3Rpbmd1aXNoIHRoZSB1bnJlbGlh YmxlLCBsaWdodHdlaWdodCBTT1MgbWVzc2FnZXMgdG8gYmUgdXNlZCB3aGVuIHVuZGVyIGF0dGFj ayBmcm9tIHRoZSByZWxpYWJsZSBtZXNzYWdpbmcgcmVxdWlyZWQgdG8gZS5nLiBtYW5hZ2UgZmls dGVycyBhbmQgcmVzb3VyY2UgYWxpYXNlcy4gVGhlIOKAnHNpZ25hbGluZyBzZXNzaW9u4oCdIGlu IHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgaXMgYWN0aXZlIG1lc3NhZ2luZyBiZXR3ZWVuIERP VFMgYWdlbnRzIG92ZXIgdGhlIHNpZ25hbCBjaGFubmVsLg0KDQpTaG91bGQg4oCcRmlsdGVy4oCd IGJlIGxpbWl0ZWQgdG8gdGhlIHR3byBhY3Rpb25zIG9mIHJhdGUtbGltaXRpbmcgb3IgZGlzY2Fy ZGluZz8gIElzIGZpbHRlciByZWFsbHkgaW50ZW5kZWQgdG8gaW5jbHVkZSBhY3Rpb24sIG9yIGp1 c3QgdGhlIG1hdGNoIGNyaXRlcmlhPw0KDQpJdCBzb3VuZHMgbGlrZSB5b3XigJlyZSByZWFsbHkg YXNraW5nIHdoZXRoZXIgd2Ugc2hvdWxkIGxlYXZlIHRoZSBkZWZpbml0aW9uIG9mIOKAnGZpbHRl cmluZ+KAnSB1cCB0byB0aGUgRE9UUyBzZXJ2ZXIvbWl0aWdhdG9yLiBJIHdvcnJ5IHRoYXQgbGVh dmluZyDigJxmaWx0ZXJpbmfigJ0gbG9vc2VseSBkZWZpbmVkIHdpbGwgbGVhZCB0byBjb25mdXNp b24gZnVydGhlciBkb3duIHRoZSBsaW5lLiBJIHRoaW5rIHdlIG5lZWQgZXhwbGljaXQgYWN0aW9u czogZGlzY2FyZCBpcyB2ZXJ5IGRpZmZlcmVudCBmcm9tIHJhdGUtbGltaXQuDQoNCkFzIEkgc2Vl IGl0LCBmaWx0ZXJpbmcgaXMgZGlzdGluY3QgZnJvbSB2ZW5kb3IgZXh0ZW5zaW9ucyB3aGljaCBt aWdodCBpbmNsdWRlIGNvdW50ZXJtZWFzdXJlIHNwZWNpZmljcy4gSSBkb27igJl0IHRoaW5rIERP VFMgaXMgYSBnZW5lcmFsIHB1cnBvc2UgaW50ZXJmYWNlIGZvciBjb3VudGVybWVhc3VyZSBjb25m aWd1cmF0aW9uLg0KDQpTaW1pbGFybHkgZm9yIOKAnEJsYWNrbGlzdOKAnTogaXMgYmxvY2sgdGhl IG9ubHkgdmFsaWQgYWN0aW9uIGZvciBibGFjay1saXN0ZWQgYWRkcmVzc2VzPw0KDQpZZXMsIHRo YXTigJlzIHRoZSBkaXN0aW5ndWlzaGluZyBjaGFyYWN0ZXJpc3RpYyBvZiBhIGJsYWNrbGlzdGVk IHNvdXJjZS4gQSB3aGl0ZWxpc3RlZCBzb3VyY2UgaXMgYWx3YXlzIGFsbG93ZWQgdG8gcGFzcy4g VGhlIERPVFMgY2xpZW50IGhhcyBmdWxsIGNvbnRyb2wgb3ZlciB0aGUgYmxhY2stL3doaXRlLWxp c3RzLCB0aG91Z2ggdGhlIHNjb3BlIGlzIHJlc3RyaWN0ZWQgYnkgdGhlIERPVFMgc2VydmVyIHRv IHByZWZpeGVzL3Jlc291cmNlcyBiZWxvbmdpbmcgdG8gdGhlIERPVFMgY2xpZW50Lg0KDQoyLg0K VGhlIHNlY29uZCBwYXJhZ3JhcGggc2F5cyDigJxET1RTIGlzIGFuIGFkdmlzb3J5IHByb3RvY29s LuKAnSBJIHRob3VnaHQgdGhpcyBtaWdodCBtZWFuIHRoYXQgKGEpIGEgY2xpZW504oCZcyByZXF1 ZXN0IGZvciBhaWQgbWF5IGJlIGlnbm9yZWQgYW5kIChiKSBtaXRpZ2F0aW9uIG1heSBiZSBkb25l IHByaW9yIHRvIHJlcXVlc3Qgb3IgYWZ0ZXIgd2l0aGRyYXdhbC4gV291bGQgdGhhdCBpZGVhIGJl IGFjY3VyYXRlPw0KDQpJIHRoaW5rIChhKSBpcyBjb3JyZWN0LCB0aG91Z2ggaWdub3JpbmcgYSBy ZXF1ZXN0IHdpdGhvdXQgcHJvdmlkaW5nIGEgcmVhc29uIHdoZW4gYSBzZXJ2aWNlIGFncmVlbWVu dCBpcyBpbiBwbGFjZSBzZWVtcyBsaWtlIGEgcG9vciB3YXkgdG8gbWFuYWdlIGEgc2VydmljZS4g SW4gZ2VuZXJhbCBhIERPVFMgcmVxdWVzdCBmb3IgbWl0aWdhdGlvbiBzaG91bGQgcmVzdWx0IGlu IG1pdGlnYXRpb24sIGFzc3VtaW5nIGJ1c2luZXNzIG9yIHNlcnZpY2UgYWdyZWVtZW50cyBhcmUg aW4gcGxhY2UsIGJ1dCBtaXRpZ2F0aW5nIHRoZSBhdHRhY2sgbWlnaHQgaW52b2x2ZSBtb3JlIHRo YW4ganVzdCBhDQoNCkluIGNhbGxpbmcgRE9UUyDigJxhZHZpc29yeeKAnSBJIHdhcyB0cnlpbmcg dG8gZW1waGFzaXplIHR3byBwb2ludHM6IHRoZSBkaWZmaWN1bHR5IG9mIG1haW50YWluaW5nIHJl bGlhYmxlIG1lc3NhZ2luZyB1bmRlciBhdHRhY2sgY29uZGl0aW9ucyAod2l0aCB0aGUgY29yb2xs YXJ5IHRoYXQgYSBET1RTIHNlcnZlciBtYXkgbm90IGJlIGFibGUgdG8gaGVscCBldmVuIGlmIGEg cmVxdWVzdCBnZXRzIHRocm91Z2gpOyBhbmQgdGhlIGZhY3QgdGhhdCBET1RTIGlzIG5vdCBhIGdl bmVyYWwgcHVycG9zZSBtaXRpZ2F0aW9uIEFQSS4NCg0KTWF5YmUgSSBzaG91bGQgY2xhcmlmeSB0 aGF0IGZ1cnRoZXIuIEkgYmVsaWV2ZSB0aGUgRE9UUyAqc2lnbmFsIGNoYW5uZWwqIGlzIG5vdCBh IGdlbmVyYWwgcHVycG9zZSBtaXRpZ2F0aW9uIEFQSS4gVGhlIERPVFMgZGF0YSBjaGFubmVsIGNv dWxkIGV2b2x2ZSBpbnRvIHRoYXQgYXMgYSBzb3J0IG9mIERPVFMgY29udHJvbCBwcm90b2NvbCwg aW4gd2hpY2ggdGhlIGltcGFjdCBvZiBhbiBhdHRhY2sgb24gdGhlIGNvbW11bmljYXRpb24gbGF5 ZXIgYmV0d2VlbiBjbGllbnQgYW5kIHNlcnZlciBpcyBub3QgYSBjb25jZXJuLg0KDQooTXkgdGhp bmtpbmcgaXMgdGhhdCBhIERPVFMgc2VydmVyIG1heSBrbm93IGJldHRlciB0aGFuIHRoZSBjbGll bnQgYmFzZWQgb24gYSB3aWRlciBzb3VyY2Ugb2YgdGVsZW1ldHJ5LikNCg0KQWdyZWVkLiBPbmNl IGEgbWl0aWdhdG9yIGJlZ2lucyBmaWx0ZXJpbmcgdHJhZmZpYyBib3VuZCBmb3IgdGhlIGRvbWFp biBvZiB0aGUgRE9UUyBjbGllbnQsIHRoZSBET1RTIGNsaWVudOKAmXMgdmlldyBpbnRvIHRoZSBh dHRhY2sgaXMgc2tld2VkLg0KDQoNCi0gaW4gR0VOLTAwNCwgY29uc2lkZXIgcGlja2luZyBhIHNw ZWNpZmljIE1UVSBzaXplLCBsaWtlIDUwMCBieXRlcywgYmVjYXVzZSBvdGhlcndpc2UgdGhlcmUg aXMgbm8gd2F5IHRvIGp1ZGdlIGlmIHRoZSBwcm90b2NvbCBtZWV0cyByZXF1aXJlbWVudHMuDQoN ClRoaXMgaGFzIGJlY29tZSBtb3JlIGltcG9ydGFudCBzaW5jZSB5b3Ugc3VnZ2VzdGVkIGl0LCBp biBsaWdodCBvZiB0aGUgcmVjZW50IHRocmVhZCBvbiB0ZWxlbWV0cnkuIGRyYWZ0LXJlZGR5LWRv dHMtc2lnbmFsLWNoYW5uZWwgaXMgc3VnZ2VzdGluZyA1MDAgYnl0ZXMgaW4gdGhlIGV2ZW50IHRo ZSBjbGllbnQgY2Fu4oCZdCBkaXNjZXJuIHBhdGggTVRVLiBJ4oCZbSBjb21mb3J0YWJsZSB3aXRo IHRleHQgdG8gdGhlIGVmZmVjdCB0aGF0IGNsaWVudHMgU0hPVUxEIHRyeSB0byBkZXRlcm1pbmUg cGF0aCBNVFUsIGFuZCBmYWxsIGJhY2sgdG8gNTAwIGJ5dGVzIGlmIGl0IGNhbuKAmXQgYmUgZGlz Y292ZXJlZC4NCg0KDQpJbiAyLjIsDQrigKYgc25pcCAuLi4NCk9QLTAwNDogVGhpcyByZXF1aXJl bWVudCBoYXMgc2V2ZXJhbCBpZGVhcyBpbiBpdCwgd2hpY2ggSSB0aGluayBzaG91bGQgYmUgYnJv a2VuIGludG8gbXVsdGlwbGUgcmVxdWlyZW1lbnRzOg0KKGEpICAgIFRoZSBpZGVhIHRoYXQgbWVz c2FnZXMgYmUgYWNrbm93bGVkZ2VkIHdpdGggYSBzdGF0dXMgY29kZS4NCi0gICAgICAgICAgQnV0 IGl0IGlzIHVuY2xlYXIgd2hldGhlciB0aGUgc3RhdHVzIG11c3QgYmUgZGVsaXZlcmVkIGltbWVk aWF0ZWx5LCBvciByZXBvcnRlZCBsYXRlci4gSSBleHBlY3QgdGhlcmUgY291bGQgYmUgYW4gaW1t ZWRpYXRlIOKAnEkgaGVhciB5b3VyIHJlcXVlc3TigJ0sIHdoaWNoIGRvZXNu4oCZdCBuZWNlc3Nh cmlseSBtZWFuIGFueXRoaW5nIGNhbiBiZSBkb25lLiBUaGVyZSBzaG91bGQgYmUgYSB3YXkgZm9y IHRoZSBjbGllbnQgdG8gbGF0ZXIgYXNrLCDigJxob3cgYXJlIHlvdSBkb2luZyB3aXRoIHRoYXQg cmVxdWVzdD/igJ0NCg0KSSBtZWFudCB0aGlzIHRvIGJlIGxlc3MgcmVzdHJpY3RpdmUgdGhhbiB3 aGF0IHlvdeKAmXZlIGRlc2NyaWJlZC4gVGhlcmUgc2hvdWxkIGJlIHNvbWUgd2F5IGZvciB0aGUg RE9UUyBjbGllbnQgdG8gZGV0ZWN0IHRoYXQgaXRzIG1lc3NhZ2VzIGFyZSBiZWluZyByZWNlaXZl ZC9wcm9jZXNzZWQgb3IgbG9zdCwgYW5kIHRoZSBzYW1lIGlzIHRydWUgZm9yIHRoZSBET1RTIHNl cnZlci4gVGhhdCBkb2VzbuKAmXQgaGF2ZSB0byBtZWFuIGFuIEhUVFAtbGlrZSBtb2RlbC4gRm9y IGV4YW1wbGUsIGluIHRoZSBwcm90b2NvbCBkcmFmdCBOaWsgVGVhZ3VlIGFuZCBJIGhhdmUgcHV0 IHRvZ2V0aGVyLCB0aGUgc2lnbmFsIGNoYW5uZWwgaXMgb25nb2luZywgcGVyaW9kaWMgY29tbXVu aWNhdGlvbiBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyLiBUaGUgY2xpZW50IGRvZXMgbm90IG5l ZWQgdG8gc2VuZCBhIHNlcGFyYXRlIG1lc3NhZ2UgdG8gYXNrIGFib3V0IHJlcXVlc3Qgc3RhdHVz LCBzaW5jZSB0aGUgRE9UUyBzZXJ2ZXIgd2lsbCBzZW5kIGl0IGluIGEgZmV3IHNlY29uZHMgYW55 d2F5Lg0KDQooYikgICBXaGV0aGVyIHRoZSBzZXJ2ZXIgTVVTVCBkbyBhcyBpdCBpcyB0b2xkLg0K LSAgICAgICAgICBPbiB0aGlzIHBvaW50LCBJIHRoaW5rIHRoZSDigJxNVVNUIGNlYXNlIG1pdGln YXRpb24gYWN0aXZpdHnigJ0gaXMgd3JvbmcsIHNpbmNlIHRoZSBzZXJ2ZXIgbWF5IGhhdmUgb3Ro ZXIgZXZpZGVuY2Ugb3Igb3RoZXIgY2xpZW50cyByZXF1ZXN0aW5nIHRoZSBtaXRpZ2F0aW9uLiBU aGlzIGlzIGFja25vd2xlZGdlZCBieSB0aGUg4oCcbWF5IGNvbnRpbnVlIG1pdGlnYXRpbmfigJ0g bGF0ZXIgaW4gdGhlIHBhcmFncmFwaC4gU28gYXQgbWluaW11bSB0aGUgTVVTVCBpcyB0b28gc3Ry b25nLg0KDQpUaGUgZnVsbCBwaHJhc2UgaXMg4oCcTVVTVCBjZWFzZSBtaXRpZ2F0aW9uIGFzIHF1 aWNrbHkgYXMgcG9zc2libGXigJ0sIGJ5IHdoaWNoIEkgbWVhbnQgdG8gZXhwcmVzcyB0aGUgaW1w b3J0YW5jZSBvZiBhbGxvd2luZyB0aGUgc2VydmVyIHRvIG1haW50YWluIHRoZSBtaXRpZ2F0aW9u IGZvciBhIHNob3J0IHBlcmlvZCB0byByZWR1Y2UgdGhlIGltcGFjdCBvZiBhIERPVFMgY2xpZW50 IHJhcGlkbHkgdG9nZ2xpbmcgbWl0aWdhdGlvbi4gSXQgc291bmRzIGxpa2UgdGhlIGR1cmF0aW9u IG9mIHRoYXQgc2hvcnQgcGVyaW9kIG5lZWRzIHRvIGJlIGRlZmluZWQuDQoNCkkgdGhpbmsgdHdv IHRoaW5ncyBzaG91bGQgYmUgY2xlYXIgaW4gdGhlIGZpbmFsIHRleHQ6DQoNCjEpIFRoZSBET1RT IGNsaWVudCBjYW4gY2Vhc2UgdG8gYmUgdGhlIGNhdXNlIGZvciBhIG1pdGlnYXRpb24gYXQgYW55 IHRpbWUgYnkgc2VuZGluZyBhIG1pdGlnYXRpb24gdGVybWluYXRpb24gcmVxdWVzdCwgYnV0IGNh bm5vdCBjb25zaWRlciBhIG1pdGlnYXRpb24gdGVybWluYXRlZCB1bnRpbCBjb25maXJtYXRpb24g ZnJvbSB0aGUgc2VydmVyLiAoTWl0aWdhdGlvbiBsaWZldGltZSBpcyB0aGVyZSB0byBoYW5kbGUg dGhlIGNhc2VzIHdoZXJlIHRoZSBzZXJ2ZXLigJlzIGNvbmZpcm1hdGlvbiBpcyBub3QgZGVsaXZl cmVkLikNCg0KMikgT25jZSBhIERPVFMgY2xpZW50IHRlbGxzIGEgRE9UUyBzZXJ2ZXIgdG8gc3Rv cCBtaXRpZ2F0aW5nLCB0aGUgRE9UUyBjbGllbnQgaXMgbm8gbG9uZ2VyIHJlc3BvbnNpYmxlIGZv ciB0aGUgbWl0aWdhdGlvbi4gVGhlIERPVFMgc2VydmVyL21pdGlnYXRvciBjYW4gY29udGludWUg bWl0aWdhdGluZyBhcmJpdHJhcmlseSwgYnV0IGFmdGVyIHRoZSBtaXRpZ2F0aW9uIHRlcm1pbmF0 aW9uIGdyYWNlIHBlcmlvZCBlbGFwc2VzIGFuZCB0aGUgY2xpZW50IGhhc27igJl0IHJlbmV3ZWQg YSByZXF1ZXN0IGZvciBtaXRpZ2F0aW9uLCBhbGwgcmVzcG9uc2liaWxpdHkgZm9yIHRoZSBtaXRp Z2F0aW9uIGlzIGJvcm5lIGJ5IHRoZSBET1RTIHNlcnZlciBkb21haW4uDQoNCk9QLTAwNi4gSSB3 b3VsZCBsaWtlIHRvIHNlZSBhbGwgb2Ygc3BlY2lmaWMgc2NvcGVzIHByZWNpc2VseSBkZWZpbmVk IGFzIHJlcXVpcmVkIG9yIG9wdGlvbmFsLCBidXQgbm90IGFzIGV4YW1wbGVzLg0KDQpZZXMsIHRo aXMgaXMgYSBnb29kIHN1Z2dlc3Rpb24uDQoNCkFsc28sIEnigJltIG5vdCBjbGVhciBvbiB3aGF0 IEROUyBuYW1lIGZpbHRlcmluZyBtZWFuczogaXMgdGhpcyBmb3IgZmlsdGVyaW5nIEROUyBwYWNr ZXRzLCBvciBmb3IgbG9va2luZyB1cCB0aGUgbmFtZSBhbmQgZmlsdGVyaW5nIHRoZSBjb3JyZXNw b25kaW5nIGFkZHJlc3Nlcz8NCg0KSXTigJlzIG5vdCBETlMgbmFtZSBmaWx0ZXJpbmcsIGJ1dCBp bmRpY2F0aW5nIHdoaWNoIEZRRE5zIG5lZWQgbWl0aWdhdGlvbi4NCg0KDQpPUC0wMDguIEkgaG9w ZSB0aGVyZSBpc27igJl0IGdvaW5nIHRvIGJlIGFuIGFyZ3VtZW50IGFib3V0IHRoaXMsIGJ1dOKA piBJIGJlbGlldmUgaXQgaXMgbm90IGEgY2xpZW50IGVycm9yIHRvIGFzayBmb3IgYSBtaXRpZ2F0 aW9uIHRoYXQgY29uZmxpY3RzIHdpdGggYW5vdGhlciBjbGllbnQgKGhvdyBjb3VsZCBpdCBldmVu IGtub3c/KS4gUmF0aGVyLCBpdCBpcyB1cCB0byB0aGUgc2VydmVyIHRvIHdlaWdoIHRoZSB2YXJp b3VzIHJlcXVlc3RzIGFuZCBhY3QgZm9yIHRoZSBvdmVyYWxsIGdvb2QuIEFzIHBhcmFncmFwaCAy IG9mIHNlY3Rpb24gMiBzYXlzLCDigJxET1RTIGlzIGFuIGFkdmlzb3J5IHByb3RvY29s4oCdLg0K SSBkb27igJl0IGV2ZW4gdGhpbmsgYW4gb3ZlcmxhcHBpbmcgcHJlZml4IHJhbmdlIGlzIGFuIGVy cm9yOyByYXRoZXIgYm90aCBjbGllbnRzIGhhdmUgaWRlbnRpZmllZCB0aGUgc2FtZSBhdHRhY2su DQoNClRoaXMgaXMgYSBmYWlyIGNvdW50ZXJwb2ludC4g4oCcQWN0IGZvciB0aGUgb3ZlcmFsbCBn b29k4oCdIGlzIHVuZm9ydHVuYXRlbHkgbm90IGNvbmNyZXRlIGVub3VnaCBmb3IgYSByZXF1aXJl bWVudC4gQ2FzZXMgbGlrZSB0d28gRE9UUyBjbGllbnRzIHJlcXVlc3RpbmcgbWl0aWdhdGlvbiBm b3IgdGhlIHNhbWUgcmVzb3VyY2VzIGFyZSBlYXN5IHRvIGhhbmRsZeKAlHRoZSBzZXJ2ZXIganVz dCBsZXRzIHRoZSBsb3NpbmcgY2xpZW50IGtub3cgbWl0aWdhdGlvbiBpcyBhbHJlYWR5IGluIHBy b2dyZXNz4oCUYnV0IHBhcnRpYWxseSBvdmVybGFwcGluZyBtaXRpZ2F0aW9uIHJlcXVlc3RzIGFy ZSBoYXJkZXIgdG8gaGFuZGxlLiBEb2VzIHRoZSBzZXJ2ZXIgbm90aWZ5IGVhY2ggY2xpZW50IHRo YXQgdGhlIGFjdHVhbCBtaXRpZ2F0aW9uIHNjb3BlIGlzIGxhcmdlciB0aGFuIG9yaWdpbmFsbHkg cmVxdWVzdGVkPw0KDQoNCjIuNSAgLSBEYXRhIG1vZGVsIHJlcXVpcmVtZW50cw0KSeKAmW0gbm90 IHN1cmUgd2hhdCB0byBtYWtlIG9mIHRoaXMgc2VjdGlvbi4gSSB0aGluayBJIGp1c3Qgd2FudCB0 byByZXZpZXcgdGhlIGRhdGEgbW9kZWwuDQoNCknigJltIGNvbWZvcnRhYmxlIGp1c3QgcmVtb3Zp bmcgdGhpcyBzZWN0aW9uLiBXaXRoIEZsZW1taW5nJ3MgZHJhZnQgYXBwYXJlbnRseSBldm9sdmlu ZyBtb3JlIHRvd2FyZCBpbmZvcm1hdGlvbiBtb2RlbCwgZG8gd2UgbmVlZCB0byBkaXNjdXNzIGRh dGEgbW9kZWwgYXQgYWxsIG91dHNpZGUgb2YgdGhlIHNvbHV0aW9ucyBkcmFmdHM/DQoNCmFuZHJl dw0K --_000_C02846B1344F344EB4FAA6FA7AF481F12B0C6CB9SZXEMA502MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueaz qOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBw dDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNw YWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLmFwcGxl LXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1l OiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjE2NTI1NjE5NzM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjE3MDA4MzE2NjAgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMg Njc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4t bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SGkgRGF2ZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBs ZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5Y+R5Lu25Lq6PHNwYW4gbGFu Zz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj4gRG90cyBbbWFpbHRvOmRvdHMtYm91 bmNlc0BpZXRmLm9yZ10NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTrlrovkvZMiPuS7o+ihqCA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMiPkRhdmUgRG9sc29uPGJy Pg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWu i+S9kyI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L 5L2TIj4gMjAxNzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTrlrovkvZMiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4yPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVO LVVTIj4yMjwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogNToyMDxicj4NCjwvc3Bhbj48 Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiPiBNb3J0ZW5zZW4sIEFuZHJldzxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJF Ti1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBkb3RzQGlldGYub3JnPGJyPg0K PC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyI+IFJlOiBbRG90c10gZmVlZGJhY2sgb24gZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVt ZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBmZWVsIHNvbWUgZGlzY29ubmVjdC4gTWF5YmUg Zm9sa3MgY291bGQgc2hhcmUgdGhlaXIgdmlld3Mgb24gdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXMgYSBkb3RzIHNpZ25h bC1jaGFubmVsIHJlcXVlc3QgYSBjb21tYW5kIG9yIGFuIGFkdmlzb3J5PyBJLmUuLCBNVVNUIHRo ZSBzZXJ2ZXIgbWl0aWdhdGUsIG9yIGRvZXMgdGhlIHNlcnZlciBzaW1wbHkgY29uc2lkZXIgaXQg YSBkYXRhLXBvaW50DQogaW4gdGhlIG9uZ29pbmcgYmF0dGxlPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W015IG9waW5pb246IGFkdmlzb3J5OyB0aGUgY2xpZW50 IGlzIG5vdCBhbHdheXMgcmlnaHQgb3IgdHJ1c3R3b3J0aHksIG9yIG1pdGlnYXRpb24gaXMgbm90 IGFsd2F5cyBhdmFpbGFibGVdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5bRnJhbmtdOiBJIHNoYXJlIHRoZSBzYW1lIGlkZWEgd2l0aCB5b3UuIEZvciBleGFtcGxl LCBpbiBPUC0wMDQsIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSBET1RTIHNlcnZlciBNVVNUIGNl YXNlIG1pdGlnYXRpb24gQVNBUCBpbiByZXNwb25zZSB0byBET1RTDQogY2xpZW504oCZcyB3aXRo ZHJhdyByZXF1ZXN0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklz IHRoZXJlIGEgcXVlc3Rpb24gb2Ygb3ZlcmxhcHBpbmcgcmVzb3VyY2VzPyBJLmUuLCBNYXkgZGlm ZmVyZW50IGNsaWVudHMgYXNrIGZvciBtaXRpZ2F0aW9uIG9mIHRoZSBzYW1lIHNjb3BlPyAoSWYg bm90LCBob3cgaXMgb3duZXJzaGlwDQogb2YgcmVzb3VyY2VzIGRldGVybWluZWQ/KTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W015IG9waW5pb246IHRoZXJlIGlz IG93bmVyc2hpcCwgc28gb3ZlcmxhcCBpcyBub3QgcG9zc2libGUuIE5lZ290aWF0ZWQgaW4gZGF0 YSBjaGFubmVsLl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltG cmFua106IGFncmVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklz IGEgc2Vzc2lvbiByZXF1aXJlZCAobGlrZSBEaWFtZXRlcik/IE9yIGNhbiBlYWNoIHJlcXVlc3Qg c3RhbmQgYWxvbmUgKGxpa2UgRE5TKT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPltNeSBvcGluaW9uOiBzZXNzaW9uIGlzIG5vdCByZXF1aXJlZCwgYW5kIGJ5IGl0 cyBjb21wbGV4aXR5IGhhcm1mdWwuXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+W0ZyYW5rXTogRE9UUyBhcmNoaXRlY3R1cmUgZHJhZnQgaGFzIHRoZSBkZWZpbml0 aW9uIGFib3V0IERPVFMgc2lnbmFsaW5nIHNlc3Npb24uIEkgdGhpbmsgaXTigJlzIHVzZWZ1bCBz aW5jZSBET1RTIHByb3RvY29sIGhhcyBzb21lIGtpbmRzIG9mIHRyYW5zYWN0aW9uDQogZmVhdHVy ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tRGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNb3J0ZW5zZW4sIEFuZHJldyBbPGEgaHJlZj0ibWFp bHRvOmFtb3J0ZW5zZW5AYXJib3IubmV0Ij5tYWlsdG86YW1vcnRlbnNlbkBhcmJvci5uZXQ8L2E+ XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkgMjAsIDIwMTcgMTozMSBQTTxi cj4NCjxiPlRvOjwvYj4gRGF2ZSBEb2xzb248YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0 bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogZmVlZGJhY2sgb24gZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50czxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcywgRGF2ZS4gVGhpcyBpcyB2ZXJ5IGhlbHBmdWwu IE15IChleHRyZW1lbHkgdGFyZHkpIHJlc3BvbnNlcyBhcmUgaW5saW5lLiBJ4oCZdmUgc25pcHBl ZCBtb3N0IG9mIHRoZSBtaW5vciByZXBocmFzaW5nIHN1Z2dlc3Rpb25zLiBBbGwgY29tbWVudHMg YXJlIG1lIHNwZWFraW5nIGZvciBteXNlbGYsIG5vdCBuZWNlc3NhcmlseSBmb3IgdGhlIG90aGVy IHJlcXVpcmVtZW50cw0KIGRyYWZ0IGVkaXRvcnMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPknigJl2ZSBvcGVuZWQgaXNzdWVzIG9uIGdpdGh1YiBmb3IgbW9zdCBv ZiB0aGVzZSBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+T24gTm92IDI2LCAyMDE2LCBhdCA5OjMxIFBNLCBEYXZlIERvbHNv biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tIj5kZG9sc29uQHNhbmR2 aW5lLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCmc25pcC4uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjEuMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPuKApnNuaXAuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gb3Ig4oCcY291bnRlcm1lYXN1cmXigJ0sIHRoaXMgc291bmRzIGxp a2Ugb25seSBwYWNrZXQgZmlsdGVyaW5nLiBJcyB0aGF0IGFjY3VyYXRlIGFuZCBjb21wbGV0ZT8g Q291bGQgdGFyLXBpdCBvciByb3V0aW5nIGNoYW5nZXMgYmUgaW5jbHVkZWQgaW4gY291bnRlcm1l YXN1cmVzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGRvbuKAmXQgd2FudCB0aGUgZG9jdW1lbnQgdG8gcmVz dHJpY3QgdGhlIGRlZmluaXRpb24gb2YgY291bnRlcm1lYXN1cmUsIGJ1dCBJ4oCZbSBhbHNvIG5v dCBrZWVuIHRvIGVuc2hyaW5lIHNwZWNpZmljIHR5cGVzIG9mIGNvdW50ZXJtZWFzdXJlLCBlaXRo ZXIuIEnigJlsbCByZXZpc2UgdG8gbWFrZSBpdCBjbGVhcmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPklzIOKAnHNpZ25hbCBjaGFubmVs4oCdIGludGVuZGVkIHRvIGJlIHRoZSBzYW1l IHRoaW5nIGFzIHRoZSDigJxzZXNzaW9u4oCdIG1lbnRpb25lZCBpbiB0aGUgYXJjaGl0ZWN0dXJl PyBJIHRoaW5rIHNvLCBhbmQgdGVybWlub2xvZ3kgc2hvdWxkIGJlIG1hZGUgY29uc2lzdGVudCBi ZXR3ZWVuDQogdGhlIGRvY3MuIElmIG5vdCwgSSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIGRpZmZl cmVuY2UgYmV0d2VlbiBjaGFubmVsIGFuZCBzZXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U3BlYWtpbmcgZm9yIG15c2VsZiwgdGhlIOKAnGNo YW5uZWzigJ0gZGlzdGluY3Rpb24gaXMgbWVhbnQgdG8gZGlzdGluZ3Vpc2ggdGhlIHVucmVsaWFi bGUsIGxpZ2h0d2VpZ2h0IFNPUyBtZXNzYWdlcyB0byBiZSB1c2VkIHdoZW4gdW5kZXIgYXR0YWNr IGZyb20gdGhlIHJlbGlhYmxlIG1lc3NhZ2luZyByZXF1aXJlZCB0byBlLmcuIG1hbmFnZSBmaWx0 ZXJzIGFuZCByZXNvdXJjZSBhbGlhc2VzLg0KIFRoZSDigJxzaWduYWxpbmcgc2Vzc2lvbuKAnSBp biB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGlzIGFjdGl2ZSBtZXNzYWdpbmcgYmV0d2VlbiBE T1RTIGFnZW50cyBvdmVyIHRoZSBzaWduYWwgY2hhbm5lbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlNob3VsZCDigJxGaWx0ZXLigJ0gYmUgbGltaXRlZCB0byB0aGUgdHdvIGFjdGlv bnMgb2YgcmF0ZS1saW1pdGluZyBvciBkaXNjYXJkaW5nPyZuYnNwOyBJcyBmaWx0ZXIgcmVhbGx5 IGludGVuZGVkIHRvIGluY2x1ZGUgYWN0aW9uLCBvciBqdXN0IHRoZSBtYXRjaCBjcml0ZXJpYT88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkl0IHNvdW5kcyBsaWtlIHlvdeKAmXJlIHJlYWxseSBhc2tpbmcgd2hldGhlciB3ZSBz aG91bGQgbGVhdmUgdGhlIGRlZmluaXRpb24gb2Yg4oCcZmlsdGVyaW5n4oCdIHVwIHRvIHRoZSBE T1RTIHNlcnZlci9taXRpZ2F0b3IuIEkgd29ycnkgdGhhdCBsZWF2aW5nIOKAnGZpbHRlcmluZ+KA nSBsb29zZWx5IGRlZmluZWQgd2lsbCBsZWFkIHRvIGNvbmZ1c2lvbiBmdXJ0aGVyIGRvd24gdGhl IGxpbmUuDQogSSB0aGluayB3ZSBuZWVkIGV4cGxpY2l0IGFjdGlvbnM6IGRpc2NhcmQgaXMgdmVy eSBkaWZmZXJlbnQgZnJvbSByYXRlLWxpbWl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+QXMgSSBzZWUgaXQsIGZpbHRlcmluZyBpcyBkaXN0aW5jdCBm cm9tIHZlbmRvciBleHRlbnNpb25zIHdoaWNoIG1pZ2h0IGluY2x1ZGUgY291bnRlcm1lYXN1cmUg c3BlY2lmaWNzLiBJIGRvbuKAmXQgdGhpbmsgRE9UUyBpcyBhIGdlbmVyYWwgcHVycG9zZSBpbnRl cmZhY2UgZm9yIGNvdW50ZXJtZWFzdXJlIGNvbmZpZ3VyYXRpb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ U2ltaWxhcmx5IGZvciDigJxCbGFja2xpc3TigJ06IGlzIGJsb2NrIHRoZSBvbmx5IHZhbGlkIGFj dGlvbiBmb3IgYmxhY2stbGlzdGVkIGFkZHJlc3Nlcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlllcywgdGhhdOKAmXMgdGhl IGRpc3Rpbmd1aXNoaW5nIGNoYXJhY3RlcmlzdGljIG9mIGEgYmxhY2tsaXN0ZWQgc291cmNlLiBB IHdoaXRlbGlzdGVkIHNvdXJjZSBpcyBhbHdheXMgYWxsb3dlZCB0byBwYXNzLiBUaGUgRE9UUyBj bGllbnQgaGFzIGZ1bGwgY29udHJvbCBvdmVyIHRoZSBibGFjay0vd2hpdGUtbGlzdHMsIHRob3Vn aCB0aGUgc2NvcGUgaXMgcmVzdHJpY3RlZCBieSB0aGUNCiBET1RTIHNlcnZlciB0byBwcmVmaXhl cy9yZXNvdXJjZXMgYmVsb25naW5nIHRvIHRoZSBET1RTIGNsaWVudC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+VGhlIHNlY29uZCBwYXJhZ3JhcGggc2F5cyDigJxET1RTIGlzIGFuIGFk dmlzb3J5IHByb3RvY29sLuKAnSBJIHRob3VnaHQgdGhpcyBtaWdodCBtZWFuIHRoYXQgKGEpIGEg Y2xpZW504oCZcyByZXF1ZXN0IGZvciBhaWQgbWF5IGJlIGlnbm9yZWQgYW5kIChiKSBtaXRpZ2F0 aW9uIG1heQ0KIGJlIGRvbmUgcHJpb3IgdG8gcmVxdWVzdCBvciBhZnRlciB3aXRoZHJhd2FsLiBX b3VsZCB0aGF0IGlkZWEgYmUgYWNjdXJhdGU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHRoaW5rIChhKSBpcyBjb3JyZWN0 LCB0aG91Z2ggaWdub3JpbmcgYSByZXF1ZXN0IHdpdGhvdXQgcHJvdmlkaW5nIGEgcmVhc29uIHdo ZW4gYSBzZXJ2aWNlIGFncmVlbWVudCBpcyBpbiBwbGFjZSBzZWVtcyBsaWtlIGEgcG9vciB3YXkg dG8gbWFuYWdlIGEgc2VydmljZS4gSW4gZ2VuZXJhbCBhIERPVFMgcmVxdWVzdCBmb3IgbWl0aWdh dGlvbiBzaG91bGQgcmVzdWx0IGluIG1pdGlnYXRpb24sDQogYXNzdW1pbmcgYnVzaW5lc3Mgb3Ig c2VydmljZSBhZ3JlZW1lbnRzIGFyZSBpbiBwbGFjZSwgYnV0IG1pdGlnYXRpbmcgdGhlIGF0dGFj ayBtaWdodCBpbnZvbHZlIG1vcmUgdGhhbiBqdXN0IGEmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIGNhbGxpbmcgRE9UUyDigJxhZHZpc29y eeKAnSBJIHdhcyB0cnlpbmcgdG8gZW1waGFzaXplIHR3byBwb2ludHM6IHRoZSBkaWZmaWN1bHR5 IG9mIG1haW50YWluaW5nIHJlbGlhYmxlIG1lc3NhZ2luZyB1bmRlciBhdHRhY2sgY29uZGl0aW9u cyAod2l0aCB0aGUgY29yb2xsYXJ5IHRoYXQgYSBET1RTIHNlcnZlciBtYXkgbm90IGJlIGFibGUg dG8gaGVscCBldmVuIGlmIGEgcmVxdWVzdA0KIGdldHMgdGhyb3VnaCk7IGFuZCB0aGUgZmFjdCB0 aGF0IERPVFMgaXMgbm90IGEgZ2VuZXJhbCBwdXJwb3NlIG1pdGlnYXRpb24gQVBJLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TWF5YmUgSSBzaG91bGQg Y2xhcmlmeSB0aGF0IGZ1cnRoZXIuIEkgYmVsaWV2ZSB0aGUgRE9UUyAqc2lnbmFsIGNoYW5uZWwq IGlzIG5vdCBhIGdlbmVyYWwgcHVycG9zZSBtaXRpZ2F0aW9uIEFQSS4gVGhlIERPVFMgZGF0YSBj aGFubmVsIGNvdWxkIGV2b2x2ZSBpbnRvIHRoYXQgYXMgYSBzb3J0IG9mIERPVFMgY29udHJvbCBw cm90b2NvbCwgaW4gd2hpY2ggdGhlIGltcGFjdCBvZg0KIGFuIGF0dGFjayBvbiB0aGUgY29tbXVu aWNhdGlvbiBsYXllciBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyIGlzIG5vdCBhIGNvbmNlcm4u PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPihNeSB0aGlua2luZyBpcyB0aGF0 IGEgRE9UUyBzZXJ2ZXIgbWF5IGtub3cgYmV0dGVyIHRoYW4gdGhlIGNsaWVudCBiYXNlZCBvbiBh IHdpZGVyIHNvdXJjZSBvZiB0ZWxlbWV0cnkuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BZ3JlZWQuIE9uY2UgYSBtaXRpZ2F0b3IgYmVn aW5zIGZpbHRlcmluZyB0cmFmZmljIGJvdW5kIGZvciB0aGUgZG9tYWluIG9mIHRoZSBET1RTIGNs aWVudCwgdGhlIERPVFMgY2xpZW504oCZcyB2aWV3IGludG8gdGhlIGF0dGFjayBpcyBza2V3ZWQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0gaW4gR0VOLTAw NCwgY29uc2lkZXIgcGlja2luZyBhIHNwZWNpZmljIE1UVSBzaXplLCBsaWtlIDUwMCBieXRlcywg YmVjYXVzZSBvdGhlcndpc2UgdGhlcmUgaXMgbm8gd2F5IHRvIGp1ZGdlIGlmIHRoZSBwcm90b2Nv bCBtZWV0cyByZXF1aXJlbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIGhhcyBiZWNvbWUgbW9yZSBpbXBvcnRh bnQgc2luY2UgeW91IHN1Z2dlc3RlZCBpdCwgaW4gbGlnaHQgb2YgdGhlIHJlY2VudCB0aHJlYWQg b24gdGVsZW1ldHJ5LiBkcmFmdC1yZWRkeS1kb3RzLXNpZ25hbC1jaGFubmVsIGlzIHN1Z2dlc3Rp bmcgNTAwIGJ5dGVzIGluIHRoZSBldmVudCB0aGUgY2xpZW50IGNhbuKAmXQgZGlzY2VybiBwYXRo IE1UVS4gSeKAmW0gY29tZm9ydGFibGUNCiB3aXRoIHRleHQgdG8gdGhlIGVmZmVjdCB0aGF0IGNs aWVudHMgU0hPVUxEIHRyeSB0byBkZXRlcm1pbmUgcGF0aCBNVFUsIGFuZCBmYWxsIGJhY2sgdG8g NTAwIGJ5dGVzIGlmIGl0IGNhbuKAmXQgYmUgZGlzY292ZXJlZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SW4gMi4yLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPuKApiBzbmlwIC4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T1AtMDA0OiBUaGlzIHJlcXVp cmVtZW50IGhhcyBzZXZlcmFsIGlkZWFzIGluIGl0LCB3aGljaCBJIHRoaW5rIHNob3VsZCBiZSBi cm9rZW4gaW50byBtdWx0aXBsZSByZXF1aXJlbWVudHM6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPihhKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5UaGUNCiBpZGVhIHRoYXQgbWVzc2FnZXMgYmUgYWNrbm93bGVkZ2Vk IHdpdGggYSBzdGF0dXMgY29kZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+LTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5CdXQNCiBpdCBpcyB1bmNsZWFy IHdoZXRoZXIgdGhlIHN0YXR1cyBtdXN0IGJlIGRlbGl2ZXJlZCBpbW1lZGlhdGVseSwgb3IgcmVw b3J0ZWQgbGF0ZXIuIEkgZXhwZWN0IHRoZXJlIGNvdWxkIGJlIGFuIGltbWVkaWF0ZSDigJxJIGhl YXIgeW91ciByZXF1ZXN04oCdLCB3aGljaCBkb2VzbuKAmXQgbmVjZXNzYXJpbHkgbWVhbiBhbnl0 aGluZyBjYW4gYmUgZG9uZS4gVGhlcmUgc2hvdWxkIGJlIGEgd2F5IGZvciB0aGUgY2xpZW50IHRv IGxhdGVyIGFzaywg4oCcaG93IGFyZQ0KIHlvdSBkb2luZyB3aXRoIHRoYXQgcmVxdWVzdD/igJ08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkkgbWVhbnQgdGhpcyB0byBiZSBsZXNzIHJlc3RyaWN0aXZlIHRoYW4gd2hhdCB5b3Xi gJl2ZSBkZXNjcmliZWQuIFRoZXJlIHNob3VsZCBiZSBzb21lIHdheSBmb3IgdGhlIERPVFMgY2xp ZW50IHRvIGRldGVjdCB0aGF0IGl0cyBtZXNzYWdlcyBhcmUgYmVpbmcgcmVjZWl2ZWQvcHJvY2Vz c2VkIG9yIGxvc3QsIGFuZCB0aGUgc2FtZSBpcyB0cnVlIGZvciB0aGUgRE9UUyBzZXJ2ZXIuDQog VGhhdCBkb2VzbuKAmXQgaGF2ZSB0byBtZWFuIGFuIEhUVFAtbGlrZSBtb2RlbC4gRm9yIGV4YW1w bGUsIGluIHRoZSBwcm90b2NvbCBkcmFmdCBOaWsgVGVhZ3VlIGFuZCBJIGhhdmUgcHV0IHRvZ2V0 aGVyLCB0aGUgc2lnbmFsIGNoYW5uZWwgaXMgb25nb2luZywgcGVyaW9kaWMgY29tbXVuaWNhdGlv biBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyLiBUaGUgY2xpZW50IGRvZXMgbm90IG5lZWQgdG8g c2VuZCBhIHNlcGFyYXRlIG1lc3NhZ2UgdG8gYXNrDQogYWJvdXQgcmVxdWVzdCBzdGF0dXMsIHNp bmNlIHRoZSBET1RTIHNlcnZlciB3aWxsIHNlbmQgaXQgaW4gYSBmZXcgc2Vjb25kcyBhbnl3YXku PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPihiKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5XaGV0aGVyDQogdGhlIHNlcnZlciBNVVNUIGRvIGFzIGl0IGlz IHRvbGQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDo1NC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0x OC4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi08L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T24NCiB0aGlzIHBvaW50LCBJIHRoaW5rIHRoZSDigJxN VVNUIGNlYXNlIG1pdGlnYXRpb24gYWN0aXZpdHnigJ0gaXMgd3JvbmcsIHNpbmNlIHRoZSBzZXJ2 ZXIgbWF5IGhhdmUgb3RoZXIgZXZpZGVuY2Ugb3Igb3RoZXIgY2xpZW50cyByZXF1ZXN0aW5nIHRo ZSBtaXRpZ2F0aW9uLiBUaGlzIGlzIGFja25vd2xlZGdlZCBieSB0aGUg4oCcbWF5IGNvbnRpbnVl IG1pdGlnYXRpbmfigJ0gbGF0ZXIgaW4gdGhlIHBhcmFncmFwaC4gU28gYXQgbWluaW11bSB0aGUg TVVTVCBpcw0KIHRvbyBzdHJvbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5UaGUgZnVsbCBwaHJhc2UgaXMg4oCcTVVTVCBjZWFzZSBtaXRpZ2F0aW9u IGFzIHF1aWNrbHkgYXMgcG9zc2libGXigJ0sIGJ5IHdoaWNoIEkgbWVhbnQgdG8gZXhwcmVzcyB0 aGUgaW1wb3J0YW5jZSBvZiBhbGxvd2luZyB0aGUgc2VydmVyIHRvIG1haW50YWluIHRoZSBtaXRp Z2F0aW9uIGZvciBhIHNob3J0IHBlcmlvZCB0byByZWR1Y2UgdGhlIGltcGFjdCBvZiBhIERPVFMg Y2xpZW50DQogcmFwaWRseSB0b2dnbGluZyBtaXRpZ2F0aW9uLiBJdCBzb3VuZHMgbGlrZSB0aGUg ZHVyYXRpb24gb2YgdGhhdCBzaG9ydCBwZXJpb2QgbmVlZHMgdG8gYmUgZGVmaW5lZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgdGhpbmsgdHdvIHRo aW5ncyBzaG91bGQgYmUgY2xlYXIgaW4gdGhlIGZpbmFsIHRleHQ6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4xKSBUaGUgRE9UUyBjbGllbnQgY2FuIGNl YXNlIHRvIGJlIHRoZSBjYXVzZSBmb3IgYSBtaXRpZ2F0aW9uIGF0IGFueSB0aW1lIGJ5IHNlbmRp bmcgYSBtaXRpZ2F0aW9uIHRlcm1pbmF0aW9uIHJlcXVlc3QsIGJ1dCBjYW5ub3QgY29uc2lkZXIg YSBtaXRpZ2F0aW9uIHRlcm1pbmF0ZWQgdW50aWwgY29uZmlybWF0aW9uIGZyb20gdGhlIHNlcnZl ci4gKE1pdGlnYXRpb24gbGlmZXRpbWUNCiBpcyB0aGVyZSB0byBoYW5kbGUgdGhlIGNhc2VzIHdo ZXJlIHRoZSBzZXJ2ZXLigJlzIGNvbmZpcm1hdGlvbiBpcyBub3QgZGVsaXZlcmVkLik8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjIpJm5ic3A7T25jZSBh IERPVFMgY2xpZW50IHRlbGxzIGEgRE9UUyBzZXJ2ZXIgdG8gc3RvcCBtaXRpZ2F0aW5nLCB0aGUg RE9UUyBjbGllbnQgaXMgbm8gbG9uZ2VyIHJlc3BvbnNpYmxlIGZvciB0aGUgbWl0aWdhdGlvbi4g VGhlIERPVFMgc2VydmVyL21pdGlnYXRvciBjYW4gY29udGludWUgbWl0aWdhdGluZyBhcmJpdHJh cmlseSwgYnV0IGFmdGVyIHRoZSBtaXRpZ2F0aW9uIHRlcm1pbmF0aW9uDQogZ3JhY2UgcGVyaW9k IGVsYXBzZXMgYW5kIHRoZSBjbGllbnQgaGFzbuKAmXQgcmVuZXdlZCBhIHJlcXVlc3QgZm9yIG1p dGlnYXRpb24sIGFsbCByZXNwb25zaWJpbGl0eSBmb3IgdGhlIG1pdGlnYXRpb24gaXMgYm9ybmUg YnkgdGhlIERPVFMgc2VydmVyIGRvbWFpbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5P UC0wMDYuIEkgd291bGQgbGlrZSB0byBzZWUgYWxsIG9mIHNwZWNpZmljIHNjb3BlcyBwcmVjaXNl bHkgZGVmaW5lZCBhcyByZXF1aXJlZCBvciBvcHRpb25hbCwgYnV0IG5vdCBhcyBleGFtcGxlcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlllcywgdGhp cyBpcyBhIGdvb2Qgc3VnZ2VzdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BbHNv LCBJ4oCZbSBub3QgY2xlYXIgb24gd2hhdCBETlMgbmFtZSBmaWx0ZXJpbmcgbWVhbnM6IGlzIHRo aXMgZm9yIGZpbHRlcmluZyBETlMgcGFja2V0cywgb3IgZm9yIGxvb2tpbmcgdXAgdGhlIG5hbWUg YW5kIGZpbHRlcmluZyB0aGUgY29ycmVzcG9uZGluZyBhZGRyZXNzZXM/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JdOKAmXMgbm90IEROUyBuYW1lIGZp bHRlcmluZywgYnV0IGluZGljYXRpbmcgd2hpY2ggRlFETnMgbmVlZCBtaXRpZ2F0aW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPk9QLTAwOC4gSSBob3BlIHRoZXJlIGlzbuKAmXQgZ29pbmcgdG8g YmUgYW4gYXJndW1lbnQgYWJvdXQgdGhpcywgYnV04oCmIEkgYmVsaWV2ZSBpdCBpcyBub3QgYSBj bGllbnQgZXJyb3IgdG8gYXNrIGZvciBhIG1pdGlnYXRpb24gdGhhdCBjb25mbGljdHMgd2l0aCBh bm90aGVyIGNsaWVudA0KIChob3cgY291bGQgaXQgZXZlbiBrbm93PykuJm5ic3A7UmF0aGVyLCBp dCBpcyB1cCB0byB0aGUgc2VydmVyIHRvIHdlaWdoIHRoZSB2YXJpb3VzIHJlcXVlc3RzIGFuZCBh Y3QgZm9yIHRoZSBvdmVyYWxsIGdvb2QuIEFzIHBhcmFncmFwaCAyIG9mIHNlY3Rpb24gMiBzYXlz LCDigJxET1RTIGlzIGFuIGFkdmlzb3J5IHByb3RvY29s4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBkb27igJl0IGV2ZW4gdGhpbmsgYW4gb3Zlcmxh cHBpbmcgcHJlZml4IHJhbmdlIGlzIGFuIGVycm9yOyByYXRoZXIgYm90aCBjbGllbnRzIGhhdmUg aWRlbnRpZmllZCB0aGUgc2FtZSBhdHRhY2suPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIGlzIGEgZmFpciBjb3VudGVy cG9pbnQuIOKAnEFjdCBmb3IgdGhlIG92ZXJhbGwgZ29vZOKAnSBpcyB1bmZvcnR1bmF0ZWx5IG5v dCBjb25jcmV0ZSBlbm91Z2ggZm9yIGEgcmVxdWlyZW1lbnQuIENhc2VzIGxpa2UgdHdvIERPVFMg Y2xpZW50cyByZXF1ZXN0aW5nIG1pdGlnYXRpb24gZm9yIHRoZSBzYW1lIHJlc291cmNlcyBhcmUg ZWFzeSB0byBoYW5kbGXigJR0aGUgc2VydmVyIGp1c3QNCiBsZXRzIHRoZSBsb3NpbmcgY2xpZW50 IGtub3cgbWl0aWdhdGlvbiBpcyBhbHJlYWR5IGluIHByb2dyZXNz4oCUYnV0IHBhcnRpYWxseSBv dmVybGFwcGluZyBtaXRpZ2F0aW9uIHJlcXVlc3RzIGFyZSBoYXJkZXIgdG8gaGFuZGxlLiBEb2Vz IHRoZSBzZXJ2ZXIgbm90aWZ5IGVhY2ggY2xpZW50IHRoYXQgdGhlIGFjdHVhbCBtaXRpZ2F0aW9u IHNjb3BlIGlzIGxhcmdlciB0aGFuIG9yaWdpbmFsbHkgcmVxdWVzdGVkPyZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yLjU8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDsgLSBEYXRhIG1vZGVsIHJlcXVpcmVtZW50czwvc3Bh bj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5J4oCZbSBub3Qg c3VyZSB3aGF0IHRvIG1ha2Ugb2YgdGhpcyBzZWN0aW9uLiBJIHRoaW5rIEkganVzdCB3YW50IHRv IHJldmlldyB0aGUgZGF0YSBtb2RlbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPknigJltIGNvbWZvcnRhYmxlIGp1c3QgcmVt b3ZpbmcgdGhpcyBzZWN0aW9uLiBXaXRoIEZsZW1taW5nJ3MgZHJhZnQgYXBwYXJlbnRseSBldm9s dmluZyBtb3JlIHRvd2FyZCBpbmZvcm1hdGlvbiBtb2RlbCwgZG8gd2UgbmVlZCB0byBkaXNjdXNz IGRhdGEgbW9kZWwgYXQgYWxsIG91dHNpZGUgb2YgdGhlIHNvbHV0aW9ucyBkcmFmdHM/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5hbmRyZXc8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_C02846B1344F344EB4FAA6FA7AF481F12B0C6CB9SZXEMA502MBSchi_-- From nobody Wed Feb 22 05:16:28 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC63129868 for ; Wed, 22 Feb 2017 05:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nasa.gov 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 IHU4nralSpgn for ; Wed, 22 Feb 2017 05:16:24 -0800 (PST) Received: from ndjsvnpf101.ndc.nasa.gov (NDJSVNPF101.ndc.nasa.gov [198.117.1.151]) (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 92825129863 for ; Wed, 22 Feb 2017 05:16:24 -0800 (PST) X-Comment: SPF check N/A for local connections - client-ip=198.117.1.197; helo=ndjsppt103.ndc.nasa.gov; envelope-from=gilbert.j.clark@nasa.gov; receiver=dots@ietf.org DKIM-Filter: OpenDKIM Filter v2.11.0 ndjsvnpf101.ndc.nasa.gov A07314008467 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nasa.gov; s=letsgomars; t=1487769383; bh=dMYGg0x+Z/uz1O3HpflSc5PYKVPZSarYVgqgbSPYHZ8=; h=From:To:Subject:Date:References:In-Reply-To:From; b=Nn84lwvRM1fOpcpEbO8sBRVSoLy5qV0+EaObmYtxMwv05TdQXA5VLev0YAepltPQe 6EuFeAwhkcuGzP3khacHzZo1Dfr9ufwNWuieWMbW1ZSYzEtI45Hu9Z+tDkvJ1FcPTa LvfTgHHOTW7BYfy5TOqwsfotv+Hn60siOybUOqDjmbD+LEsxz2AwvI6nVaKHJpblDl plDrvovclttZ4fBxQXnGYkZ9M6/fx9mslM8cMvBxA/xwj+1WVIU5qhbH5+on5fys8p +siM4rfMxXBjetUSs1bHzhpeW6aRIipzl6QAcLbL84UHbkmnpH6zihl1JsY4+clFIu gkothocJevrTA== Received: from ndjsppt103.ndc.nasa.gov (ndjsppt103.ndc.nasa.gov [198.117.1.197]) by ndjsvnpf101.ndc.nasa.gov (Postfix) with ESMTP id A07314008467; Wed, 22 Feb 2017 07:16:23 -0600 (CST) Received: from pps.filterd (ndjsppt103.ndc.nasa.gov [127.0.0.1]) by ndjsppt103.ndc.nasa.gov (8.16.0.20/8.16.0.20) with SMTP id v1MDBrTZ032506; Wed, 22 Feb 2017 07:16:23 -0600 Received: from ndjscht108.ndc.nasa.gov (ndjscht108-pub.ndc.nasa.gov [198.117.1.208]) by ndjsppt103.ndc.nasa.gov with ESMTP id 28s5rkh130-1; Wed, 22 Feb 2017 07:16:23 -0600 Received: from NDJSMBX201.ndc.nasa.gov ([169.254.4.228]) by NDJSCHT108.ndc.nasa.gov ([198.117.1.178]) with mapi id 14.03.0319.002; Wed, 22 Feb 2017 07:16:22 -0600 From: "Clark, Gilbert J. (GRC-LCA0)" To: "Tirumaleswar Reddy (tireddy)" , "Roman D. Danyliw" , "Mortensen, Andrew" , "dots@ietf.org" Thread-Topic: use of restconf for the data channel? Thread-Index: AQHShUvelq2Fax0X1U+DAQQ/dairhqFqKpDAgApPffGAADEigIAAW2c4 Date: Wed, 22 Feb 2017 13:16:21 +0000 Message-ID: <5AE9F2D3F5799545818A4795DA145E7103BC595B@NDJSMBX201.ndc.nasa.gov> References: <6AE56175-DBE7-4CD9-BA4E-5DCA88E901D8@arbor.net>, <359EC4B99E040048A7131E0F4E113AFC0104F01D17@marathon> <5AE9F2D3F5799545818A4795DA145E7103BC588B@NDJSMBX201.ndc.nasa.gov>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.118.191.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-22_08:, , signatures=0 Archived-At: Subject: Re: [Dots] use of restconf for the data channel? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 13:16:26 -0000 Oh, neat: didn't realize RESTCONF graduated to an RFC. Looks like it was p= retty recent, but that is still a good thing and does alleviate one of my c= oncerns to an extent :)=0A= =0A= "But for DOTS data channel RESTCONF is suitable"=0A= =0A= Why is RESTCONF suitable for the data channel? Why was RESTCONF, specifica= lly, chosen? What does it offer that might justify the implementation burd= en that it brings, and would therefore make it a compelling choice when com= pared to just building and documenting a REST interface? If there are reas= ons to use it that justify the complexity, then okay. I haven't seen these= elements documented on the mailing list, though (apologies if I missed the= m?), and I also didn't see them documented anywhere in the current draft. = =0A= =0A= With this in mind, including text to explain what benefits RESTCONF offers = and explains *why* its adoption is important to the data channel would go a= long way to alleviate the concerns I have in this instance :)=0A= =0A= I would also point out that the data-channel-04 draft still references the = restconf draft instead of the RFC [1] - that's something that should probab= ly be corrected for a future revision of the draft, if it hasn't already.= =0A= =0A= Cheers,=0A= Gilbert=0A= =0A= [1] [I-D.ietf-netconf-restconf]=0A= Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF=0A= Protocol", draft-ietf-netconf-restconf-18 (work in=0A= progress), October 2016.=0A= ________________________________________=0A= From: Tirumaleswar Reddy (tireddy) [tireddy@cisco.com]=0A= Sent: Wednesday, February 22, 2017 2:17 AM=0A= To: Clark, Gilbert J. (GRC-LCA0); Roman D. Danyliw; Mortensen, Andrew; dots= @ietf.org=0A= Subject: RE: use of restconf for the data channel?=0A= =0A= NETCONF and RESTCONF are not both suitable for DOTS signal channel.=0A= But for DOTS data channel RESTCONF is suitable and RESTCONF is already an R= FC https://tools.ietf.org/html/rfc8040.=0A= Various products in the market already use RESTCONF (e.g. confd 6.3 http://= www.tail-f.com/management-agent/)=0A= =0A= -Tiru=0A= =0A= > -----Original Message-----=0A= > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Clark, Gilbert J. = (GRC-=0A= > LCA0)=0A= > Sent: Wednesday, February 22, 2017 11:26 AM=0A= > To: Roman D. Danyliw ; Mortensen, Andrew=0A= > ; dots@ietf.org=0A= > Subject: Re: [Dots] use of restconf for the data channel?=0A= >=0A= > Hi:=0A= >=0A= > My strongest objection to both NETCONF and RESTCONF were in the context= =0A= > of their consideration for use in the signal channel.=0A= >=0A= > I wouldn't personally vote to see NETCONF, specifically, used in either c= hannel.=0A= > NETCONF can involve substantial implementation complexity to support=0A= > capabilities that, in the case of DOTS, seem to me to be of marginal util= ity at=0A= > best.=0A= >=0A= > The use of RESTCONF seems a little more reasonable to me here since many = of=0A= > those implementation requirements are relaxed.=0A= >=0A= > I will note that adoption of RESTCONF will inflict a 100+ page not-yet-RF= C as=0A= > (additional) required reading for anyone who wishes to implement a DOTS= =0A= > data channel from scratch. Also, note that the use of RESTCONF would=0A= > introduce a dependency on something that is still in development, and tha= t=0A= > therefore most likely hasn't yet been very well tested and / or may be su= bject=0A= > to change.=0A= >=0A= > Just offering some clarification on my original opinion(s), for what that= 's=0A= > worth.=0A= >=0A= > -Gilbert=0A= > _________________________________=0A= > From: Dots [dots-bounces@ietf.org] on behalf of Roman D. Danyliw=0A= > [rdd@cert.org]=0A= > Sent: Wednesday, February 15, 2017 9:51 AM=0A= > To: Mortensen, Andrew; dots@ietf.org=0A= > Subject: Re: [Dots] use of restconf for the data channel?=0A= >=0A= > > Subject: [Dots] use of restconf for the data channel?=0A= > > [snip]=0A= > >=0A= > > Since RESTCONF is now a concrete proposal, it seems worthwhile=0A= > > continuing the debate ahead of the interim meeting. Are there=0A= > > specific concerns in the WG regarding the use ...=0A= >=0A= > This discussion topic is one we need to resolve. We can start here on th= e list=0A= > but I'll also add a slot to the interim meeting to continue the conversat= ion.=0A= >=0A= > Roman=0A= >=0A= > _______________________________________________=0A= > Dots mailing list=0A= > Dots@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/dots=0A= >=0A= > _______________________________________________=0A= > Dots mailing list=0A= > Dots@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/dots=0A= From nobody Wed Feb 22 05:59:26 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F53012968F for ; Wed, 22 Feb 2017 05:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=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 fV54eecPj3Mx for ; Wed, 22 Feb 2017 05:59:18 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 60E3D129863 for ; Wed, 22 Feb 2017 05:59:18 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.124.243.128; From: "Susan Hares" To: "'Clark, Gilbert J. \(GRC-LCA0\)'" , "'Tirumaleswar Reddy \(tireddy\)'" , "'Roman D. Danyliw'" , "'Mortensen, Andrew'" , References: <6AE56175-DBE7-4CD9-BA4E-5DCA88E901D8@arbor.net>, <359EC4B99E040048A7131E0F4E113AFC0104F01D17@marathon> <5AE9F2D3F5799545818A4795DA145E7103BC588B@NDJSMBX201.ndc.nasa.gov>, <5AE9F2D3F5799545818A4795DA145E7103BC595B@NDJSMBX201.ndc.nasa.gov> In-Reply-To: <5AE9F2D3F5799545818A4795DA145E7103BC595B@NDJSMBX201.ndc.nasa.gov> Date: Wed, 22 Feb 2017 08:54:34 -0500 Message-ID: <00d501d28d13$3b0564f0$b1102ed0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJmFW6DDzAmzfgGvVNa0u+cVn2h/AKLxGeiAr6R73ABz+0ANAEMF6looAzAN6A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Dots] use of restconf for the data channel? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 13:59:20 -0000 Gilbert: Can you provide a bit more unpacking of the message here? NETCONF or RESTCONF + Yang data models was the initial suggestion to allow stable protocol plus the ability to rapidly change data models that form the content of the bulk data channel. I sent a longish message to the list around IETF 97 since you have questions, I will reformat this message as an internet-draft and send it to the list this week. The Data channel requirements are: reliable transport, data privacy and integrity, resource configuration (described in OP-07), data-004 black-white list management. These are the basic design requirements for NETCONF/RESTCONF functionality. The specific resources, black-list, or white-list management can be data models. There are four parts to NETCONF/RESTCONF protocol: Content -- data models Messaging method (NETCONF: edit-config, get-config, RESTCONF/ PUT, GET) + new Event and publication/subscription streams information Messaging protocol (rpc/rpc-reply / secure http) ============= Secure transport (TLS with X.509 certifications, DTLS + add ons) Transport (TCP or UDP) Since all of the requirements for the secure transport are the same (peer mutual authentication, message confidentiality, integrity and authenticity, and message replay protection are the same as the DOTS requirements. You may wish to change the messaging protocol (rpc/rpc-reply or RESTCONF http) to protobufs. If so, I suggest you make that suggestion to the I2NSF WG that will include it in its general changes suggested to NETCONF WG and I2RS WG . The WGs would consider protobufs if there is a real use case. If you want to change the message method to edit configuration, what your alternative would be? If you are read, write, or updating you configuration or white lists, this is what these protocols are built for. The yang data models are tailored for user-readability. If you want to change the new event publication and subscription, exactly what do you want to change. As I will rapidly turn around a draft to answer your questions, please let me know exactly what your concerns are. If you are looking for the a secure shim layer, Content -- data models Messaging method (NETCONF: edit-config, get-config, RESTCONF/ PUT, GET) + new Event and publication/subscription streams information Messaging protocol (rpc/rpc-reply / secure http) (proposed: protobufs) ============= Secure session layer (for attack scenarios) Secure transport (TLS with X.509 certifications, DTLS + add ons) Transport (TCP or UDP Bob Moskowitz and I have proposed one. If you use this, you may be able to utilize a lighter weight upper layer. Thanks for your comments, Sue Hares -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Clark, Gilbert J. (GRC-LCA0) Sent: Wednesday, February 22, 2017 8:16 AM To: Tirumaleswar Reddy (tireddy); Roman D. Danyliw; Mortensen, Andrew; dots@ietf.org Subject: Re: [Dots] use of restconf for the data channel? Oh, neat: didn't realize RESTCONF graduated to an RFC. Looks like it was pretty recent, but that is still a good thing and does alleviate one of my concerns to an extent :) "But for DOTS data channel RESTCONF is suitable" Why is RESTCONF suitable for the data channel? Why was RESTCONF, specifically, chosen? What does it offer that might justify the implementation burden that it brings, and would therefore make it a compelling choice when compared to just building and documenting a REST interface? If there are reasons to use it that justify the complexity, then okay. I haven't seen these elements documented on the mailing list, though (apologies if I missed them?), and I also didn't see them documented anywhere in the current draft. With this in mind, including text to explain what benefits RESTCONF offers and explains *why* its adoption is important to the data channel would go a long way to alleviate the concerns I have in this instance :) I would also point out that the data-channel-04 draft still references the restconf draft instead of the RFC [1] - that's something that should probably be corrected for a future revision of the draft, if it hasn't already. Cheers, Gilbert [1] [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", draft-ietf-netconf-restconf-18 (work in progress), October 2016. ________________________________________ From: Tirumaleswar Reddy (tireddy) [tireddy@cisco.com] Sent: Wednesday, February 22, 2017 2:17 AM To: Clark, Gilbert J. (GRC-LCA0); Roman D. Danyliw; Mortensen, Andrew; dots@ietf.org Subject: RE: use of restconf for the data channel? NETCONF and RESTCONF are not both suitable for DOTS signal channel. But for DOTS data channel RESTCONF is suitable and RESTCONF is already an RFC https://tools.ietf.org/html/rfc8040. Various products in the market already use RESTCONF (e.g. confd 6.3 http://www.tail-f.com/management-agent/) -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Clark, Gilbert > J. (GRC- > LCA0) > Sent: Wednesday, February 22, 2017 11:26 AM > To: Roman D. Danyliw ; Mortensen, Andrew > ; dots@ietf.org > Subject: Re: [Dots] use of restconf for the data channel? > > Hi: > > My strongest objection to both NETCONF and RESTCONF were in the > context of their consideration for use in the signal channel. > > I wouldn't personally vote to see NETCONF, specifically, used in either channel. > NETCONF can involve substantial implementation complexity to support > capabilities that, in the case of DOTS, seem to me to be of marginal > utility at best. > > The use of RESTCONF seems a little more reasonable to me here since > many of those implementation requirements are relaxed. > > I will note that adoption of RESTCONF will inflict a 100+ page > not-yet-RFC as > (additional) required reading for anyone who wishes to implement a > DOTS data channel from scratch. Also, note that the use of RESTCONF > would introduce a dependency on something that is still in > development, and that therefore most likely hasn't yet been very well > tested and / or may be subject to change. > > Just offering some clarification on my original opinion(s), for what > that's worth. > > -Gilbert > _________________________________ > From: Dots [dots-bounces@ietf.org] on behalf of Roman D. Danyliw > [rdd@cert.org] > Sent: Wednesday, February 15, 2017 9:51 AM > To: Mortensen, Andrew; dots@ietf.org > Subject: Re: [Dots] use of restconf for the data channel? > > > Subject: [Dots] use of restconf for the data channel? > > [snip] > > > > Since RESTCONF is now a concrete proposal, it seems worthwhile > > continuing the debate ahead of the interim meeting. Are there > > specific concerns in the WG regarding the use ... > > This discussion topic is one we need to resolve. We can start here on > the list but I'll also add a slot to the interim meeting to continue the conversation. > > Roman > > _______________________________________________ > 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 From nobody Wed Feb 22 06:55:01 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FC01299D3 for ; Wed, 22 Feb 2017 06:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=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 8JraeteXkEgi for ; Wed, 22 Feb 2017 06:54:54 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 E5AE21299C1 for ; Wed, 22 Feb 2017 06:54:53 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.124.243.128; From: "Susan Hares" To: "'Clark, Gilbert J. \(GRC-LCA0\)'" , "'Tirumaleswar Reddy \(tireddy\)'" , "'Roman D. Danyliw'" , "'Mortensen, Andrew'" , References: <6AE56175-DBE7-4CD9-BA4E-5DCA88E901D8@arbor.net>, <359EC4B99E040048A7131E0F4E113AFC0104F01D17@marathon> <5AE9F2D3F5799545818A4795DA145E7103BC588B@NDJSMBX201.ndc.nasa.gov>, <5AE9F2D3F5799545818A4795DA145E7103BC595B@NDJSMBX201.ndc.nasa.gov> <00d501d28d13$3b0564f0$b1102ed0$@ndzh.com> In-Reply-To: <00d501d28d13$3b0564f0$b1102ed0$@ndzh.com> Date: Wed, 22 Feb 2017 09:50:24 -0500 Message-ID: <010a01d28d1b$0057c070$01074150$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJmFW6DDzAmzfgGvVNa0u+cVn2h/AKLxGeiAr6R73ABz+0ANAEMF6loAdJol4Sf/jlV4A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Dots] use of restconf for the data channel? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 14:55:00 -0000 Gilbert and Tirumaleswar: Here are a few advanced on NETCONF/RESTCONF stack related to upcoming changes. ---------------------------------------------------------------------------- ------------ Content (data models) ---> data stores (config, control plane, dynamic configuration) ---------------------------------------------------------------------------- -------------- Operations: NETCONF, RESTCONF config + events + pub/sub Upcoming operations: control plane state + dynamic config (dhcp) ---------------------------------------------------------------------------- --------------- CoAP (proposed for light-weight config/events, or streams) --------------- |TLS| DLTS | -------------- |TCP|UDP | -------------- | IP | --------------- The NETCONF/RESTCONF events are NETCONF and NETMOD Working Documents. The signaling of events or publication streams may range from light weight (I'm here, I'm attacked) to large streams. The events + publication/subscription streams requirements come from I2RS work which desires these to be used for configuration and for control plane protocols such as I2RS protocol. DOTS signaling could be another control plane protocol. CoAPs does not yet support these events, but it could be added. Why use this? The event notification and publication/subscription stream have many of the same base mechanisms. ID, lifetime, policy-id, sequencing numbers, and timeouts plus additional features to tune the level of data transmission. Mitigation request/signaling requires status updates at period intervals which could use the publication/subscription channel that sends this information to multiple clients. A binary encoding of the event/signal mechanism via CoAP would this efficient. One other thing to consider is the mixture of configuration/control plane protocols. The NETMOD revised data stores (https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/) describes the NETMOD architecture for the mixture of configuration and control plane. The control plane protocol does not need to follow the netconf/restconf operational rules - but can set their own rules for validation of data. NETMOD plans to support Yang modification for this point. I hope this helps. We'll talk in a few minutes. Sue Hares -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Susan Hares Sent: Wednesday, February 22, 2017 8:55 AM To: 'Clark, Gilbert J. (GRC-LCA0)'; 'Tirumaleswar Reddy (tireddy)'; 'Roman D. Danyliw'; 'Mortensen, Andrew'; dots@ietf.org Subject: Re: [Dots] use of restconf for the data channel? Gilbert: Can you provide a bit more unpacking of the message here? NETCONF or RESTCONF + Yang data models was the initial suggestion to allow stable protocol plus the ability to rapidly change data models that form the content of the bulk data channel. I sent a longish message to the list around IETF 97 since you have questions, I will reformat this message as an internet-draft and send it to the list this week. The Data channel requirements are: reliable transport, data privacy and integrity, resource configuration (described in OP-07), data-004 black-white list management. These are the basic design requirements for NETCONF/RESTCONF functionality. The specific resources, black-list, or white-list management can be data models. There are four parts to NETCONF/RESTCONF protocol: Content -- data models Messaging method (NETCONF: edit-config, get-config, RESTCONF/ PUT, GET) + new Event and publication/subscription streams information Messaging protocol (rpc/rpc-reply / secure http) ============= Secure transport (TLS with X.509 certifications, DTLS + add ons) Transport (TCP or UDP) Since all of the requirements for the secure transport are the same (peer mutual authentication, message confidentiality, integrity and authenticity, and message replay protection are the same as the DOTS requirements. You may wish to change the messaging protocol (rpc/rpc-reply or RESTCONF http) to protobufs. If so, I suggest you make that suggestion to the I2NSF WG that will include it in its general changes suggested to NETCONF WG and I2RS WG . The WGs would consider protobufs if there is a real use case. If you want to change the message method to edit configuration, what your alternative would be? If you are read, write, or updating you configuration or white lists, this is what these protocols are built for. The yang data models are tailored for user-readability. If you want to change the new event publication and subscription, exactly what do you want to change. As I will rapidly turn around a draft to answer your questions, please let me know exactly what your concerns are. If you are looking for the a secure shim layer, Content -- data models Messaging method (NETCONF: edit-config, get-config, RESTCONF/ PUT, GET) + new Event and publication/subscription streams information Messaging protocol (rpc/rpc-reply / secure http) (proposed: protobufs) ============= Secure session layer (for attack scenarios) Secure transport (TLS with X.509 certifications, DTLS + add ons) Transport (TCP or UDP Bob Moskowitz and I have proposed one. If you use this, you may be able to utilize a lighter weight upper layer. Thanks for your comments, Sue Hares -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Clark, Gilbert J. (GRC-LCA0) Sent: Wednesday, February 22, 2017 8:16 AM To: Tirumaleswar Reddy (tireddy); Roman D. Danyliw; Mortensen, Andrew; dots@ietf.org Subject: Re: [Dots] use of restconf for the data channel? Oh, neat: didn't realize RESTCONF graduated to an RFC. Looks like it was pretty recent, but that is still a good thing and does alleviate one of my concerns to an extent :) "But for DOTS data channel RESTCONF is suitable" Why is RESTCONF suitable for the data channel? Why was RESTCONF, specifically, chosen? What does it offer that might justify the implementation burden that it brings, and would therefore make it a compelling choice when compared to just building and documenting a REST interface? If there are reasons to use it that justify the complexity, then okay. I haven't seen these elements documented on the mailing list, though (apologies if I missed them?), and I also didn't see them documented anywhere in the current draft. With this in mind, including text to explain what benefits RESTCONF offers and explains *why* its adoption is important to the data channel would go a long way to alleviate the concerns I have in this instance :) I would also point out that the data-channel-04 draft still references the restconf draft instead of the RFC [1] - that's something that should probably be corrected for a future revision of the draft, if it hasn't already. Cheers, Gilbert [1] [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", draft-ietf-netconf-restconf-18 (work in progress), October 2016. ________________________________________ From: Tirumaleswar Reddy (tireddy) [tireddy@cisco.com] Sent: Wednesday, February 22, 2017 2:17 AM To: Clark, Gilbert J. (GRC-LCA0); Roman D. Danyliw; Mortensen, Andrew; dots@ietf.org Subject: RE: use of restconf for the data channel? NETCONF and RESTCONF are not both suitable for DOTS signal channel. But for DOTS data channel RESTCONF is suitable and RESTCONF is already an RFC https://tools.ietf.org/html/rfc8040. Various products in the market already use RESTCONF (e.g. confd 6.3 http://www.tail-f.com/management-agent/) -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Clark, Gilbert > J. (GRC- > LCA0) > Sent: Wednesday, February 22, 2017 11:26 AM > To: Roman D. Danyliw ; Mortensen, Andrew > ; dots@ietf.org > Subject: Re: [Dots] use of restconf for the data channel? > > Hi: > > My strongest objection to both NETCONF and RESTCONF were in the > context of their consideration for use in the signal channel. > > I wouldn't personally vote to see NETCONF, specifically, used in > either channel. > NETCONF can involve substantial implementation complexity to support > capabilities that, in the case of DOTS, seem to me to be of marginal > utility at best. > > The use of RESTCONF seems a little more reasonable to me here since > many of those implementation requirements are relaxed. > > I will note that adoption of RESTCONF will inflict a 100+ page > not-yet-RFC as > (additional) required reading for anyone who wishes to implement a > DOTS data channel from scratch. Also, note that the use of RESTCONF > would introduce a dependency on something that is still in > development, and that therefore most likely hasn't yet been very well > tested and / or may be subject to change. > > Just offering some clarification on my original opinion(s), for what > that's worth. > > -Gilbert > _________________________________ > From: Dots [dots-bounces@ietf.org] on behalf of Roman D. Danyliw > [rdd@cert.org] > Sent: Wednesday, February 15, 2017 9:51 AM > To: Mortensen, Andrew; dots@ietf.org > Subject: Re: [Dots] use of restconf for the data channel? > > > Subject: [Dots] use of restconf for the data channel? > > [snip] > > > > Since RESTCONF is now a concrete proposal, it seems worthwhile > > continuing the debate ahead of the interim meeting. Are there > > specific concerns in the WG regarding the use ... > > This discussion topic is one we need to resolve. We can start here on > the list but I'll also add a slot to the interim meeting to continue > the conversation. > > Roman > > _______________________________________________ > 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 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Wed Feb 22 07:06:17 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A251299E8 for ; Wed, 22 Feb 2017 07:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com 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 aKDFbYOC1fVq for ; Wed, 22 Feb 2017 07:06:14 -0800 (PST) Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7B51299E3 for ; Wed, 22 Feb 2017 07:06:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=16394; q=dns/txt; s=VRSN; t=1487775974; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BWQVGp1qPXI6QBCVpEnWJI8g1/KVUSNz+ZwSpmsOnNg=; b=PgrGTVYs8W0lmaINJqk15PeZ1n5sYaSfztrigRSCTVnKPAfVupRk4Uuk kvkBuSgmDT2P1MjuH/GVDUlof2e+VsKNeKdkYDIiXPMzJ/SKHRx1NPbUV wzlmYE01jUpXWZTpD4PjwAmwTcTfzrM8orKTGujROlIz83yiL/reMUAOE o6dUJ1l9YnCyDgdVmmTQYxe3Sev50OATmwkxz8k3w2+Jwmb84Faqlbzb0 quucORIb8dIFZOOZWMwOu8xR5fV/n1bJj/btZTae2dkZToH6KTPH3DQQy kT2FabquJ8O3aMfh5dQ4NHwxij3SNXiglz1RTPHrDLOn9AIa3N0mGjgR+ w==; X-IronPort-AV: E=Sophos;i="5.35,194,1484006400"; d="scan'208";a="1578527" IronPort-PHdr: =?us-ascii?q?9a23=3ARH65hxTpF0v/6dRCJohjX5cBNdpsv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa67ZxeEt8tkgFKBZ4jH8fUM07OQ6PG9HzVeqsnZ+Fk5M7V0Hycfjs?= =?us-ascii?q?sXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aFRrwLxd6?= =?us-ascii?q?KfroEYDOkcu3y/qy+5rOaAlUmTaxe71/IRG2oAnLq8UbgIRuJ6QtxhDUvnZGZu?= =?us-ascii?q?NayH9yK1mOhRj8/MCw/JBi8yRUpf0s8tNLXLv5caolU7FWFSwqPG8p6sLlsxnD?= =?us-ascii?q?VhaP6WAHUmoKiBpIAhPK4w/8U5zsryb1rOt92C2dPc3rUbA5XCmp4ql3RBP0ji?= =?us-ascii?q?oMKiU0+3/LhMNukK1boQqhpx1hzI7SfIGVL+d1cqfEcd8HWWZNQsNdWipcCY2+?= =?us-ascii?q?coQPFfIMM+ZGoYfgu1sAoxiwBQeuC+zhyz9HmnD40qIh3uQ9Cg7G2RAsE84UvX?= =?us-ascii?q?nWqtj+KaccUfqyzKnN1TjPYe1Y1inn54jHbxAuv+mAVq9of8rQykkjGR7Og1KW?= =?us-ascii?q?qYz5ITyazOsNs3WF4Od7S+KglXQnqwBqojiuyccsjJPFiZ4SylDB7Ch0xps+K9?= =?us-ascii?q?O/SE5+e9GkEZ1QujmbN4RoXsMiTXtkuCEgyr0Jv5OwYSsEyIw/yhLCd/CLaZWE?= =?us-ascii?q?7xDtWeqLPDt1hHxodKihixu98UWs0vDwWtWu3FpXrCdInMPAum0N2hDN8MSKRf?= =?us-ascii?q?1w9Vq71zmVzQDc8ORELFgxlarcNpEu3KY9loEWsUTfBi/2n1j2jLOOekUk5Oeo?= =?us-ascii?q?7+Pnb639qZ+GMY94lwX+M6srmsOlAOQ4Ng8OX3WH+eigyrHv51P5T6tQjv03ia?= =?us-ascii?q?nZsZ/aJcIBqqGlBA9V154v6xe5Dzi4zNQVhWQLIE5fdB6ajYXkNUvCLO34APqx?= =?us-ascii?q?mVigjjhmyvDeMr3kGJrNL3zDkLn7fbZ67k5R0AwzzcxB6J1OBbEBPez8V1TvtN?= =?us-ascii?q?PGFB85Mhe0w+foCNV7zI8RRWWPAqqBPKPIrVCI/v4vI/WLZIINpTn9LOQl5+X1?= =?us-ascii?q?gH84h1AdYaep0YEQaHCiEfRsO1+Zbmb0gtcdDWcKuRIzQ/bviF2FSz5Te2i9X6?= =?us-ascii?q?Qn5j4lDoKrFp3MRpq2j7yGxie3BJtWaX5aClqUC3fna52EW+sQaCKVOsJhiCEL?= =?us-ascii?q?WqW6RoA9yx6urhP6x6BgLurO9S0SrYjj28Rt5+3PiREy8iR5D9ic02GXUW57g3?= =?us-ascii?q?4HRj8t0a9joEx90UuM0a9ij/NEEtxT4utDUh0mOp7E0+x6F9fyVxrOfteITFap?= =?us-ascii?q?WcupASstTt4rwd8CeVpyG9G4gRDZ3CqnGLkVmKaQBJMu6K7c0H/xJ9hlwXbcyK?= =?us-ascii?q?Yhl0UmQtdINWC+na5/9xLcB5TXnEWCjKuqc7kT3S/N9GuZ0WWOu0RYA0ZMVvD+?= =?us-ascii?q?QGsWYAP2pM70/QuWVL+nE7k8Gg1N287EIaxPPJmhxxptQP75O5CWTGO1kWqqGV?= =?us-ascii?q?6qgPvMQ7DBPkE29X2cRwJMxw8S+XyLLxR4BGGqp2vEDxRoHEnmJUzr77864Dn0?= =?us-ascii?q?ck4u0gSDa0B6yLOvsiQYifCNA7MP36gJtCsw6no+VAKh3sjbB9aRjwFgZ65bJ9?= =?us-ascii?q?g65QEDnSiWjQt4N5roA+YqqlcYYgB2oAykn0FtBolomsUwsDUt1gUkberSn3ZG?= =?us-ascii?q?bS+V24v9PPmfA2/+5h2wJOSejljb18yK96EU5fIQok/puxvvEEc+pTEvmdVSz2?= =?us-ascii?q?C055jWAkwVS527GhI78ARhj7DXfid74Jnbgy5CK66x53X+1tsmGeZhgjChfJ0X?= =?us-ascii?q?ZKWYGQb9DsAyGcW0KfcrlF7vZRUBarMBvJUoNt+rIqPVkJWgO/xtyXf/1TxK?= X-IPAS-Result: =?us-ascii?q?A2HNAQBxqK1Y//WZrQpeGgEBAQECAQEBAQgBAQEBFQEBAQE?= =?us-ascii?q?CAQEBAQgBAQEBhAeBCQeDVIoIkVqVNIIJBB8LhXgCGoMqGAEBAQEBAQEBAQEBA?= =?us-ascii?q?oEHgjMiAQwmFxABAQEBAQEBAQEjAQEBAQEBIwINMSwBAQEBAwEBIQQNOhcEAgE?= =?us-ascii?q?IDQEDAQMBAQMCCRoDAgICJQsUAQIGCAIEARKKA68JgWw6i0MBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdgQuFQoIEgmqEVBeCby6CMQWJEpJ+AYZzjSqFHINRhiiPCYQ?= =?us-ascii?q?cH4E5VBU+EQGGN3WHWSuBA4ENAQEB?= Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id v1MF69oX021774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Feb 2017 10:06:09 -0500 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Wed, 22 Feb 2017 10:06:08 -0500 From: "Teague, Nik" To: Susan Hares , "'Clark, Gilbert J. (GRC-LCA0)'" , "'Tirumaleswar Reddy (tireddy)'" , "'Roman D. Danyliw'" , "'Mortensen, Andrew'" , "dots@ietf.org" Thread-Topic: [EXTERNAL] Re: [Dots] use of restconf for the data channel? Thread-Index: AQHShUvelq2Fax0X1U+DAQQ/dairhqFqKpDAgApPffGAADEigIAAW2c4gABpCQCAAA+ZAIAABIqA Date: Wed, 22 Feb 2017 15:06:07 +0000 Message-ID: <9BB728BF-B3D5-4A8F-8C82-0EC87B7A59AE@verisign.com> References: <6AE56175-DBE7-4CD9-BA4E-5DCA88E901D8@arbor.net> <359EC4B99E040048A7131E0F4E113AFC0104F01D17@marathon> <5AE9F2D3F5799545818A4795DA145E7103BC588B@NDJSMBX201.ndc.nasa.gov> <5AE9F2D3F5799545818A4795DA145E7103BC595B@NDJSMBX201.ndc.nasa.gov> <00d501d28d13$3b0564f0$b1102ed0$@ndzh.com> <010a01d28d1b$0057c070$01074150$@ndzh.com> In-Reply-To: <010a01d28d1b$0057c070$01074150$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.0.161115 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-ID: <0254CF8D06D4BD46AFFE6494AB737CFF@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] use of restconf for the data channel? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 15:06:16 -0000 U3VlIGhpLA0KDQpBcmUgeW91IGRldGFpbGluZyB0aGlzIHN0aWxsIGluIHRoZSBjb250ZXh0IG9m IHRoZSBET1RTIGRhdGEgY2hhbm5lbD8gIFlvdSBtZW50aW9uIERPVFMgc2lnbmFsaW5nDQoNClRo YW5rcywNCg0KLU5paw0KDQpPbiAyMi8wMi8yMDE3LCAxNDo1MCwgIkRvdHMgb24gYmVoYWxmIG9m IFN1c2FuIEhhcmVzIiA8ZG90cy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBzaGFyZXNA bmR6aC5jb20+IHdyb3RlOg0KDQogICAgR2lsYmVydCBhbmQgVGlydW1hbGVzd2FyOiANCiAgICAN CiAgICBIZXJlIGFyZSBhIGZldyBhZHZhbmNlZCBvbiBORVRDT05GL1JFU1RDT05GIHN0YWNrIHJl bGF0ZWQgdG8gdXBjb21pbmcNCiAgICBjaGFuZ2VzLiANCiAgICANCiAgICAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQogICAgLS0tLS0tLS0tLS0tDQogICAgQ29udGVudCAoZGF0YSBtb2RlbHMpIC0tLT4g ZGF0YSBzdG9yZXMgKGNvbmZpZywgY29udHJvbCBwbGFuZSwgZHluYW1pYw0KICAgIGNvbmZpZ3Vy YXRpb24pIA0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAtLS0tLS0tLS0tLS0tLQ0KICAg IE9wZXJhdGlvbnM6IE5FVENPTkYsIFJFU1RDT05GIA0KICAgICAgIGNvbmZpZyArIGV2ZW50cyAr IHB1Yi9zdWIgDQogICAgICBVcGNvbWluZyAgb3BlcmF0aW9uczogIGNvbnRyb2wgcGxhbmUgc3Rh dGUgKyAgZHluYW1pYyBjb25maWcgKGRoY3ApICANCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog ICAgLS0tLS0tLS0tLS0tLS0tDQogICAgQ29BUCAocHJvcG9zZWQgZm9yIGxpZ2h0LXdlaWdodCBj b25maWcvZXZlbnRzLCBvciBzdHJlYW1zKSANCiAgICAtLS0tLS0tLS0tLS0tLS0NCiAgICB8VExT fCBETFRTIHwNCiAgICAtLS0tLS0tLS0tLS0tLQ0KICAgIHxUQ1B8VURQIHwNCiAgICAtLS0tLS0t LS0tLS0tLQ0KICAgIHwgSVAgICAgICAgICAgICB8DQogICAgLS0tLS0tLS0tLS0tLS0tDQogICAg DQogICAgVGhlIE5FVENPTkYvUkVTVENPTkYgZXZlbnRzIGFyZSBORVRDT05GIGFuZCBORVRNT0Qg V29ya2luZyBEb2N1bWVudHMuICBUaGUNCiAgICBzaWduYWxpbmcgb2YgZXZlbnRzIG9yIHB1Ymxp Y2F0aW9uIHN0cmVhbXMgbWF5IHJhbmdlIGZyb20gbGlnaHQgd2VpZ2h0IChJJ20NCiAgICBoZXJl LCBJJ20gYXR0YWNrZWQpIHRvIGxhcmdlIHN0cmVhbXMuICBUaGUgIGV2ZW50cyArDQogICAgcHVi bGljYXRpb24vc3Vic2NyaXB0aW9uIHN0cmVhbXMgcmVxdWlyZW1lbnRzIGNvbWUgZnJvbSBJMlJT IHdvcmsgd2hpY2gNCiAgICBkZXNpcmVzIHRoZXNlIHRvIGJlIHVzZWQgZm9yIGNvbmZpZ3VyYXRp b24gYW5kIGZvciBjb250cm9sIHBsYW5lIHByb3RvY29scw0KICAgIHN1Y2ggYXMgSTJSUyBwcm90 b2NvbC4gIERPVFMgc2lnbmFsaW5nIGNvdWxkIGJlIGFub3RoZXIgY29udHJvbCBwbGFuZQ0KICAg IHByb3RvY29sLiAgQ29BUHMgZG9lcyBub3QgeWV0IHN1cHBvcnQgdGhlc2UgZXZlbnRzLCBidXQg aXQgY291bGQgYmUgYWRkZWQuDQogICAgDQogICAgDQogICAgV2h5IHVzZSB0aGlzPyAgVGhlIGV2 ZW50IG5vdGlmaWNhdGlvbiBhbmQgcHVibGljYXRpb24vc3Vic2NyaXB0aW9uIHN0cmVhbQ0KICAg IGhhdmUgbWFueSBvZiB0aGUgc2FtZSBiYXNlIG1lY2hhbmlzbXMuIElELCBsaWZldGltZSwgcG9s aWN5LWlkLCBzZXF1ZW5jaW5nDQogICAgbnVtYmVycywgYW5kIHRpbWVvdXRzIHBsdXMgYWRkaXRp b25hbCBmZWF0dXJlcyB0byB0dW5lIHRoZSBsZXZlbCBvZiBkYXRhDQogICAgdHJhbnNtaXNzaW9u LiAgTWl0aWdhdGlvbiByZXF1ZXN0L3NpZ25hbGluZyByZXF1aXJlcyBzdGF0dXMgdXBkYXRlcyBh dA0KICAgIHBlcmlvZCBpbnRlcnZhbHMgd2hpY2ggY291bGQgdXNlIHRoZSBwdWJsaWNhdGlvbi9z dWJzY3JpcHRpb24gY2hhbm5lbCB0aGF0DQogICAgc2VuZHMgdGhpcyBpbmZvcm1hdGlvbiB0byBt dWx0aXBsZSBjbGllbnRzLiAgICBBIGJpbmFyeSBlbmNvZGluZyBvZiB0aGUNCiAgICBldmVudC9z aWduYWwgbWVjaGFuaXNtIHZpYSBDb0FQIHdvdWxkIHRoaXMgZWZmaWNpZW50LiANCiAgICANCiAg ICBPbmUgb3RoZXIgdGhpbmcgdG8gY29uc2lkZXIgaXMgdGhlIG1peHR1cmUgb2YgY29uZmlndXJh dGlvbi9jb250cm9sIHBsYW5lDQogICAgcHJvdG9jb2xzLiAgIFRoZSBORVRNT0QgcmV2aXNlZCBk YXRhIHN0b3Jlcw0KICAgIChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMvKQ0KICAgIGRlc2NyaWJlcyB0aGUgTkVUTU9E IGFyY2hpdGVjdHVyZSBmb3IgdGhlIG1peHR1cmUgb2YgY29uZmlndXJhdGlvbiBhbmQNCiAgICBj b250cm9sIHBsYW5lLiAgIFRoZSAgY29udHJvbCBwbGFuZSBwcm90b2NvbCBkb2VzIG5vdCBuZWVk IHRvIGZvbGxvdyB0aGUNCiAgICBuZXRjb25mL3Jlc3Rjb25mIG9wZXJhdGlvbmFsIHJ1bGVzIC0g IGJ1dCBjYW4gc2V0IHRoZWlyIG93biBydWxlcyBmb3INCiAgICB2YWxpZGF0aW9uIG9mIGRhdGEu ICAgTkVUTU9EIHBsYW5zIHRvIHN1cHBvcnQgWWFuZyBtb2RpZmljYXRpb24gZm9yIHRoaXMNCiAg ICBwb2ludC4NCiAgICANCiAgICBJIGhvcGUgdGhpcyBoZWxwcy4gICBXZSdsbCB0YWxrIGluIGEg ZmV3IG1pbnV0ZXMuIA0KICAgIA0KICAgIFN1ZSBIYXJlcyANCiAgICANCiAgICAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBTdXNhbiBIYXJlcw0KICAgIFNlbnQ6IFdlZG5lc2RheSwgRmVi cnVhcnkgMjIsIDIwMTcgODo1NSBBTQ0KICAgIFRvOiAnQ2xhcmssIEdpbGJlcnQgSi4gKEdSQy1M Q0EwKSc7ICdUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpJzsgJ1JvbWFuDQogICAgRC4gRGFu eWxpdyc7ICdNb3J0ZW5zZW4sIEFuZHJldyc7IGRvdHNAaWV0Zi5vcmcNCiAgICBTdWJqZWN0OiBS ZTogW0RvdHNdIHVzZSBvZiByZXN0Y29uZiBmb3IgdGhlIGRhdGEgY2hhbm5lbD8NCiAgICANCiAg ICBHaWxiZXJ0OiANCiAgICANCiAgICBDYW4geW91IHByb3ZpZGUgYSBiaXQgbW9yZSB1bnBhY2tp bmcgb2YgdGhlIG1lc3NhZ2UgaGVyZT8gICAgTkVUQ09ORiBvcg0KICAgIFJFU1RDT05GICsgWWFu ZyBkYXRhIG1vZGVscyB3YXMgdGhlIGluaXRpYWwgc3VnZ2VzdGlvbiB0byBhbGxvdyBzdGFibGUN CiAgICBwcm90b2NvbCBwbHVzIHRoZSBhYmlsaXR5IHRvIHJhcGlkbHkgY2hhbmdlIGRhdGEgbW9k ZWxzIHRoYXQgZm9ybSB0aGUNCiAgICBjb250ZW50IG9mIHRoZSBidWxrIGRhdGEgY2hhbm5lbC4g SSBzZW50IGEgbG9uZ2lzaCBtZXNzYWdlIHRvIHRoZSBsaXN0DQogICAgYXJvdW5kIElFVEYgOTcg c2luY2UgeW91IGhhdmUgcXVlc3Rpb25zLCBJIHdpbGwgcmVmb3JtYXQgdGhpcyBtZXNzYWdlIGFz IGFuDQogICAgaW50ZXJuZXQtZHJhZnQgYW5kIHNlbmQgaXQgdG8gdGhlIGxpc3QgdGhpcyB3ZWVr LiANCiAgICANCiAgICBUaGUgRGF0YSBjaGFubmVsIHJlcXVpcmVtZW50cyBhcmU6ICByZWxpYWJs ZSB0cmFuc3BvcnQsIGRhdGEgcHJpdmFjeSBhbmQNCiAgICBpbnRlZ3JpdHksIHJlc291cmNlIGNv bmZpZ3VyYXRpb24gKGRlc2NyaWJlZCBpbiBPUC0wNyksIGRhdGEtMDA0IGJsYWNrLXdoaXRlDQog ICAgbGlzdCBtYW5hZ2VtZW50LiAgVGhlc2UgYXJlIHRoZSBiYXNpYyBkZXNpZ24gcmVxdWlyZW1l bnRzIGZvcg0KICAgIE5FVENPTkYvUkVTVENPTkYgZnVuY3Rpb25hbGl0eS4gICBUaGUgc3BlY2lm aWMgcmVzb3VyY2VzLCBibGFjay1saXN0LCBvcg0KICAgIHdoaXRlLWxpc3QgbWFuYWdlbWVudCBj YW4gYmUgZGF0YSBtb2RlbHMuICAgDQogICAgDQogICAgVGhlcmUgYXJlIGZvdXIgcGFydHMgdG8g TkVUQ09ORi9SRVNUQ09ORiBwcm90b2NvbDogDQogICAgDQogICAgQ29udGVudCAgLS0gICBkYXRh IG1vZGVscyANCiAgICBNZXNzYWdpbmcgbWV0aG9kICAoTkVUQ09ORjogZWRpdC1jb25maWcsIGdl dC1jb25maWcsIFJFU1RDT05GLyBQVVQsIEdFVCkgIA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKyBuZXcgRXZlbnQgYW5kIHB1YmxpY2F0aW9uL3N1YnNjcmlwdGlvbg0KICAg IHN0cmVhbXMgaW5mb3JtYXRpb24gIA0KICAgIE1lc3NhZ2luZyBwcm90b2NvbCAocnBjL3JwYy1y ZXBseSAvIHNlY3VyZSBodHRwKSAgIA0KICAgID09PT09PT09PT09PT0NCiAgICBTZWN1cmUgdHJh bnNwb3J0IChUTFMgd2l0aCBYLjUwOSBjZXJ0aWZpY2F0aW9ucywgRFRMUyArIGFkZCBvbnMpICAg DQogICAgVHJhbnNwb3J0IChUQ1Agb3IgVURQKSANCiAgICANCiAgICBTaW5jZSBhbGwgb2YgdGhl IHJlcXVpcmVtZW50cyBmb3IgdGhlIHNlY3VyZSB0cmFuc3BvcnQgYXJlIHRoZSBzYW1lIChwZWVy DQogICAgbXV0dWFsIGF1dGhlbnRpY2F0aW9uLCBtZXNzYWdlIGNvbmZpZGVudGlhbGl0eSwgaW50 ZWdyaXR5IGFuZCBhdXRoZW50aWNpdHksDQogICAgYW5kIG1lc3NhZ2UgcmVwbGF5IHByb3RlY3Rp b24gYXJlIHRoZSBzYW1lIGFzIHRoZSBET1RTIHJlcXVpcmVtZW50cy4gICBZb3UNCiAgICBtYXkg d2lzaCB0byBjaGFuZ2UgdGhlIG1lc3NhZ2luZyBwcm90b2NvbCAocnBjL3JwYy1yZXBseSBvciBS RVNUQ09ORiBodHRwKQ0KICAgIHRvIHByb3RvYnVmcy4gIElmIHNvLCBJIHN1Z2dlc3QgeW91IG1h a2UgdGhhdCBzdWdnZXN0aW9uIHRvIHRoZSBJMk5TRiBXRw0KICAgIHRoYXQgd2lsbCBpbmNsdWRl IGl0IGluIGl0cyBnZW5lcmFsIGNoYW5nZXMgc3VnZ2VzdGVkIHRvIE5FVENPTkYgV0cgYW5kIEky UlMNCiAgICBXRyAuICAgVGhlIFdHcyB3b3VsZCBjb25zaWRlciBwcm90b2J1ZnMgaWYgdGhlcmUg aXMgYSByZWFsIHVzZSBjYXNlLiAgDQogICAgDQogICAgSWYgeW91IHdhbnQgdG8gY2hhbmdlIHRo ZSBtZXNzYWdlIG1ldGhvZCB0byBlZGl0IGNvbmZpZ3VyYXRpb24sIHdoYXQgeW91cg0KICAgIGFs dGVybmF0aXZlIHdvdWxkIGJlPyAgSWYgeW91IGFyZSByZWFkLCB3cml0ZSwgb3IgdXBkYXRpbmcg eW91IGNvbmZpZ3VyYXRpb24NCiAgICBvciB3aGl0ZSBsaXN0cywgdGhpcyBpcyB3aGF0IHRoZXNl IHByb3RvY29scyBhcmUgYnVpbHQgZm9yLiAgIFRoZSB5YW5nIGRhdGENCiAgICBtb2RlbHMgYXJl IHRhaWxvcmVkIGZvciB1c2VyLXJlYWRhYmlsaXR5LiAgIElmIHlvdSB3YW50IHRvIGNoYW5nZSB0 aGUgbmV3DQogICAgZXZlbnQgcHVibGljYXRpb24gYW5kIHN1YnNjcmlwdGlvbiwgIGV4YWN0bHkg d2hhdCBkbyB5b3Ugd2FudCB0byBjaGFuZ2UuDQogICAgQXMgSSB3aWxsIHJhcGlkbHkgdHVybiBh cm91bmQgYSBkcmFmdCB0byBhbnN3ZXIgeW91ciBxdWVzdGlvbnMsIHBsZWFzZSBsZXQNCiAgICBt ZSBrbm93IGV4YWN0bHkgd2hhdCB5b3VyIGNvbmNlcm5zIGFyZS4gDQogICAgDQogICAgSWYgeW91 IGFyZSBsb29raW5nIGZvciB0aGUgYSBzZWN1cmUgc2hpbSBsYXllciwgDQogICAgDQogICAgQ29u dGVudCAgLS0gICBkYXRhIG1vZGVscyANCiAgICBNZXNzYWdpbmcgbWV0aG9kICAoTkVUQ09ORjog ZWRpdC1jb25maWcsIGdldC1jb25maWcsIFJFU1RDT05GLyBQVVQsIEdFVCkgIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKyBuZXcgRXZlbnQgYW5kIHB1YmxpY2F0aW9uL3N1 YnNjcmlwdGlvbg0KICAgIHN0cmVhbXMgaW5mb3JtYXRpb24gIA0KICAgIE1lc3NhZ2luZyBwcm90 b2NvbCAocnBjL3JwYy1yZXBseSAvIHNlY3VyZSBodHRwKSAocHJvcG9zZWQ6IHByb3RvYnVmcykg ICANCiAgICA9PT09PT09PT09PT09DQogICAgU2VjdXJlIHNlc3Npb24gbGF5ZXIgKGZvciBhdHRh Y2sgc2NlbmFyaW9zKSANCiAgICBTZWN1cmUgdHJhbnNwb3J0IChUTFMgd2l0aCBYLjUwOSBjZXJ0 aWZpY2F0aW9ucywgRFRMUyArIGFkZCBvbnMpICAgDQogICAgVHJhbnNwb3J0IChUQ1Agb3IgVURQ DQogICAgDQogICAgQm9iIE1vc2tvd2l0eiBhbmQgSSBoYXZlIHByb3Bvc2VkIG9uZS4gIElmIHlv dSB1c2UgdGhpcywgeW91IG1heSBiZSBhYmxlIHRvDQogICAgdXRpbGl6ZSBhIGxpZ2h0ZXIgd2Vp Z2h0IHVwcGVyIGxheWVyLiANCiAgICANCiAgICANCiAgICBUaGFua3MgZm9yIHlvdXIgY29tbWVu dHMsIA0KICAgIA0KICAgIFN1ZSBIYXJlcyANCiAgICANCiAgICAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KICAgIEZyb206IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBDbGFyaywgR2lsYmVydCBKLg0KICAgIChHUkMtTENBMCkNCiAgICBTZW50OiBX ZWRuZXNkYXksIEZlYnJ1YXJ5IDIyLCAyMDE3IDg6MTYgQU0NCiAgICBUbzogVGlydW1hbGVzd2Fy IFJlZGR5ICh0aXJlZGR5KTsgUm9tYW4gRC4gRGFueWxpdzsgTW9ydGVuc2VuLCBBbmRyZXc7DQog ICAgZG90c0BpZXRmLm9yZw0KICAgIFN1YmplY3Q6IFJlOiBbRG90c10gdXNlIG9mIHJlc3Rjb25m IGZvciB0aGUgZGF0YSBjaGFubmVsPw0KICAgIA0KICAgIE9oLCBuZWF0OiBkaWRuJ3QgcmVhbGl6 ZSBSRVNUQ09ORiBncmFkdWF0ZWQgdG8gYW4gUkZDLiAgTG9va3MgbGlrZSBpdCB3YXMNCiAgICBw cmV0dHkgcmVjZW50LCBidXQgdGhhdCBpcyBzdGlsbCBhIGdvb2QgdGhpbmcgYW5kIGRvZXMgYWxs ZXZpYXRlIG9uZSBvZiBteQ0KICAgIGNvbmNlcm5zIHRvIGFuIGV4dGVudCA6KQ0KICAgIA0KICAg ICJCdXQgZm9yIERPVFMgZGF0YSBjaGFubmVsIFJFU1RDT05GIGlzIHN1aXRhYmxlIg0KICAgIA0K ICAgIFdoeSBpcyBSRVNUQ09ORiBzdWl0YWJsZSBmb3IgdGhlIGRhdGEgY2hhbm5lbD8gIFdoeSB3 YXMgUkVTVENPTkYsDQogICAgc3BlY2lmaWNhbGx5LCBjaG9zZW4/ICBXaGF0IGRvZXMgaXQgb2Zm ZXIgdGhhdCBtaWdodCBqdXN0aWZ5IHRoZQ0KICAgIGltcGxlbWVudGF0aW9uIGJ1cmRlbiB0aGF0 IGl0IGJyaW5ncywgYW5kIHdvdWxkIHRoZXJlZm9yZSBtYWtlIGl0IGENCiAgICBjb21wZWxsaW5n IGNob2ljZSB3aGVuIGNvbXBhcmVkIHRvIGp1c3QgYnVpbGRpbmcgYW5kIGRvY3VtZW50aW5nIGEg UkVTVA0KICAgIGludGVyZmFjZT8gIElmIHRoZXJlIGFyZSByZWFzb25zIHRvIHVzZSBpdCB0aGF0 IGp1c3RpZnkgdGhlIGNvbXBsZXhpdHksIHRoZW4NCiAgICBva2F5LiAgSSBoYXZlbid0IHNlZW4g dGhlc2UgZWxlbWVudHMgZG9jdW1lbnRlZCBvbiB0aGUgbWFpbGluZyBsaXN0LCB0aG91Z2gNCiAg ICAoYXBvbG9naWVzIGlmIEkgbWlzc2VkIHRoZW0/KSwgYW5kIEkgYWxzbyBkaWRuJ3Qgc2VlIHRo ZW0gZG9jdW1lbnRlZA0KICAgIGFueXdoZXJlIGluIHRoZSBjdXJyZW50IGRyYWZ0LiAgDQogICAg DQogICAgV2l0aCB0aGlzIGluIG1pbmQsIGluY2x1ZGluZyB0ZXh0IHRvIGV4cGxhaW4gd2hhdCBi ZW5lZml0cyBSRVNUQ09ORiBvZmZlcnMNCiAgICBhbmQgZXhwbGFpbnMgKndoeSogaXRzIGFkb3B0 aW9uIGlzIGltcG9ydGFudCB0byB0aGUgZGF0YSBjaGFubmVsIHdvdWxkIGdvIGENCiAgICBsb25n IHdheSB0byBhbGxldmlhdGUgdGhlIGNvbmNlcm5zIEkgaGF2ZSBpbiB0aGlzIGluc3RhbmNlIDop DQogICAgDQogICAgSSB3b3VsZCBhbHNvIHBvaW50IG91dCB0aGF0IHRoZSBkYXRhLWNoYW5uZWwt MDQgZHJhZnQgc3RpbGwgcmVmZXJlbmNlcyB0aGUNCiAgICByZXN0Y29uZiBkcmFmdCBpbnN0ZWFk IG9mIHRoZSBSRkMgWzFdIC0gdGhhdCdzIHNvbWV0aGluZyB0aGF0IHNob3VsZA0KICAgIHByb2Jh Ymx5IGJlIGNvcnJlY3RlZCBmb3IgYSBmdXR1cmUgcmV2aXNpb24gb2YgdGhlIGRyYWZ0LCBpZiBp dCBoYXNuJ3QNCiAgICBhbHJlYWR5Lg0KICAgIA0KICAgIENoZWVycywNCiAgICBHaWxiZXJ0DQog ICAgDQogICAgWzFdICAgIFtJLUQuaWV0Zi1uZXRjb25mLXJlc3Rjb25mXQ0KICAgICAgICAgICAg ICAgICAgQmllcm1hbiwgQS4sIEJqb3JrbHVuZCwgTS4sIGFuZCBLLiBXYXRzZW4sICJSRVNUQ09O Rg0KICAgICAgICAgICAgICAgICAgUHJvdG9jb2wiLCBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNv bmYtMTggKHdvcmsgaW4NCiAgICAgICAgICAgICAgICAgIHByb2dyZXNzKSwgT2N0b2JlciAyMDE2 Lg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBGcm9t OiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIFt0aXJlZGR5QGNpc2NvLmNvbV0NCiAgICBT ZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDIyLCAyMDE3IDI6MTcgQU0NCiAgICBUbzogQ2xhcmss IEdpbGJlcnQgSi4gKEdSQy1MQ0EwKTsgUm9tYW4gRC4gRGFueWxpdzsgTW9ydGVuc2VuLCBBbmRy ZXc7DQogICAgZG90c0BpZXRmLm9yZw0KICAgIFN1YmplY3Q6IFJFOiB1c2Ugb2YgcmVzdGNvbmYg Zm9yIHRoZSBkYXRhIGNoYW5uZWw/DQogICAgDQogICAgTkVUQ09ORiBhbmQgUkVTVENPTkYgYXJl IG5vdCBib3RoIHN1aXRhYmxlIGZvciBET1RTIHNpZ25hbCBjaGFubmVsLg0KICAgIEJ1dCBmb3Ig RE9UUyBkYXRhIGNoYW5uZWwgUkVTVENPTkYgaXMgc3VpdGFibGUgYW5kIFJFU1RDT05GIGlzIGFs cmVhZHkgYW4NCiAgICBSRkMgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgwNDAuDQog ICAgVmFyaW91cyBwcm9kdWN0cyBpbiB0aGUgbWFya2V0IGFscmVhZHkgdXNlIFJFU1RDT05GIChl LmcuIGNvbmZkIDYuMw0KICAgIGh0dHA6Ly93d3cudGFpbC1mLmNvbS9tYW5hZ2VtZW50LWFnZW50 LykNCiAgICANCiAgICAtVGlydQ0KICAgIA0KICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCiAgICA+IEZyb206IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBDbGFyaywgR2lsYmVydCANCiAgICA+IEouIChHUkMtDQogICAgPiBMQ0EwKQ0KICAg ID4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyMiwgMjAxNyAxMToyNiBBTQ0KICAgID4gVG86 IFJvbWFuIEQuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz47IE1vcnRlbnNlbiwgQW5kcmV3IA0KICAg ID4gPGFtb3J0ZW5zZW5AYXJib3IubmV0PjsgZG90c0BpZXRmLm9yZw0KICAgID4gU3ViamVjdDog UmU6IFtEb3RzXSB1c2Ugb2YgcmVzdGNvbmYgZm9yIHRoZSBkYXRhIGNoYW5uZWw/DQogICAgPg0K ICAgID4gSGk6DQogICAgPg0KICAgID4gTXkgc3Ryb25nZXN0IG9iamVjdGlvbiB0byBib3RoIE5F VENPTkYgYW5kIFJFU1RDT05GIHdlcmUgaW4gdGhlIA0KICAgID4gY29udGV4dCBvZiB0aGVpciBj b25zaWRlcmF0aW9uIGZvciB1c2UgaW4gdGhlIHNpZ25hbCBjaGFubmVsLg0KICAgID4NCiAgICA+ IEkgd291bGRuJ3QgcGVyc29uYWxseSB2b3RlIHRvIHNlZSBORVRDT05GLCBzcGVjaWZpY2FsbHks IHVzZWQgaW4gDQogICAgPiBlaXRoZXINCiAgICBjaGFubmVsLg0KICAgID4gTkVUQ09ORiBjYW4g aW52b2x2ZSBzdWJzdGFudGlhbCBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5IHRvIHN1cHBvcnQg DQogICAgPiBjYXBhYmlsaXRpZXMgdGhhdCwgaW4gdGhlIGNhc2Ugb2YgRE9UUywgc2VlbSB0byBt ZSB0byBiZSBvZiBtYXJnaW5hbCANCiAgICA+IHV0aWxpdHkgYXQgYmVzdC4NCiAgICA+DQogICAg PiBUaGUgdXNlIG9mIFJFU1RDT05GIHNlZW1zIGEgbGl0dGxlIG1vcmUgcmVhc29uYWJsZSB0byBt ZSBoZXJlIHNpbmNlIA0KICAgID4gbWFueSBvZiB0aG9zZSBpbXBsZW1lbnRhdGlvbiByZXF1aXJl bWVudHMgYXJlIHJlbGF4ZWQuDQogICAgPg0KICAgID4gSSB3aWxsIG5vdGUgdGhhdCBhZG9wdGlv biBvZiBSRVNUQ09ORiB3aWxsIGluZmxpY3QgYSAxMDArIHBhZ2UgDQogICAgPiBub3QteWV0LVJG QyBhcw0KICAgID4gKGFkZGl0aW9uYWwpIHJlcXVpcmVkIHJlYWRpbmcgZm9yIGFueW9uZSB3aG8g d2lzaGVzIHRvIGltcGxlbWVudCBhIA0KICAgID4gRE9UUyBkYXRhIGNoYW5uZWwgZnJvbSBzY3Jh dGNoLiAgQWxzbywgbm90ZSB0aGF0IHRoZSB1c2Ugb2YgUkVTVENPTkYgDQogICAgPiB3b3VsZCBp bnRyb2R1Y2UgYSBkZXBlbmRlbmN5IG9uIHNvbWV0aGluZyB0aGF0IGlzIHN0aWxsIGluIA0KICAg ID4gZGV2ZWxvcG1lbnQsIGFuZCB0aGF0IHRoZXJlZm9yZSBtb3N0IGxpa2VseSBoYXNuJ3QgeWV0 IGJlZW4gdmVyeSB3ZWxsIA0KICAgID4gdGVzdGVkIGFuZCAvIG9yIG1heSBiZSBzdWJqZWN0IHRv IGNoYW5nZS4NCiAgICA+DQogICAgPiBKdXN0IG9mZmVyaW5nIHNvbWUgY2xhcmlmaWNhdGlvbiBv biBteSBvcmlnaW5hbCBvcGluaW9uKHMpLCBmb3Igd2hhdCANCiAgICA+IHRoYXQncyB3b3J0aC4N CiAgICA+DQogICAgPiAtR2lsYmVydA0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQogICAgPiBGcm9tOiBEb3RzIFtkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJlaGFs ZiBvZiBSb21hbiBELiBEYW55bGl3IA0KICAgID4gW3JkZEBjZXJ0Lm9yZ10NCiAgICA+IFNlbnQ6 IFdlZG5lc2RheSwgRmVicnVhcnkgMTUsIDIwMTcgOTo1MSBBTQ0KICAgID4gVG86IE1vcnRlbnNl biwgQW5kcmV3OyBkb3RzQGlldGYub3JnDQogICAgPiBTdWJqZWN0OiBSZTogW0RvdHNdIHVzZSBv ZiByZXN0Y29uZiBmb3IgdGhlIGRhdGEgY2hhbm5lbD8NCiAgICA+DQogICAgPiA+IFN1YmplY3Q6 IFtEb3RzXSB1c2Ugb2YgcmVzdGNvbmYgZm9yIHRoZSBkYXRhIGNoYW5uZWw/DQogICAgPiA+IFtz bmlwXQ0KICAgID4gPg0KICAgID4gPiBTaW5jZSBSRVNUQ09ORiBpcyBub3cgYSBjb25jcmV0ZSBw cm9wb3NhbCwgaXQgc2VlbXMgd29ydGh3aGlsZSANCiAgICA+ID4gY29udGludWluZyB0aGUgZGVi YXRlIGFoZWFkIG9mIHRoZSBpbnRlcmltIG1lZXRpbmcuICBBcmUgdGhlcmUgDQogICAgPiA+IHNw ZWNpZmljIGNvbmNlcm5zIGluIHRoZSBXRyByZWdhcmRpbmcgdGhlIHVzZSAuLi4NCiAgICA+DQog ICAgPiBUaGlzIGRpc2N1c3Npb24gdG9waWMgaXMgb25lIHdlIG5lZWQgdG8gcmVzb2x2ZS4gIFdl IGNhbiBzdGFydCBoZXJlIG9uIA0KICAgID4gdGhlIGxpc3QgYnV0IEknbGwgYWxzbyBhZGQgYSBz bG90IHRvIHRoZSBpbnRlcmltIG1lZXRpbmcgdG8gY29udGludWUgDQogICAgPiB0aGUNCiAgICBj b252ZXJzYXRpb24uDQogICAgPg0KICAgID4gUm9tYW4NCiAgICA+DQogICAgPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gRG90cyBtYWlsaW5n IGxpc3QNCiAgICA+IERvdHNAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG90cw0KICAgID4NCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBEb3RzIG1haWxpbmcgbGlzdA0KICAgID4g RG90c0BpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kb3RzDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCiAgICBEb3RzIG1haWxpbmcgbGlzdA0KICAgIERvdHNAaWV0Zi5vcmcNCiAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCiAgICANCiAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIERvdHMgbWFp bGluZyBsaXN0DQogICAgRG90c0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG90cw0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQogICAgRG90cyBtYWlsaW5nIGxpc3QNCiAgICBEb3RzQGll dGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQog ICAgDQoNCg== From nobody Wed Feb 22 07:57:40 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2EE129A48 for ; Wed, 22 Feb 2017 07:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=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 2-8cHZm7IGls for ; Wed, 22 Feb 2017 07:57:37 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 9EEE4129A5A for ; Wed, 22 Feb 2017 07:57:36 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.124.243.128; From: "Susan Hares" To: "'Teague, Nik'" , "'Clark, Gilbert J. \(GRC-LCA0\)'" , "'Tirumaleswar Reddy \(tireddy\)'" , "'Roman D. Danyliw'" , "'Mortensen, Andrew'" , References: <6AE56175-DBE7-4CD9-BA4E-5DCA88E901D8@arbor.net> <359EC4B99E040048A7131E0F4E113AFC0104F01D17@marathon> <5AE9F2D3F5799545818A4795DA145E7103BC588B@NDJSMBX201.ndc.nasa.gov> <5AE9F2D3F5799545818A4795DA145E7103BC595B@NDJSMBX201.ndc.nasa.gov> <00d501d28d13$3b0564f0$b1102ed0$@ndzh.com> <010a01d28d1b$0057c070$01074150$@ndzh.com> <9BB728BF-B3D5-4A8F-8C82-0EC87B7A59AE@verisign.com> In-Reply-To: <9BB728BF-B3D5-4A8F-8C82-0EC87B7A59AE@verisign.com> Date: Wed, 22 Feb 2017 10:53:06 -0500 Message-ID: <014f01d28d23$c2529710$46f7c530$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJmFW6DDzAmzfgGvVNa0u+cVn2h/AKLxGeiAr6R73ABz+0ANAEMF6loAdJol4QBzYxY9gHIa8Zdn+GanpA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Dots] use of restconf for the data channel? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 15:57:39 -0000 Nik:=20 This second message was to inform you of upcoming changes in NETCONF and = NETMOD work.=20 Here's the take away:=20 1) NETMOD's revision of data store design allows Yang support for = control plane protocols (E.g. DOTS signal), and the traditional = configuration (E.g. NETCONF/RESTCONF configuration for the DOTS bulk = protocol)=20 2) Events and publication/subscription functionality in NETCONF/NETMO is = something you should review - ODL has open-source code 3) Other control plane protocols (E.g. I2RS or I2NSF) will want to use = CoAP below the event stream with minimal additional layers=20 Perhaps working with them will help you determine what is common and = what is unique to DOTS signaling channels.=20 Sue=20 -----Original Message----- From: Teague, Nik [mailto:nteague@verisign.com]=20 Sent: Wednesday, February 22, 2017 10:06 AM To: Susan Hares; 'Clark, Gilbert J. (GRC-LCA0)'; 'Tirumaleswar Reddy = (tireddy)'; 'Roman D. Danyliw'; 'Mortensen, Andrew'; dots@ietf.org Subject: Re: [Dots] use of restconf for the data channel? Sue hi, Are you detailing this still in the context of the DOTS data channel? = You mention DOTS signaling Thanks, -Nik On 22/02/2017, 14:50, "Dots on behalf of Susan Hares" = wrote: Gilbert and Tirumaleswar:=20 =20 Here are a few advanced on NETCONF/RESTCONF stack related to = upcoming changes.=20 =20 = -------------------------------------------------------------------------= --- ------------ Content (data models) ---> data stores (config, control plane, = dynamic configuration)=20 = -------------------------------------------------------------------------= --- -------------- Operations: NETCONF, RESTCONF=20 config + events + pub/sub=20 Upcoming operations: control plane state + dynamic config = (dhcp) =20 = -------------------------------------------------------------------------= --- --------------- CoAP (proposed for light-weight config/events, or streams)=20 --------------- |TLS| DLTS | -------------- |TCP|UDP | -------------- | IP | --------------- =20 The NETCONF/RESTCONF events are NETCONF and NETMOD Working = Documents. The signaling of events or publication streams may range from light = weight (I'm here, I'm attacked) to large streams. The events + publication/subscription streams requirements come from I2RS work = which desires these to be used for configuration and for control plane = protocols such as I2RS protocol. DOTS signaling could be another control = plane protocol. CoAPs does not yet support these events, but it could be = added. =20 =20 Why use this? The event notification and publication/subscription = stream have many of the same base mechanisms. ID, lifetime, policy-id, = sequencing numbers, and timeouts plus additional features to tune the level of = data transmission. Mitigation request/signaling requires status updates = at period intervals which could use the publication/subscription = channel that sends this information to multiple clients. A binary encoding of = the event/signal mechanism via CoAP would this efficient.=20 =20 One other thing to consider is the mixture of configuration/control = plane protocols. The NETMOD revised data stores = (https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/) describes the NETMOD architecture for the mixture of configuration = and control plane. The control plane protocol does not need to follow = the netconf/restconf operational rules - but can set their own rules = for validation of data. NETMOD plans to support Yang modification for = this point. =20 I hope this helps. We'll talk in a few minutes.=20 =20 Sue Hares=20 =20 -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Susan Hares Sent: Wednesday, February 22, 2017 8:55 AM To: 'Clark, Gilbert J. (GRC-LCA0)'; 'Tirumaleswar Reddy (tireddy)'; = 'Roman D. Danyliw'; 'Mortensen, Andrew'; dots@ietf.org Subject: Re: [Dots] use of restconf for the data channel? =20 Gilbert:=20 =20 Can you provide a bit more unpacking of the message here? NETCONF = or RESTCONF + Yang data models was the initial suggestion to allow = stable protocol plus the ability to rapidly change data models that form = the content of the bulk data channel. I sent a longish message to the = list around IETF 97 since you have questions, I will reformat this = message as an internet-draft and send it to the list this week.=20 =20 The Data channel requirements are: reliable transport, data privacy = and integrity, resource configuration (described in OP-07), data-004 = black-white list management. These are the basic design requirements for NETCONF/RESTCONF functionality. The specific resources, = black-list, or white-list management can be data models. =20 =20 There are four parts to NETCONF/RESTCONF protocol:=20 =20 Content -- data models=20 Messaging method (NETCONF: edit-config, get-config, RESTCONF/ PUT, = GET) =20 + new Event and = publication/subscription streams information =20 Messaging protocol (rpc/rpc-reply / secure http) =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Secure transport (TLS with X.509 certifications, DTLS + add ons) =20 Transport (TCP or UDP)=20 =20 Since all of the requirements for the secure transport are the same = (peer mutual authentication, message confidentiality, integrity and = authenticity, and message replay protection are the same as the DOTS requirements. = You may wish to change the messaging protocol (rpc/rpc-reply or RESTCONF = http) to protobufs. If so, I suggest you make that suggestion to the = I2NSF WG that will include it in its general changes suggested to NETCONF WG = and I2RS WG . The WGs would consider protobufs if there is a real use case. = =20 =20 If you want to change the message method to edit configuration, what = your alternative would be? If you are read, write, or updating you = configuration or white lists, this is what these protocols are built for. The = yang data models are tailored for user-readability. If you want to change = the new event publication and subscription, exactly what do you want to = change. As I will rapidly turn around a draft to answer your questions, = please let me know exactly what your concerns are.=20 =20 If you are looking for the a secure shim layer,=20 =20 Content -- data models=20 Messaging method (NETCONF: edit-config, get-config, RESTCONF/ PUT, = GET) =20 + new Event and = publication/subscription streams information =20 Messaging protocol (rpc/rpc-reply / secure http) (proposed: = protobufs) =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Secure session layer (for attack scenarios)=20 Secure transport (TLS with X.509 certifications, DTLS + add ons) =20 Transport (TCP or UDP =20 Bob Moskowitz and I have proposed one. If you use this, you may be = able to utilize a lighter weight upper layer.=20 =20 =20 Thanks for your comments,=20 =20 Sue Hares=20 =20 -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Clark, = Gilbert J. (GRC-LCA0) Sent: Wednesday, February 22, 2017 8:16 AM To: Tirumaleswar Reddy (tireddy); Roman D. Danyliw; Mortensen, = Andrew; dots@ietf.org Subject: Re: [Dots] use of restconf for the data channel? =20 Oh, neat: didn't realize RESTCONF graduated to an RFC. Looks like = it was pretty recent, but that is still a good thing and does alleviate one = of my concerns to an extent :) =20 "But for DOTS data channel RESTCONF is suitable" =20 Why is RESTCONF suitable for the data channel? Why was RESTCONF, specifically, chosen? What does it offer that might justify the implementation burden that it brings, and would therefore make it a compelling choice when compared to just building and documenting a = REST interface? If there are reasons to use it that justify the = complexity, then okay. I haven't seen these elements documented on the mailing list, = though (apologies if I missed them?), and I also didn't see them documented anywhere in the current draft. =20 =20 With this in mind, including text to explain what benefits RESTCONF = offers and explains *why* its adoption is important to the data channel = would go a long way to alleviate the concerns I have in this instance :) =20 I would also point out that the data-channel-04 draft still = references the restconf draft instead of the RFC [1] - that's something that should probably be corrected for a future revision of the draft, if it = hasn't already. =20 Cheers, Gilbert =20 [1] [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", draft-ietf-netconf-restconf-18 (work in progress), October 2016. ________________________________________ From: Tirumaleswar Reddy (tireddy) [tireddy@cisco.com] Sent: Wednesday, February 22, 2017 2:17 AM To: Clark, Gilbert J. (GRC-LCA0); Roman D. Danyliw; Mortensen, = Andrew; dots@ietf.org Subject: RE: use of restconf for the data channel? =20 NETCONF and RESTCONF are not both suitable for DOTS signal channel. But for DOTS data channel RESTCONF is suitable and RESTCONF is = already an RFC https://tools.ietf.org/html/rfc8040. Various products in the market already use RESTCONF (e.g. confd 6.3 http://www.tail-f.com/management-agent/) =20 -Tiru =20 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Clark, = Gilbert=20 > J. (GRC- > LCA0) > Sent: Wednesday, February 22, 2017 11:26 AM > To: Roman D. Danyliw ; Mortensen, Andrew=20 > ; dots@ietf.org > Subject: Re: [Dots] use of restconf for the data channel? > > Hi: > > My strongest objection to both NETCONF and RESTCONF were in the=20 > context of their consideration for use in the signal channel. > > I wouldn't personally vote to see NETCONF, specifically, used in=20 > either channel. > NETCONF can involve substantial implementation complexity to = support=20 > capabilities that, in the case of DOTS, seem to me to be of = marginal=20 > utility at best. > > The use of RESTCONF seems a little more reasonable to me here = since=20 > many of those implementation requirements are relaxed. > > I will note that adoption of RESTCONF will inflict a 100+ page=20 > not-yet-RFC as > (additional) required reading for anyone who wishes to implement a = > DOTS data channel from scratch. Also, note that the use of = RESTCONF=20 > would introduce a dependency on something that is still in=20 > development, and that therefore most likely hasn't yet been very = well=20 > tested and / or may be subject to change. > > Just offering some clarification on my original opinion(s), for = what=20 > that's worth. > > -Gilbert > _________________________________ > From: Dots [dots-bounces@ietf.org] on behalf of Roman D. Danyliw=20 > [rdd@cert.org] > Sent: Wednesday, February 15, 2017 9:51 AM > To: Mortensen, Andrew; dots@ietf.org > Subject: Re: [Dots] use of restconf for the data channel? > > > Subject: [Dots] use of restconf for the data channel? > > [snip] > > > > Since RESTCONF is now a concrete proposal, it seems worthwhile=20 > > continuing the debate ahead of the interim meeting. Are there=20 > > specific concerns in the WG regarding the use ... > > This discussion topic is one we need to resolve. We can start = here on=20 > the list but I'll also add a slot to the interim meeting to = continue=20 > the conversation. > > Roman > > _______________________________________________ > 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 =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 =20 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 From nobody Wed Feb 22 08:10:28 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3004E129A45 for ; Wed, 22 Feb 2017 08:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nasa.gov 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 1t7h-70oQkJa for ; Wed, 22 Feb 2017 08:10:24 -0800 (PST) Received: from ndmsvnpf104.ndc.nasa.gov (NDMSVNPF104.ndc.nasa.gov [198.117.0.154]) (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 D2DBC129A0E for ; Wed, 22 Feb 2017 08:10:23 -0800 (PST) X-Comment: SPF check N/A for local connections - client-ip=198.117.1.197; helo=ndjsppt103.ndc.nasa.gov; envelope-from=gilbert.j.clark@nasa.gov; receiver=dots@ietf.org DKIM-Filter: OpenDKIM Filter v2.11.0 ndmsvnpf104.ndc.nasa.gov 69090400BB4A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nasa.gov; s=letsgomars; t=1487779822; bh=Qm/FlgzVe42UDID83ygdsw4U+N+Ms+InhdruqFYi+fA=; h=From:To:Subject:Date:References:In-Reply-To:From; b=OVTOoGHh6a+xBN1qoGVmPONi/vqLwYKKxKLndF4WLOAxXIG4ONeSMGhfKufrdbNwe Z4Rktnx8hcu35a6iP/oSydsOzpKXqvqID/HpainJSSwUBc5eBUfGNph3PE8tRivV1d 3K+3pZ0f71cTWwrIhY+6vuv7QxqbosbEv1/GXpKzii6GwVK0406b7hVw75iENdktFY ob2Rj1ITIu6D0IFliDnuylfCjRGVz3B2dnsjFRRsj9igjBhda0WBHDEseikUkOS67M TOMDBn9akvxs4HF63mNLZHuexWxMxxn8TABf56MAlREMvfpSRXxjMVuxNOKguvsOcq Z68tXedsogVtg== Received: from ndjsppt103.ndc.nasa.gov (ndjsppt103.ndc.nasa.gov [198.117.1.197]) by ndmsvnpf104.ndc.nasa.gov (Postfix) with ESMTP id 69090400BB4A; Wed, 22 Feb 2017 10:10:22 -0600 (CST) Received: from pps.filterd (ndjsppt103.ndc.nasa.gov [127.0.0.1]) by ndjsppt103.ndc.nasa.gov (8.16.0.20/8.16.0.20) with SMTP id v1MG7wKd026897; Wed, 22 Feb 2017 10:10:22 -0600 Received: from ndjscht103.ndc.nasa.gov (ndjscht103-pub.ndc.nasa.gov [198.117.1.203]) by ndjsppt103.ndc.nasa.gov with ESMTP id 28sbhw8t39-1; Wed, 22 Feb 2017 10:10:22 -0600 Received: from NDJSMBX201.ndc.nasa.gov ([169.254.4.228]) by NDJSCHT103.ndc.nasa.gov ([198.117.1.173]) with mapi id 14.03.0319.002; Wed, 22 Feb 2017 10:10:21 -0600 From: "Clark, Gilbert J. (GRC-LCA0)" To: "Teague, Nik" , Susan Hares , "'Tirumaleswar Reddy (tireddy)'" , "'Roman D. Danyliw'" , "'Mortensen, Andrew'" , "dots@ietf.org" Thread-Topic: [Dots] use of restconf for the data channel? Thread-Index: AQHShUvelq2Fax0X1U+DAQQ/dairhqFqKpDAgApPffGAADEigIAAW2c4gAB5zACAAA+aAIAABGSA//+d640= Date: Wed, 22 Feb 2017 16:10:21 +0000 Message-ID: <5AE9F2D3F5799545818A4795DA145E7103BC5B30@NDJSMBX201.ndc.nasa.gov> References: <6AE56175-DBE7-4CD9-BA4E-5DCA88E901D8@arbor.net> <359EC4B99E040048A7131E0F4E113AFC0104F01D17@marathon> <5AE9F2D3F5799545818A4795DA145E7103BC588B@NDJSMBX201.ndc.nasa.gov> <5AE9F2D3F5799545818A4795DA145E7103BC595B@NDJSMBX201.ndc.nasa.gov> <00d501d28d13$3b0564f0$b1102ed0$@ndzh.com> <010a01d28d1b$0057c070$01074150$@ndzh.com>, <9BB728BF-B3D5-4A8F-8C82-0EC87B7A59AE@verisign.com> In-Reply-To: <9BB728BF-B3D5-4A8F-8C82-0EC87B7A59AE@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [107.77.194.209] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-22_10:, , signatures=0 Archived-At: Subject: Re: [Dots] use of restconf for the data channel? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 16:10:26 -0000 Hi:=0A= =0A= Just as an addendum, I unfortunately can't make the meeting.=0A= =0A= I don't notice a notable distinction between RESTCONF and NETCONF in this d= iscussion thus far, which I find to be concerning to an extent. The two ar= e not the same, and should therefore be considered separately based on the = merits and suitability of each. I also think that upcoming features in NET= CONF is really orthogonal to the conversation here: I'm sure NETCONF has a = number of features that could possibly be useful. Instead, my question is = whether NETCONF's implementation, configuration, and runtime complexity jus= tify its use.=0A= =0A= Also: revisiting the idea of using RESTCONF and / or NETCONF in the signali= ng channel should really be a separate conversation, in my opinion.=0A= =0A= I would also point out that the WG in general isn't going to be the primary= audience for a generalized DDoS solution. Instead, the challenge will be = twofold:=0A= =0A= * Convincing vendors that it's worth their while to implement what's develo= ped here as part of a generalized DDoS mitigation strategy. If people don'= t like it, they'll go standardize their own ... and while two generalized D= DoS mitigation protocols would still probably be an improvement to what exi= sts today, I also doubt that such would be the ideal outcome in the case of= DOTS.=0A= =0A= * Convincing operators that it's worth their while to use what the vendors = have developed. NETCONF has a unique set of connotations for the operators= I know (which are not necessarily always entirely positive), which means t= hat including it as a requirement for DOTS could immediately alienate anyon= e who doesn't like NETCONF. RESTCONF sounds close enough to NETCONF that i= t would, in all likelihood, have a similar effect. The way these things ar= e named might also beg the question of why a configuration protocol is a go= od choice for something billed as a data channel, which seems like it could= be a point of confusion to those reading through the specification.=0A= =0A= With this in mind, minimizing both implementation / configuration complexit= y and runtime requirements strike me as essential, especially for the signa= ling aspects of the protocol. I'd be concerned with NETCONF, in particular= , because it has a few elements that can make it tricky to implement (confi= guration locking, transaction support, an ability to parse XML, stuff like = that) and can lead to relatively high runtime requirements (for some defini= tion of relatively high). To my understanding, RESTCONF relaxes many of th= ese requirements, and operates in a manner that is widely understood, so it= seems like a better choice to me than NETCONF does. It does, however, s= till require the folks implementing the draft to first understand RESTCONF = before they can implement DOTS, which will add additional implementation co= st to the vendor writing the implementation, and could *possibly* make thin= gs more difficult for the operators to both initially configure the system = and troubleshoot issues when they come up.=0A= =0A= Really though, all I'm suggesting here is a little text to the data channel= draft in order to make the RESTCONF decision appear to be a little less ar= bitrary than I perceive it to be at the moment. Whether or not the authors= agree and choose to add said text is, of course, entirely up to them :)=0A= =0A= Cheers,=0A= Gilbert=0A= ________________________________________=0A= From: Teague, Nik [nteague@verisign.com]=0A= Sent: Wednesday, February 22, 2017 10:06 AM=0A= To: Susan Hares; Clark, Gilbert J. (GRC-LCA0); 'Tirumaleswar Reddy (tireddy= )'; 'Roman D. Danyliw'; 'Mortensen, Andrew'; dots@ietf.org=0A= Subject: Re: [Dots] use of restconf for the data channel?=0A= =0A= Sue hi,=0A= =0A= Are you detailing this still in the context of the DOTS data channel? You = mention DOTS signaling=0A= =0A= Thanks,=0A= =0A= -Nik=0A= =0A= On 22/02/2017, 14:50, "Dots on behalf of Susan Hares" wrote:=0A= =0A= Gilbert and Tirumaleswar:=0A= =0A= Here are a few advanced on NETCONF/RESTCONF stack related to upcoming= =0A= changes.=0A= =0A= -----------------------------------------------------------------------= -----=0A= ------------=0A= Content (data models) ---> data stores (config, control plane, dynamic= =0A= configuration)=0A= -----------------------------------------------------------------------= -----=0A= --------------=0A= Operations: NETCONF, RESTCONF=0A= config + events + pub/sub=0A= Upcoming operations: control plane state + dynamic config (dhcp)= =0A= -----------------------------------------------------------------------= -----=0A= ---------------=0A= CoAP (proposed for light-weight config/events, or streams)=0A= ---------------=0A= |TLS| DLTS |=0A= --------------=0A= |TCP|UDP |=0A= --------------=0A= | IP |=0A= ---------------=0A= =0A= The NETCONF/RESTCONF events are NETCONF and NETMOD Working Documents. = The=0A= signaling of events or publication streams may range from light weight = (I'm=0A= here, I'm attacked) to large streams. The events +=0A= publication/subscription streams requirements come from I2RS work which= =0A= desires these to be used for configuration and for control plane protoc= ols=0A= such as I2RS protocol. DOTS signaling could be another control plane= =0A= protocol. CoAPs does not yet support these events, but it could be add= ed.=0A= =0A= =0A= Why use this? The event notification and publication/subscription stre= am=0A= have many of the same base mechanisms. ID, lifetime, policy-id, sequenc= ing=0A= numbers, and timeouts plus additional features to tune the level of dat= a=0A= transmission. Mitigation request/signaling requires status updates at= =0A= period intervals which could use the publication/subscription channel t= hat=0A= sends this information to multiple clients. A binary encoding of the= =0A= event/signal mechanism via CoAP would this efficient.=0A= =0A= One other thing to consider is the mixture of configuration/control pla= ne=0A= protocols. The NETMOD revised data stores=0A= (https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/= )=0A= describes the NETMOD architecture for the mixture of configuration and= =0A= control plane. The control plane protocol does not need to follow th= e=0A= netconf/restconf operational rules - but can set their own rules for= =0A= validation of data. NETMOD plans to support Yang modification for thi= s=0A= point.=0A= =0A= I hope this helps. We'll talk in a few minutes.=0A= =0A= Sue Hares=0A= =0A= -----Original Message-----=0A= From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Susan Hares=0A= Sent: Wednesday, February 22, 2017 8:55 AM=0A= To: 'Clark, Gilbert J. (GRC-LCA0)'; 'Tirumaleswar Reddy (tireddy)'; 'Ro= man=0A= D. Danyliw'; 'Mortensen, Andrew'; dots@ietf.org=0A= Subject: Re: [Dots] use of restconf for the data channel?=0A= =0A= Gilbert:=0A= =0A= Can you provide a bit more unpacking of the message here? NETCONF or= =0A= RESTCONF + Yang data models was the initial suggestion to allow stable= =0A= protocol plus the ability to rapidly change data models that form the= =0A= content of the bulk data channel. I sent a longish message to the list= =0A= around IETF 97 since you have questions, I will reformat this message a= s an=0A= internet-draft and send it to the list this week.=0A= =0A= The Data channel requirements are: reliable transport, data privacy an= d=0A= integrity, resource configuration (described in OP-07), data-004 black-= white=0A= list management. These are the basic design requirements for=0A= NETCONF/RESTCONF functionality. The specific resources, black-list, o= r=0A= white-list management can be data models.=0A= =0A= There are four parts to NETCONF/RESTCONF protocol:=0A= =0A= Content -- data models=0A= Messaging method (NETCONF: edit-config, get-config, RESTCONF/ PUT, GET= )=0A= + new Event and publication/subscriptio= n=0A= streams information=0A= Messaging protocol (rpc/rpc-reply / secure http)=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= Secure transport (TLS with X.509 certifications, DTLS + add ons)=0A= Transport (TCP or UDP)=0A= =0A= Since all of the requirements for the secure transport are the same (pe= er=0A= mutual authentication, message confidentiality, integrity and authentic= ity,=0A= and message replay protection are the same as the DOTS requirements. = You=0A= may wish to change the messaging protocol (rpc/rpc-reply or RESTCONF ht= tp)=0A= to protobufs. If so, I suggest you make that suggestion to the I2NSF W= G=0A= that will include it in its general changes suggested to NETCONF WG and= I2RS=0A= WG . The WGs would consider protobufs if there is a real use case.=0A= =0A= If you want to change the message method to edit configuration, what yo= ur=0A= alternative would be? If you are read, write, or updating you configur= ation=0A= or white lists, this is what these protocols are built for. The yang = data=0A= models are tailored for user-readability. If you want to change the n= ew=0A= event publication and subscription, exactly what do you want to change= .=0A= As I will rapidly turn around a draft to answer your questions, please = let=0A= me know exactly what your concerns are.=0A= =0A= If you are looking for the a secure shim layer,=0A= =0A= Content -- data models=0A= Messaging method (NETCONF: edit-config, get-config, RESTCONF/ PUT, GET= )=0A= + new Event and publication/subscriptio= n=0A= streams information=0A= Messaging protocol (rpc/rpc-reply / secure http) (proposed: protobufs)= =0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= Secure session layer (for attack scenarios)=0A= Secure transport (TLS with X.509 certifications, DTLS + add ons)=0A= Transport (TCP or UDP=0A= =0A= Bob Moskowitz and I have proposed one. If you use this, you may be abl= e to=0A= utilize a lighter weight upper layer.=0A= =0A= =0A= Thanks for your comments,=0A= =0A= Sue Hares=0A= =0A= -----Original Message-----=0A= From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Clark, Gilbert J= .=0A= (GRC-LCA0)=0A= Sent: Wednesday, February 22, 2017 8:16 AM=0A= To: Tirumaleswar Reddy (tireddy); Roman D. Danyliw; Mortensen, Andrew;= =0A= dots@ietf.org=0A= Subject: Re: [Dots] use of restconf for the data channel?=0A= =0A= Oh, neat: didn't realize RESTCONF graduated to an RFC. Looks like it w= as=0A= pretty recent, but that is still a good thing and does alleviate one of= my=0A= concerns to an extent :)=0A= =0A= "But for DOTS data channel RESTCONF is suitable"=0A= =0A= Why is RESTCONF suitable for the data channel? Why was RESTCONF,=0A= specifically, chosen? What does it offer that might justify the=0A= implementation burden that it brings, and would therefore make it a=0A= compelling choice when compared to just building and documenting a REST= =0A= interface? If there are reasons to use it that justify the complexity,= then=0A= okay. I haven't seen these elements documented on the mailing list, th= ough=0A= (apologies if I missed them?), and I also didn't see them documented=0A= anywhere in the current draft.=0A= =0A= With this in mind, including text to explain what benefits RESTCONF off= ers=0A= and explains *why* its adoption is important to the data channel would = go a=0A= long way to alleviate the concerns I have in this instance :)=0A= =0A= I would also point out that the data-channel-04 draft still references = the=0A= restconf draft instead of the RFC [1] - that's something that should=0A= probably be corrected for a future revision of the draft, if it hasn't= =0A= already.=0A= =0A= Cheers,=0A= Gilbert=0A= =0A= [1] [I-D.ietf-netconf-restconf]=0A= Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF=0A= Protocol", draft-ietf-netconf-restconf-18 (work in=0A= progress), October 2016.=0A= ________________________________________=0A= From: Tirumaleswar Reddy (tireddy) [tireddy@cisco.com]=0A= Sent: Wednesday, February 22, 2017 2:17 AM=0A= To: Clark, Gilbert J. (GRC-LCA0); Roman D. Danyliw; Mortensen, Andrew;= =0A= dots@ietf.org=0A= Subject: RE: use of restconf for the data channel?=0A= =0A= NETCONF and RESTCONF are not both suitable for DOTS signal channel.=0A= But for DOTS data channel RESTCONF is suitable and RESTCONF is already = an=0A= RFC https://tools.ietf.org/html/rfc8040.=0A= Various products in the market already use RESTCONF (e.g. confd 6.3=0A= http://www.tail-f.com/management-agent/)=0A= =0A= -Tiru=0A= =0A= > -----Original Message-----=0A= > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Clark, Gilbert= =0A= > J. (GRC-=0A= > LCA0)=0A= > Sent: Wednesday, February 22, 2017 11:26 AM=0A= > To: Roman D. Danyliw ; Mortensen, Andrew=0A= > ; dots@ietf.org=0A= > Subject: Re: [Dots] use of restconf for the data channel?=0A= >=0A= > Hi:=0A= >=0A= > My strongest objection to both NETCONF and RESTCONF were in the=0A= > context of their consideration for use in the signal channel.=0A= >=0A= > I wouldn't personally vote to see NETCONF, specifically, used in=0A= > either=0A= channel.=0A= > NETCONF can involve substantial implementation complexity to support= =0A= > capabilities that, in the case of DOTS, seem to me to be of marginal= =0A= > utility at best.=0A= >=0A= > The use of RESTCONF seems a little more reasonable to me here since= =0A= > many of those implementation requirements are relaxed.=0A= >=0A= > I will note that adoption of RESTCONF will inflict a 100+ page=0A= > not-yet-RFC as=0A= > (additional) required reading for anyone who wishes to implement a=0A= > DOTS data channel from scratch. Also, note that the use of RESTCONF= =0A= > would introduce a dependency on something that is still in=0A= > development, and that therefore most likely hasn't yet been very well= =0A= > tested and / or may be subject to change.=0A= >=0A= > Just offering some clarification on my original opinion(s), for what= =0A= > that's worth.=0A= >=0A= > -Gilbert=0A= > _________________________________=0A= > From: Dots [dots-bounces@ietf.org] on behalf of Roman D. Danyliw=0A= > [rdd@cert.org]=0A= > Sent: Wednesday, February 15, 2017 9:51 AM=0A= > To: Mortensen, Andrew; dots@ietf.org=0A= > Subject: Re: [Dots] use of restconf for the data channel?=0A= >=0A= > > Subject: [Dots] use of restconf for the data channel?=0A= > > [snip]=0A= > >=0A= > > Since RESTCONF is now a concrete proposal, it seems worthwhile=0A= > > continuing the debate ahead of the interim meeting. Are there=0A= > > specific concerns in the WG regarding the use ...=0A= >=0A= > This discussion topic is one we need to resolve. We can start here o= n=0A= > the list but I'll also add a slot to the interim meeting to continue= =0A= > the=0A= conversation.=0A= >=0A= > Roman=0A= >=0A= > _______________________________________________=0A= > Dots mailing list=0A= > Dots@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/dots=0A= >=0A= > _______________________________________________=0A= > Dots mailing list=0A= > Dots@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/dots=0A= =0A= _______________________________________________=0A= Dots mailing list=0A= Dots@ietf.org=0A= https://www.ietf.org/mailman/listinfo/dots=0A= =0A= _______________________________________________=0A= Dots mailing list=0A= Dots@ietf.org=0A= https://www.ietf.org/mailman/listinfo/dots=0A= =0A= _______________________________________________=0A= Dots mailing list=0A= Dots@ietf.org=0A= https://www.ietf.org/mailman/listinfo/dots=0A= =0A= =0A= From nobody Wed Feb 22 08:23:57 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D82129A0E for ; Wed, 22 Feb 2017 08:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.256 X-Spam-Level: X-Spam-Status: No, score=-1.256 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 qO5K9zaqj2a9 for ; Wed, 22 Feb 2017 08:23:55 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC7B9129A39 for ; Wed, 22 Feb 2017 08:23:54 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0319.002; Wed, 22 Feb 2017 11:23:53 -0500 From: Dave Dolson To: "Tirumaleswar Reddy (tireddy)" , "dots@ietf.org" Thread-Topic: New Version Notification for draft-reddy-dots-signal-channel-08.txt Thread-Index: AQHSjCCkIbjO+MzHWE6MQfNQQhzR96FzMYZQgADQiUCAAJ2nMIAAlop7 Date: Wed, 22 Feb 2017 16:23:53 +0000 Message-ID: References: <148766749366.32553.4722816219476780947.idtracker@ietfa.amsl.com> <68781b8926724ea9ad41230aeb94b1a0@XCH-ALN-017.cisco.com> , <213d4ddabdb1441495ce430aa7da8d69@XCH-RCD-017.cisco.com> In-Reply-To: <213d4ddabdb1441495ce430aa7da8d69@XCH-RCD-017.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.142.9] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] New Version Notification for draft-reddy-dots-signal-channel-08.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 16:23:56 -0000 I think my point was missed.=0A= See inline [DD]=0A= =0A= ________________________________________=0A= From: Tirumaleswar Reddy (tireddy) [tireddy@cisco.com]=0A= Sent: Wednesday, February 22, 2017 3:55 AM=0A= To: Dave Dolson; dots@ietf.org=0A= Subject: RE: New Version Notification for draft-reddy-dots-signal-channel-0= 8.txt=0A= =0A= > -----Original Message-----=0A= > From: Dave Dolson [mailto:ddolson@sandvine.com]=0A= > Sent: Wednesday, February 22, 2017 3:35 AM=0A= > To: Tirumaleswar Reddy (tireddy) ; dots@ietf.org=0A= > Subject: RE: New Version Notification for draft-reddy-dots-signal-channel= -=0A= > 08.txt=0A= >=0A= > On the topic of "Happy Eyeballs" (although I think this is a misnomer),= =0A= =0A= Why "Happy Eyeballs" is used by most browsers today https://tools.ietf.org/= html/rfc6555 and MIF WG is also using "Happy Eyeballs" technique (see https= ://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-11).=0A= [DD] I said "misnomer" because although people look at browsers (with their= eyeballs), dots protocol is not for human eyeballs. But I'm being pedantic= :-)=0A= =0A= > I believe=0A= > the intent would be to use the same policy-id in each of the transports, = to=0A= > detect duplicates at the server, correct?=0A= =0A= No. The use of "Happy Eyeballs" is test and pick a transport using which TL= S or DTLS session can be established with the DOTS server (UDP has higher p= recedence than TCP).=0A= Once the session is established on a specific transport, there is no need t= o send the mitigation request on both the transports.=0A= [DD] Although the client desires only one request, if two sessions are init= iated simultaneously, both *might* succeed. My point is that the server sho= uld be able to identify the duplicate -- and I think the "policy-id" field = would be the mechanism to detect duplicates, correct?=0A= =0A= > The document should say so. (Or if not, explain how duplicates are to be= =0A= > detected.)=0A= >=0A= >=0A= > Also, has thought been given to preventing replay attacks? E.g., malicio= usly=0A= > asking for mitigation by replaying a captured mitigation request?=0A= =0A= DTLS is capable of detecting replay attacks, see https://tools.ietf.org/htm= l/rfc6347#section-3.3. I will update the draft to say Replay Detection usin= g DTLS is mandatory for DOTS agents.=0A= =0A= -Tiru=0A= =0A= >=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy= =0A= > (tireddy)=0A= > Sent: Tuesday, February 21, 2017 4:31 AM=0A= > To: dots@ietf.org=0A= > Subject: Re: [Dots] New Version Notification for draft-reddy-dots-signal-= =0A= > channel-08.txt=0A= >=0A= > This revision https://tools.ietf.org/html/draft-reddy-dots-signal-channel= -08=0A= > addresses comments from Ehud and Kaname.=0A= >=0A= > Major changes are:=0A= >=0A= > 1)DOTS mitigation request/response are marked as non-confirmable=0A= > messages. Requests marked by the DOTS client as Non-confirmable messages= =0A= > are sent at regular intervals until a response is received from the DOTS = server=0A= > (See Section 5.3 for more details).=0A= >=0A= > (Thanks to the feedback from Flemming, Andrew and Ehud).=0A= >=0A= > 2)Added support for vendor specific parameters.=0A= >=0A= > 3)Added new Mitigation status parameters: bytes_dropped, bps_dropped,=0A= > pkts_dropped and pps_dropped.=0A= >=0A= > Comments and suggestions are welcome.=0A= >=0A= > -Tiru=0A= >=0A= >=0A= > > -----Original Message-----=0A= > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=0A= > > Sent: Tuesday, February 21, 2017 2:28 PM=0A= > > To: Prashanth Patil (praspati) ; Mohamed Boucadair= =0A= > > ; Tirumaleswar Reddy (tireddy)=0A= > > =0A= > > Subject: New Version Notification for=0A= > > draft-reddy-dots-signal-channel-08.txt=0A= > >=0A= > >=0A= > > A new version of I-D, draft-reddy-dots-signal-channel-08.txt=0A= > > has been successfully submitted by Tirumaleswar Reddy and posted to=0A= > > the IETF repository.=0A= > >=0A= > > Name: draft-reddy-dots-signal-channel=0A= > > Revision: 08=0A= > > Title: Distributed Denial-of-Service Open Threat Signaling= (DOTS)=0A= > > Signal Channel=0A= > > Document date: 2017-02-21=0A= > > Group: Individual Submission=0A= > > Pages: 46=0A= > > URL: https://www.ietf.org/internet-drafts/draft-reddy-dots-s= ignal-=0A= > > channel-08.txt=0A= > > Status: https://datatracker.ietf.org/doc/draft-reddy-dots-signa= l-=0A= > channel/=0A= > > Htmlized: https://tools.ietf.org/html/draft-reddy-dots-signal-cha= nnel-08=0A= > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-dots-si= gnal-=0A= > channel-=0A= > > 08=0A= > >=0A= > > Abstract:=0A= > > This document specifies a mechanism that a DOTS client can use to=0A= > > signal that a network is under a Distributed Denial-of-Service (DDoS= )=0A= > > attack to an upstream DOTS server so that appropriate mitigation=0A= > > actions are undertaken (including, blackhole, drop, rate-limit, or= =0A= > > add to watch list) on the suspect traffic. The document specifies= =0A= > > the DOTS signal channel including Happy Eyeballs considerations. Th= e=0A= > > specification of the DOTS data channel is elaborated in a companion= =0A= > > document.=0A= > >=0A= > >=0A= > >=0A= > >=0A= > > Please note that it may take a couple of minutes from the time of=0A= > > submission until the htmlized version and diff are available at tools.i= etf.org.=0A= > >=0A= > > The IETF Secretariat=0A= >=0A= > _______________________________________________=0A= > Dots mailing list=0A= > Dots@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/dots=0A= From nobody Wed Feb 22 18:14:36 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBEE1294DB for ; Wed, 22 Feb 2017 18:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 RWH_EZKYLbeQ for ; Wed, 22 Feb 2017 18:14:33 -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 CA95E1294C9 for ; Wed, 22 Feb 2017 18:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6349; q=dns/txt; s=iport; t=1487816072; x=1489025672; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=9mn58MqR8GQX9xLzbIccfev0MW4Hl2obQqjxmDSFnb0=; b=SISa6Pkc0qPHtECPfFA16g1r7HYQEdhnXa+qpX4Jq3xNgkKtqcWmKbUL P64VHBtDRkg5wh3VpImKcAlsSNel2RG5cvRLAmXwrXOiHphUua5ByZlTY nrovaGpDWGI/SbvwlX/X07nPCcwmohutgPL86eb4cgH/U0Ygt4ZmIIAQQ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQA4Ra5Y/4YNJK1TAQkZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDJylhgQkHjVyRWpU0gg0fC4V4AoMNPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?wAQEBAwEBATg0CQ4EAgEIDgMEAQEfCQcnCxQJCAIEARACCIllCA6xTYtLAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWGTIRvgxeBFQEEDYV7BY9MjEQBhnOLJoIEhRy?= =?us-ascii?q?JeYg1im8BHziBAFQVGCaESx2BYUMyAYkIAQYfgQqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,197,1484006400"; d="scan'208";a="211919102" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Feb 2017 02:14:18 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v1N2EIKf028775 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Feb 2017 02:14:18 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.1210.3; Wed, 22 Feb 2017 20:14:17 -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.1210.000; Wed, 22 Feb 2017 20:14:17 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Dave Dolson , "dots@ietf.org" Thread-Topic: New Version Notification for draft-reddy-dots-signal-channel-08.txt Thread-Index: AQHSjCCkIbjO+MzHWE6MQfNQQhzR96FzMYZQgADQiUCAAJ2nMIAAlop7gAClV9A= Date: Thu, 23 Feb 2017 02:14:17 +0000 Message-ID: <12bb7f28fe654aa1912dabf00f0ff07d@XCH-RCD-017.cisco.com> References: <148766749366.32553.4722816219476780947.idtracker@ietfa.amsl.com> <68781b8926724ea9ad41230aeb94b1a0@XCH-ALN-017.cisco.com> , <213d4ddabdb1441495ce430aa7da8d69@XCH-RCD-017.cisco.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.65.72.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] New Version Notification for draft-reddy-dots-signal-channel-08.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 23 Feb 2017 02:14:35 -0000 > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Wednesday, February 22, 2017 9:54 PM > To: Tirumaleswar Reddy (tireddy) ; dots@ietf.org > Subject: RE: New Version Notification for draft-reddy-dots-signal-channel= - > 08.txt >=20 > I think my point was missed. > See inline [DD] >=20 > ________________________________________ > From: Tirumaleswar Reddy (tireddy) [tireddy@cisco.com] > Sent: Wednesday, February 22, 2017 3:55 AM > To: Dave Dolson; dots@ietf.org > Subject: RE: New Version Notification for draft-reddy-dots-signal-channel= - > 08.txt >=20 > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: Wednesday, February 22, 2017 3:35 AM > > To: Tirumaleswar Reddy (tireddy) ; dots@ietf.org > > Subject: RE: New Version Notification for > > draft-reddy-dots-signal-channel- 08.txt > > > > On the topic of "Happy Eyeballs" (although I think this is a > > misnomer), >=20 > Why "Happy Eyeballs" is used by most browsers today > https://tools.ietf.org/html/rfc6555 and MIF WG is also using "Happy Eyeba= lls" > technique (see https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs- > extension-11). > [DD] I said "misnomer" because although people look at browsers (with the= ir > eyeballs), dots protocol is not for human eyeballs. But I'm being pedanti= c :-) >=20 > > I believe > > the intent would be to use the same policy-id in each of the > > transports, to detect duplicates at the server, correct? >=20 > No. The use of "Happy Eyeballs" is test and pick a transport using which = TLS or > DTLS session can be established with the DOTS server (UDP has higher > precedence than TCP). > Once the session is established on a specific transport, there is no need= to > send the mitigation request on both the transports. > [DD] Although the client desires only one request, if two sessions are in= itiated > simultaneously, both *might* succeed. My point is that the server should = be > able to identify the duplicate -- and I think the "policy-id" field would= be the > mechanism to detect duplicates, correct ? Yes, you are correct. The DOTS client identity will be used to check if the= client has transmitted the same policy-id=20 over a different transport and also to detect duplicates in a DTLS session = over UDP. I will update the draft to clarify. Cheers, -Tiru >=20 > > The document should say so. (Or if not, explain how duplicates are to > > be > > detected.) > > > > > > Also, has thought been given to preventing replay attacks? E.g., > > maliciously asking for mitigation by replaying a captured mitigation re= quest? >=20 > DTLS is capable of detecting replay attacks, see > https://tools.ietf.org/html/rfc6347#section-3.3. I will update the draft = to say > Replay Detection using DTLS is mandatory for DOTS agents. >=20 > -Tiru >=20 > > > > > > > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Tirumaleswar > > Reddy > > (tireddy) > > Sent: Tuesday, February 21, 2017 4:31 AM > > To: dots@ietf.org > > Subject: Re: [Dots] New Version Notification for > > draft-reddy-dots-signal- channel-08.txt > > > > This revision > > https://tools.ietf.org/html/draft-reddy-dots-signal-channel-08 > > addresses comments from Ehud and Kaname. > > > > Major changes are: > > > > 1)DOTS mitigation request/response are marked as non-confirmable > > messages. Requests marked by the DOTS client as Non-confirmable > > messages are sent at regular intervals until a response is received > > from the DOTS server (See Section 5.3 for more details). > > > > (Thanks to the feedback from Flemming, Andrew and Ehud). > > > > 2)Added support for vendor specific parameters. > > > > 3)Added new Mitigation status parameters: bytes_dropped, bps_dropped, > > pkts_dropped and pps_dropped. > > > > Comments and suggestions are welcome. > > > > -Tiru > > > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: Tuesday, February 21, 2017 2:28 PM > > > To: Prashanth Patil (praspati) ; Mohamed > > > Boucadair ; Tirumaleswar Reddy > > > (tireddy) > > > Subject: New Version Notification for > > > draft-reddy-dots-signal-channel-08.txt > > > > > > > > > A new version of I-D, draft-reddy-dots-signal-channel-08.txt > > > has been successfully submitted by Tirumaleswar Reddy and posted to > > > the IETF repository. > > > > > > Name: draft-reddy-dots-signal-channel > > > Revision: 08 > > > Title: Distributed Denial-of-Service Open Threat Signali= ng (DOTS) > > > Signal Channel > > > Document date: 2017-02-21 > > > Group: Individual Submission > > > Pages: 46 > > > URL: https://www.ietf.org/internet-drafts/draft-reddy-dots= -signal- > > > channel-08.txt > > > Status: https://datatracker.ietf.org/doc/draft-reddy-dots-sig= nal- > > channel/ > > > Htmlized: https://tools.ietf.org/html/draft-reddy-dots-signal-c= hannel- > 08 > > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-dots-= signal- > > channel- > > > 08 > > > > > > Abstract: > > > This document specifies a mechanism that a DOTS client can use to > > > signal that a network is under a Distributed Denial-of-Service (DD= oS) > > > attack to an upstream DOTS server so that appropriate mitigation > > > actions are undertaken (including, blackhole, drop, rate-limit, or > > > add to watch list) on the suspect traffic. The document specifies > > > the DOTS signal channel including Happy Eyeballs considerations. = The > > > specification of the DOTS data channel is elaborated in a companio= n > > > document. > > > > > > > > > > > > > > > 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 From nobody Wed Feb 22 19:40:55 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75825129F99 for ; Wed, 22 Feb 2017 19:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ELr-D761GGo9 for ; Wed, 22 Feb 2017 19:40:51 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84310129F95 for ; Wed, 22 Feb 2017 19:40:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17623; q=dns/txt; s=iport; t=1487821251; x=1489030851; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PbsfQCwhqiW0gFWgRNUX1KTo2b5q/ULTAbfbV5y7gFA=; b=VmtAKn+tOwSFNXyXqPDadhbhRsm+cXRr2Js1iHSx+q9wTXVkrELEJp7X WvbQbGB2e9eXFI8MsZjq47/zT/GF002zTXg7hylchZEbTuSSimwlxsbKp 8DtXW0Mz/valutqqDj0+F/MK/dCDOOBogSykgtpYP9DKWf6wCT3UMM2FC U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQBmWa5Y/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1BhgQkHjVyRWpU0gg0fC4V4AoMNPxgBAgEBAQEBAQFiKIRwAQE?= =?us-ascii?q?BBAEBJRM0FwQCAQgRAQMBAQENEQkHJwsUAwYIAgQBEggTh20DgWoOsHQ6i0oBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdhkyDZoEJijkFiRKSfgGGc4MigySEYIIEGIU?= =?us-ascii?q?Eg1GGKI8JhBsBHziBAFQVPoRLHYFhdQGJCiuBA4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,197,1484006400"; d="scan'208";a="214966875" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2017 03:40:47 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v1N3elrg018654 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Feb 2017 03:40:47 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.1210.3; Wed, 22 Feb 2017 21:40:46 -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.1210.000; Wed, 22 Feb 2017 21:40:46 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Clark, Gilbert J. (GRC-LCA0)" , "Teague, Nik" , Susan Hares , "'Roman D. Danyliw'" , "'Mortensen, Andrew'" , "dots@ietf.org" Thread-Topic: [Dots] use of restconf for the data channel? Thread-Index: AQHShUvelq2Fax0X1U+DAQQ/dairhqFqKpDAgApPffGAADEigIAAW2c4gAB5zACAAA+aAIAABGSA//+d642AAM+NIA== Date: Thu, 23 Feb 2017 03:40:46 +0000 Message-ID: References: <6AE56175-DBE7-4CD9-BA4E-5DCA88E901D8@arbor.net> <359EC4B99E040048A7131E0F4E113AFC0104F01D17@marathon> <5AE9F2D3F5799545818A4795DA145E7103BC588B@NDJSMBX201.ndc.nasa.gov> <5AE9F2D3F5799545818A4795DA145E7103BC595B@NDJSMBX201.ndc.nasa.gov> <00d501d28d13$3b0564f0$b1102ed0$@ndzh.com> <010a01d28d1b$0057c070$01074150$@ndzh.com>, <9BB728BF-B3D5-4A8F-8C82-0EC87B7A59AE@verisign.com> <5AE9F2D3F5799545818A4795DA145E7103BC5B30@NDJSMBX201.ndc.nasa.gov> In-Reply-To: <5AE9F2D3F5799545818A4795DA145E7103BC5B30@NDJSMBX201.ndc.nasa.gov> 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.72.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] use of restconf for the data channel? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 23 Feb 2017 03:40:54 -0000 Hi Gilbert, RESTCONF provides a simplified interface and only supports a subset of the = capabilities provided by NETCONF.=20 DOTS data channel does not need all the functionality of RESTCONF only a su= bset of it, please see https://tools.ietf.org/html/draft-reddy-dots-data-channel-04 for more d= etails. As you may already know, the REST-like API provided by RESTCONF is not inte= nded to replace NETCONF, but rather provide a=20 simplified interface, thereby meeting a need of application developers. I will add more details to the draft to discuss the reasons behind using RE= STCONF. -Tiru > -----Original Message----- > From: Clark, Gilbert J. (GRC-LCA0) [mailto:gilbert.j.clark@nasa.gov] > Sent: Wednesday, February 22, 2017 9:40 PM > To: Teague, Nik ; Susan Hares ; > Tirumaleswar Reddy (tireddy) ; 'Roman D. Danyliw' > ; 'Mortensen, Andrew' ; > dots@ietf.org > Subject: RE: [Dots] use of restconf for the data channel? >=20 > Hi: >=20 > Just as an addendum, I unfortunately can't make the meeting. >=20 > I don't notice a notable distinction between RESTCONF and NETCONF in this > discussion thus far, which I find to be concerning to an extent. The two= are > not the same, and should therefore be considered separately based on the > merits and suitability of each. I also think that upcoming features in N= ETCONF > is really orthogonal to the conversation here: I'm sure NETCONF has a num= ber > of features that could possibly be useful. Instead, my question is wheth= er > NETCONF's implementation, configuration, and runtime complexity justify i= ts > use. >=20 > Also: revisiting the idea of using RESTCONF and / or NETCONF in the signa= ling > channel should really be a separate conversation, in my opinion. >=20 > I would also point out that the WG in general isn't going to be the prima= ry > audience for a generalized DDoS solution. Instead, the challenge will be > twofold: >=20 > * Convincing vendors that it's worth their while to implement what's > developed here as part of a generalized DDoS mitigation strategy. If peo= ple > don't like it, they'll go standardize their own ... and while two general= ized > DDoS mitigation protocols would still probably be an improvement to what > exists today, I also doubt that such would be the ideal outcome in the ca= se of > DOTS. >=20 > * Convincing operators that it's worth their while to use what the vendor= s > have developed. NETCONF has a unique set of connotations for the operato= rs > I know (which are not necessarily always entirely positive), which means = that > including it as a requirement for DOTS could immediately alienate anyone = who > doesn't like NETCONF. RESTCONF sounds close enough to NETCONF that it > would, in all likelihood, have a similar effect. The way these things ar= e named > might also beg the question of why a configuration protocol is a good cho= ice > for something billed as a data channel, which seems like it could be a po= int of > confusion to those reading through the specification. >=20 > With this in mind, minimizing both implementation / configuration complex= ity > and runtime requirements strike me as essential, especially for the signa= ling > aspects of the protocol. I'd be concerned with NETCONF, in particular, > because it has a few elements that can make it tricky to implement > (configuration locking, transaction support, an ability to parse XML, stu= ff like > that) and can lead to relatively high runtime requirements (for some defi= nition > of relatively high). To my understanding, RESTCONF relaxes many of these > requirements, and operates in a manner that is widely understood, so it s= eems > like a better choice to me than NETCONF does. It does, however, still = require > the folks implementing the draft to first understand RESTCONF before they > can implement DOTS, which will add additional implementation cost to the > vendor writing the implementation, and could *possibly* make things more > difficult for the operators to both initially configure the system and > troubleshoot issues when they come up. >=20 > Really though, all I'm suggesting here is a little text to the data chann= el draft in > order to make the RESTCONF decision appear to be a little less arbitrary = than I > perceive it to be at the moment. Whether or not the authors agree and > choose to add said text is, of course, entirely up to them :) >=20 > Cheers, > Gilbert > ________________________________________ > From: Teague, Nik [nteague@verisign.com] > Sent: Wednesday, February 22, 2017 10:06 AM > To: Susan Hares; Clark, Gilbert J. (GRC-LCA0); 'Tirumaleswar Reddy (tired= dy)'; > 'Roman D. Danyliw'; 'Mortensen, Andrew'; dots@ietf.org > Subject: Re: [Dots] use of restconf for the data channel? >=20 > Sue hi, >=20 > Are you detailing this still in the context of the DOTS data channel? Yo= u > mention DOTS signaling >=20 > Thanks, >=20 > -Nik >=20 > On 22/02/2017, 14:50, "Dots on behalf of Susan Hares" bounces@ietf.org on behalf of shares@ndzh.com> wrote: >=20 > Gilbert and Tirumaleswar: >=20 > Here are a few advanced on NETCONF/RESTCONF stack related to upcoming > changes. >=20 > ---------------------------------------------------------------------= ------- > ------------ > Content (data models) ---> data stores (config, control plane, dynami= c > configuration) > ---------------------------------------------------------------------= ------- > -------------- > Operations: NETCONF, RESTCONF > config + events + pub/sub > Upcoming operations: control plane state + dynamic config (dhcp) > ---------------------------------------------------------------------= ------- > --------------- > CoAP (proposed for light-weight config/events, or streams) > --------------- > |TLS| DLTS | > -------------- > |TCP|UDP | > -------------- > | IP | > --------------- >=20 > The NETCONF/RESTCONF events are NETCONF and NETMOD Working > Documents. The > signaling of events or publication streams may range from light weigh= t (I'm > here, I'm attacked) to large streams. The events + > publication/subscription streams requirements come from I2RS work whi= ch > desires these to be used for configuration and for control plane prot= ocols > such as I2RS protocol. DOTS signaling could be another control plane > protocol. CoAPs does not yet support these events, but it could be a= dded. >=20 >=20 > Why use this? The event notification and publication/subscription st= ream > have many of the same base mechanisms. ID, lifetime, policy-id, seque= ncing > numbers, and timeouts plus additional features to tune the level of d= ata > transmission. Mitigation request/signaling requires status updates a= t > period intervals which could use the publication/subscription channel= that > sends this information to multiple clients. A binary encoding of t= he > event/signal mechanism via CoAP would this efficient. >=20 > One other thing to consider is the mixture of configuration/control p= lane > protocols. The NETMOD revised data stores > (https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastore= s/) > describes the NETMOD architecture for the mixture of configuration an= d > control plane. The control plane protocol does not need to follow = the > netconf/restconf operational rules - but can set their own rules for > validation of data. NETMOD plans to support Yang modification for t= his > point. >=20 > I hope this helps. We'll talk in a few minutes. >=20 > Sue Hares >=20 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Wednesday, February 22, 2017 8:55 AM > To: 'Clark, Gilbert J. (GRC-LCA0)'; 'Tirumaleswar Reddy (tireddy)'; '= Roman > D. Danyliw'; 'Mortensen, Andrew'; dots@ietf.org > Subject: Re: [Dots] use of restconf for the data channel? >=20 > Gilbert: >=20 > Can you provide a bit more unpacking of the message here? NETCONF = or > RESTCONF + Yang data models was the initial suggestion to allow stabl= e > protocol plus the ability to rapidly change data models that form the > content of the bulk data channel. I sent a longish message to the lis= t > around IETF 97 since you have questions, I will reformat this message= as an > internet-draft and send it to the list this week. >=20 > The Data channel requirements are: reliable transport, data privacy = and > integrity, resource configuration (described in OP-07), data-004 blac= k-white > list management. These are the basic design requirements for > NETCONF/RESTCONF functionality. The specific resources, black-list,= or > white-list management can be data models. >=20 > There are four parts to NETCONF/RESTCONF protocol: >=20 > Content -- data models > Messaging method (NETCONF: edit-config, get-config, RESTCONF/ PUT, > GET) > + new Event and publication/subscript= ion > streams information > Messaging protocol (rpc/rpc-reply / secure http) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Secure transport (TLS with X.509 certifications, DTLS + add ons) > Transport (TCP or UDP) >=20 > Since all of the requirements for the secure transport are the same (= peer > mutual authentication, message confidentiality, integrity and authent= icity, > and message replay protection are the same as the DOTS requirements. > You > may wish to change the messaging protocol (rpc/rpc-reply or RESTCONF > http) > to protobufs. If so, I suggest you make that suggestion to the I2NSF= WG > that will include it in its general changes suggested to NETCONF WG a= nd > I2RS > WG . The WGs would consider protobufs if there is a real use case. >=20 > If you want to change the message method to edit configuration, what = your > alternative would be? If you are read, write, or updating you config= uration > or white lists, this is what these protocols are built for. The yan= g data > models are tailored for user-readability. If you want to change the= new > event publication and subscription, exactly what do you want to chan= ge. > As I will rapidly turn around a draft to answer your questions, pleas= e let > me know exactly what your concerns are. >=20 > If you are looking for the a secure shim layer, >=20 > Content -- data models > Messaging method (NETCONF: edit-config, get-config, RESTCONF/ PUT, > GET) > + new Event and publication/subscript= ion > streams information > Messaging protocol (rpc/rpc-reply / secure http) (proposed: protobufs= ) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Secure session layer (for attack scenarios) > Secure transport (TLS with X.509 certifications, DTLS + add ons) > Transport (TCP or UDP >=20 > Bob Moskowitz and I have proposed one. If you use this, you may be a= ble to > utilize a lighter weight upper layer. >=20 >=20 > Thanks for your comments, >=20 > Sue Hares >=20 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Clark, Gilbert= J. > (GRC-LCA0) > Sent: Wednesday, February 22, 2017 8:16 AM > To: Tirumaleswar Reddy (tireddy); Roman D. Danyliw; Mortensen, Andrew= ; > dots@ietf.org > Subject: Re: [Dots] use of restconf for the data channel? >=20 > Oh, neat: didn't realize RESTCONF graduated to an RFC. Looks like it= was > pretty recent, but that is still a good thing and does alleviate one = of my > concerns to an extent :) >=20 > "But for DOTS data channel RESTCONF is suitable" >=20 > Why is RESTCONF suitable for the data channel? Why was RESTCONF, > specifically, chosen? What does it offer that might justify the > implementation burden that it brings, and would therefore make it a > compelling choice when compared to just building and documenting a RE= ST > interface? If there are reasons to use it that justify the complexit= y, then > okay. I haven't seen these elements documented on the mailing list, = though > (apologies if I missed them?), and I also didn't see them documented > anywhere in the current draft. >=20 > With this in mind, including text to explain what benefits RESTCONF o= ffers > and explains *why* its adoption is important to the data channel woul= d go a > long way to alleviate the concerns I have in this instance :) >=20 > I would also point out that the data-channel-04 draft still reference= s the > restconf draft instead of the RFC [1] - that's something that should > probably be corrected for a future revision of the draft, if it hasn'= t > already. >=20 > Cheers, > Gilbert >=20 > [1] [I-D.ietf-netconf-restconf] > Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF > Protocol", draft-ietf-netconf-restconf-18 (work in > progress), October 2016. > ________________________________________ > From: Tirumaleswar Reddy (tireddy) [tireddy@cisco.com] > Sent: Wednesday, February 22, 2017 2:17 AM > To: Clark, Gilbert J. (GRC-LCA0); Roman D. Danyliw; Mortensen, Andrew= ; > dots@ietf.org > Subject: RE: use of restconf for the data channel? >=20 > NETCONF and RESTCONF are not both suitable for DOTS signal channel. > But for DOTS data channel RESTCONF is suitable and RESTCONF is alread= y an > RFC https://tools.ietf.org/html/rfc8040. > Various products in the market already use RESTCONF (e.g. confd 6.3 > http://www.tail-f.com/management-agent/) >=20 > -Tiru >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Clark, Gilbe= rt > > J. (GRC- > > LCA0) > > Sent: Wednesday, February 22, 2017 11:26 AM > > To: Roman D. Danyliw ; Mortensen, Andrew > > ; dots@ietf.org > > Subject: Re: [Dots] use of restconf for the data channel? > > > > Hi: > > > > My strongest objection to both NETCONF and RESTCONF were in the > > context of their consideration for use in the signal channel. > > > > I wouldn't personally vote to see NETCONF, specifically, used in > > either > channel. > > NETCONF can involve substantial implementation complexity to suppor= t > > capabilities that, in the case of DOTS, seem to me to be of margina= l > > utility at best. > > > > The use of RESTCONF seems a little more reasonable to me here since > > many of those implementation requirements are relaxed. > > > > I will note that adoption of RESTCONF will inflict a 100+ page > > not-yet-RFC as > > (additional) required reading for anyone who wishes to implement a > > DOTS data channel from scratch. Also, note that the use of RESTCON= F > > would introduce a dependency on something that is still in > > development, and that therefore most likely hasn't yet been very we= ll > > tested and / or may be subject to change. > > > > Just offering some clarification on my original opinion(s), for wha= t > > that's worth. > > > > -Gilbert > > _________________________________ > > From: Dots [dots-bounces@ietf.org] on behalf of Roman D. Danyliw > > [rdd@cert.org] > > Sent: Wednesday, February 15, 2017 9:51 AM > > To: Mortensen, Andrew; dots@ietf.org > > Subject: Re: [Dots] use of restconf for the data channel? > > > > > Subject: [Dots] use of restconf for the data channel? > > > [snip] > > > > > > Since RESTCONF is now a concrete proposal, it seems worthwhile > > > continuing the debate ahead of the interim meeting. Are there > > > specific concerns in the WG regarding the use ... > > > > This discussion topic is one we need to resolve. We can start here= on > > the list but I'll also add a slot to the interim meeting to continu= e > > the > conversation. > > > > Roman > > > > _______________________________________________ > > 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 >=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 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots >=20 From nobody Wed Feb 22 19:59:01 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173D1129555 for ; Wed, 22 Feb 2017 19:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 lYrgiMq1307M for ; Wed, 22 Feb 2017 19:58:57 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7E5129554 for ; Wed, 22 Feb 2017 19:58:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12238; q=dns/txt; s=iport; t=1487822337; x=1489031937; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=nSSA5uhS+zgjY36EE5cVy2Am3fc5DOAZU+F50LHRjws=; b=T1XY7DB2l4kaKFkblDip4Onj8wpjChYGxcZmx2S/qsCXI6RfACA5K/Gr 1AeGkacPakUcFa7oiIOQtg4XwZhZJdAypSAPp/iUDWeE4dkguRD8Zo+VC gdLD1IOggiNUbjRRYAZv6CcgRq8Y0lhI86DLtpzE+AMU5iNJamxmmCtyW U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQCuXK5Y/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1BhgQkHjVyRWpU0gg0fC4V4AoMNPxgBAgEBAQEBAQFiKIRwAQE?= =?us-ascii?q?BAwEBASUTNBAHBAIBCA4DAQMBAQ4RCQcnCxQDBggCBAESCIllCA6wZjqLSwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2GTIRvhD6FewWJEpJ+AYZziyaCBIUcg1GGKI8?= =?us-ascii?q?JhBsBHziBAFQVPoZJdQGJCiuBA4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,197,1484006400"; d="scan'208";a="389290265" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Feb 2017 03:58:55 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v1N3wtSd004495 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Feb 2017 03:58:55 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.1210.3; Wed, 22 Feb 2017 21:58:54 -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.1210.000; Wed, 22 Feb 2017 21:58:54 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Susan Hares , "'Clark, Gilbert J. (GRC-LCA0)'" , "'Roman D. Danyliw'" , "'Mortensen, Andrew'" , "dots@ietf.org" Thread-Topic: [Dots] use of restconf for the data channel? Thread-Index: AQHShUvelq2Fax0X1U+DAQQ/dairhqFqKpDAgApPffGAADEigIAAW2c4gAB5zACAAA+aAIAAc8cQ Date: Thu, 23 Feb 2017 03:58:54 +0000 Message-ID: References: <6AE56175-DBE7-4CD9-BA4E-5DCA88E901D8@arbor.net>, <359EC4B99E040048A7131E0F4E113AFC0104F01D17@marathon> <5AE9F2D3F5799545818A4795DA145E7103BC588B@NDJSMBX201.ndc.nasa.gov>, <5AE9F2D3F5799545818A4795DA145E7103BC595B@NDJSMBX201.ndc.nasa.gov> <00d501d28d13$3b0564f0$b1102ed0$@ndzh.com> <010a01d28d1b$0057c070$01074150$@ndzh.com> In-Reply-To: <010a01d28d1b$0057c070$01074150$@ndzh.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.72.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] use of restconf for the data channel? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 23 Feb 2017 03:59:00 -0000 Hi Susan, Yes, I am aware of the below work. https://tools.ietf.org/html/draft-reddy-= dots-signal-channel-08 uses CoAP Observe option to receive unsolicited noti= fications on the mitigation status from the DOTS server. CoAP is also discu= ssed in CORE WG for managing constrained devices (see https://tools.ietf.or= g/html/draft-ietf-core-comi-00).=20 Just like COMI, reddy-dots-signal-channel-8 uses YANG and maps to CBOR to k= eep the message size small. But there are differences b/w COMI and DOTS sig= nal channel, the latter uses non-confirmable messages for DOTS mitigation r= equest/response. -Tiru > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Wednesday, February 22, 2017 8:20 PM > To: 'Clark, Gilbert J. (GRC-LCA0)' ; Tirumalesw= ar > Reddy (tireddy) ; 'Roman D. Danyliw' ; > 'Mortensen, Andrew' ; dots@ietf.org > Subject: RE: [Dots] use of restconf for the data channel? >=20 > Gilbert and Tirumaleswar: >=20 > Here are a few advanced on NETCONF/RESTCONF stack related to upcoming > changes. >=20 > -------------------------------------------------------------------------= --- > ------------ > Content (data models) ---> data stores (config, control plane, dynamic > configuration) > -------------------------------------------------------------------------= --- > -------------- > Operations: NETCONF, RESTCONF > config + events + pub/sub > Upcoming operations: control plane state + dynamic config (dhcp) > -------------------------------------------------------------------------= --- > --------------- > CoAP (proposed for light-weight config/events, or streams) > --------------- > |TLS| DLTS | > -------------- > |TCP|UDP | > -------------- > | IP | > --------------- >=20 > The NETCONF/RESTCONF events are NETCONF and NETMOD Working > Documents. The signaling of events or publication streams may range from > light weight (I'm here, I'm attacked) to large streams. The events + > publication/subscription streams requirements come from I2RS work which > desires these to be used for configuration and for control plane protocol= s such > as I2RS protocol. DOTS signaling could be another control plane protocol= . > CoAPs does not yet support these events, but it could be added. >=20 >=20 > Why use this? The event notification and publication/subscription stream > have many of the same base mechanisms. ID, lifetime, policy-id, sequencin= g > numbers, and timeouts plus additional features to tune the level of data > transmission. Mitigation request/signaling requires status updates at pe= riod > intervals which could use the publication/subscription channel that > sends this information to multiple clients. A binary encoding of the > event/signal mechanism via CoAP would this efficient. >=20 > One other thing to consider is the mixture of configuration/control plane > protocols. The NETMOD revised data stores > (https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/) > describes the NETMOD architecture for the mixture of configuration and > control plane. The control plane protocol does not need to follow the > netconf/restconf operational rules - but can set their own rules for > validation of data. NETMOD plans to support Yang modification for this > point. >=20 > I hope this helps. We'll talk in a few minutes. >=20 > Sue Hares >=20 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Wednesday, February 22, 2017 8:55 AM > To: 'Clark, Gilbert J. (GRC-LCA0)'; 'Tirumaleswar Reddy (tireddy)'; 'Roma= n D. > Danyliw'; 'Mortensen, Andrew'; dots@ietf.org > Subject: Re: [Dots] use of restconf for the data channel? >=20 > Gilbert: >=20 > Can you provide a bit more unpacking of the message here? NETCONF or > RESTCONF + Yang data models was the initial suggestion to allow stable > protocol plus the ability to rapidly change data models that form the con= tent > of the bulk data channel. I sent a longish message to the list around IET= F 97 > since you have questions, I will reformat this message as an internet-dra= ft and > send it to the list this week. >=20 > The Data channel requirements are: reliable transport, data privacy and > integrity, resource configuration (described in OP-07), data-004 black-wh= ite > list management. These are the basic design requirements for > NETCONF/RESTCONF functionality. The specific resources, black-list, or > white-list management can be data models. >=20 > There are four parts to NETCONF/RESTCONF protocol: >=20 > Content -- data models > Messaging method (NETCONF: edit-config, get-config, RESTCONF/ PUT, GET) > + new Event and publication/subscription = streams > information > Messaging protocol (rpc/rpc-reply / secure http) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Secure transport (TLS with X.509 certifications, DTLS + add ons) > Transport (TCP or UDP) >=20 > Since all of the requirements for the secure transport are the same (peer > mutual authentication, message confidentiality, integrity and authenticit= y, > and message replay protection are the same as the DOTS requirements. Yo= u > may wish to change the messaging protocol (rpc/rpc-reply or RESTCONF http= ) > to protobufs. If so, I suggest you make that suggestion to the I2NSF WG = that > will include it in its general changes suggested to NETCONF WG and I2RS > WG . The WGs would consider protobufs if there is a real use case. >=20 > If you want to change the message method to edit configuration, what your > alternative would be? If you are read, write, or updating you configurat= ion > or white lists, this is what these protocols are built for. The yang da= ta > models are tailored for user-readability. If you want to change the new > event publication and subscription, exactly what do you want to change. > As I will rapidly turn around a draft to answer your questions, please le= t me > know exactly what your concerns are. >=20 > If you are looking for the a secure shim layer, >=20 > Content -- data models > Messaging method (NETCONF: edit-config, get-config, RESTCONF/ PUT, GET) > + new Event and publication/subscription = streams > information > Messaging protocol (rpc/rpc-reply / secure http) (proposed: protobufs) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Secure session layer (for attack scenarios) > Secure transport (TLS with X.509 certifications, DTLS + add ons) > Transport (TCP or UDP >=20 > Bob Moskowitz and I have proposed one. If you use this, you may be able = to > utilize a lighter weight upper layer. >=20 >=20 > Thanks for your comments, >=20 > Sue Hares >=20 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Clark, Gilbert J. > (GRC-LCA0) > Sent: Wednesday, February 22, 2017 8:16 AM > To: Tirumaleswar Reddy (tireddy); Roman D. Danyliw; Mortensen, Andrew; > dots@ietf.org > Subject: Re: [Dots] use of restconf for the data channel? >=20 > Oh, neat: didn't realize RESTCONF graduated to an RFC. Looks like it was > pretty recent, but that is still a good thing and does alleviate one of m= y > concerns to an extent :) >=20 > "But for DOTS data channel RESTCONF is suitable" >=20 > Why is RESTCONF suitable for the data channel? Why was RESTCONF, > specifically, chosen? What does it offer that might justify the implemen= tation > burden that it brings, and would therefore make it a compelling choice wh= en > compared to just building and documenting a REST interface? If there are > reasons to use it that justify the complexity, then okay. I haven't seen= these > elements documented on the mailing list, though (apologies if I missed > them?), and I also didn't see them documented anywhere in the current dra= ft. >=20 > With this in mind, including text to explain what benefits RESTCONF offer= s and > explains *why* its adoption is important to the data channel would go a l= ong > way to alleviate the concerns I have in this instance :) >=20 > I would also point out that the data-channel-04 draft still references th= e > restconf draft instead of the RFC [1] - that's something that should prob= ably be > corrected for a future revision of the draft, if it hasn't already. >=20 > Cheers, > Gilbert >=20 > [1] [I-D.ietf-netconf-restconf] > Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF > Protocol", draft-ietf-netconf-restconf-18 (work in > progress), October 2016. > ________________________________________ > From: Tirumaleswar Reddy (tireddy) [tireddy@cisco.com] > Sent: Wednesday, February 22, 2017 2:17 AM > To: Clark, Gilbert J. (GRC-LCA0); Roman D. Danyliw; Mortensen, Andrew; > dots@ietf.org > Subject: RE: use of restconf for the data channel? >=20 > NETCONF and RESTCONF are not both suitable for DOTS signal channel. > But for DOTS data channel RESTCONF is suitable and RESTCONF is already an > RFC https://tools.ietf.org/html/rfc8040. > Various products in the market already use RESTCONF (e.g. confd 6.3 > http://www.tail-f.com/management-agent/) >=20 > -Tiru >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Clark, Gilbert > > J. (GRC- > > LCA0) > > Sent: Wednesday, February 22, 2017 11:26 AM > > To: Roman D. Danyliw ; Mortensen, Andrew > > ; dots@ietf.org > > Subject: Re: [Dots] use of restconf for the data channel? > > > > Hi: > > > > My strongest objection to both NETCONF and RESTCONF were in the > > context of their consideration for use in the signal channel. > > > > I wouldn't personally vote to see NETCONF, specifically, used in > > either > channel. > > NETCONF can involve substantial implementation complexity to support > > capabilities that, in the case of DOTS, seem to me to be of marginal > > utility at best. > > > > The use of RESTCONF seems a little more reasonable to me here since > > many of those implementation requirements are relaxed. > > > > I will note that adoption of RESTCONF will inflict a 100+ page > > not-yet-RFC as > > (additional) required reading for anyone who wishes to implement a > > DOTS data channel from scratch. Also, note that the use of RESTCONF > > would introduce a dependency on something that is still in > > development, and that therefore most likely hasn't yet been very well > > tested and / or may be subject to change. > > > > Just offering some clarification on my original opinion(s), for what > > that's worth. > > > > -Gilbert > > _________________________________ > > From: Dots [dots-bounces@ietf.org] on behalf of Roman D. Danyliw > > [rdd@cert.org] > > Sent: Wednesday, February 15, 2017 9:51 AM > > To: Mortensen, Andrew; dots@ietf.org > > Subject: Re: [Dots] use of restconf for the data channel? > > > > > Subject: [Dots] use of restconf for the data channel? > > > [snip] > > > > > > Since RESTCONF is now a concrete proposal, it seems worthwhile > > > continuing the debate ahead of the interim meeting. Are there > > > specific concerns in the WG regarding the use ... > > > > This discussion topic is one we need to resolve. We can start here on > > the list but I'll also add a slot to the interim meeting to continue > > the > conversation. > > > > Roman > > > > _______________________________________________ > > 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 >=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 From nobody Thu Feb 23 12:27:39 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D6612A2B8 for ; Thu, 23 Feb 2017 12:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 W7oqE-b3ljKq for ; Thu, 23 Feb 2017 12:27:37 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9A512A2AE for ; Thu, 23 Feb 2017 12:27:36 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v1NKRZFQ009925 for ; Thu, 23 Feb 2017 15:27:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1487881655; bh=Wua+ZbCqpZz3sC4dsJVPFv+Hox3kRs9KDDnXZyB6BJw=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=ju9jBUp8Bm3vJWZICa42xeg1D/0F346WwEr1Qmp/Ynq7XNxmm3tyJTXLMVKiv4tk7 eGAUqZoSanG4VDBvO/9hBHW7YkJIQdDLenPRZ8rvuSlB9OL428TwYSeJpmlpONuy6k F68w4WjGirUBXQyN7MYWhmt29XYj2JsA750HV/xQ= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v1NKRVWB009735 for ; Thu, 23 Feb 2017 15:27:32 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0319.002; Thu, 23 Feb 2017 15:27:31 -0500 From: "Roman D. Danyliw" To: "dots@ietf.org" Thread-Topic: Minutes for Virtual Interim Meeting on 2/22/2017 Thread-Index: AdKOEqY+wT7Es6VFT6uQSh7I2UiZ0w== Date: Thu, 23 Feb 2017 20:27:31 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104F0A1ED@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Minutes for Virtual Interim Meeting on 2/22/2017 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 23 Feb 2017 20:27:38 -0000 Hello WG! Minutes for our virtual interim meeting on Wednesday, 2/22/2017 can be foun= d here: https://www.ietf.org/proceedings/interim-2017-dots-01/minutes/minutes-inter= im-2017-dots-01-201702221000-00 Roman From nobody Thu Feb 23 20:46:57 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6137C129528 for ; Thu, 23 Feb 2017 20:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 SK5q55Rz9sre for ; Thu, 23 Feb 2017 20:46:52 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id A748012944F for ; Thu, 23 Feb 2017 20:46:51 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 1206C25F69B; Fri, 24 Feb 2017 13:46:50 +0900 (JST) Received: from DHCP-141.nttv6.jp (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id A6A26759042; Fri, 24 Feb 2017 13:46:49 +0900 (JST) To: "Tirumaleswar Reddy (tireddy)" , Ehud Doron , 'dots' References: <331a77a5ec074db69cf2bc2715a7645e@XCH-RCD-017.cisco.com> <3bab57f083c346cfb491c29c7ff369dd@XCH-RCD-017.cisco.com> From: kaname nishizuka Message-ID: <7dcc6611-18f5-7d89-2386-8e5ee22c94b6@nttv6.jp> Date: Fri, 24 Feb 2017 13:46:48 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <3bab57f083c346cfb491c29c7ff369dd@XCH-RCD-017.cisco.com> Content-Type: multipart/alternative; boundary="------------D525075E6005AF2E5EEF4901" Archived-At: Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 24 Feb 2017 04:46:55 -0000 This is a multi-part message in MIME format. --------------D525075E6005AF2E5EEF4901 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Tiru, I'd like to add a comment on lifetime attribute in signal-channel > 7. Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested > [TR] Changed to minutes I prefer seconds than minutes because I think granularity of minutes is rough. If we are to leverage programmable and automated feature of DOTS, lifetime in "seconds" is fine. thank you, Kaname On 2017/02/16 23:00, Tirumaleswar Reddy (tireddy) wrote: > > Hi Ehud, > > Please see inline [TR2] > > *From:* Ehud Doron [mailto:EhudD@Radware.com] > *Sent:* Thursday, February 16, 2017 6:43 PM > *To:* Tirumaleswar Reddy (tireddy) ; 'dots' > *Cc:* David Aviv > *Subject:* RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Tiru Hi > > Thanks for your response and clarifications. > > Please see inline (Followed after [Ehud] ) > > Thanks, > > *Ehud Doron *| Senior Architect, *Radware* CTO office | *M:*+972-54-7575503 | *T:* +972-72-3917120 > > *From:* Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > *Sent:* Tuesday, February 14, 2017 4:53 PM > *To:* Ehud Doron >; 'dots' > > *Cc:* David Aviv > > *Subject:* RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Hi Ehud, > > Thanks for the detailed review, Please see inline (I will respond to data channel comments in a separate mail) > > *From:* Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Ehud Doron > *Sent:* Wednesday, February 8, 2017 7:21 PM > *To:* 'dots' > > *Cc:* David Aviv > > *Subject:* [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Tiru and authors Hi > > Attached please find my comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > *_Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel draft-reddy-dots-signal-channel-07_* > > 1.General comment: For all signals in the draft, need to add means to allow vendor specific attributes as part of all signals transactions > > [TR] Yes, will update draft. > > 2.General comment: Just for clarity, need to explicitly mention on each figure when it is an example or the actual API > > [TR] Done. > > 3.Page 3 second paragraph : DOTS should not be limited to “enterprise network” only > > [TR] Agreed, fixed. > > 4.Page 4 chapter 4: The overall context of the “happy eyeballs” and its relations (or coexistence) to CoAP is not clear. > > [TR] Happy eyeballs mechanism is used to reduce connection delay to setup (D)TLS session with the DOTS server. Happy eyeballs mechanism is not related to CoAP. > > 5.Page 7 chapter 5.2.1: The need for YANG model cannot be understood from text. What are the needs for YANG models? What is the relation to the JSONs in the other chapters in the draft > > [TR] YANG is a data modeling language used to model configuration and state data; The configuration and state data defined using YANG can be represented in JSON or CBOR or XML. Since CBOR is binary, JSON is used in the draft but only for illustrative purpose. > > 6.Page 14 figure 5: The mitigation request attributes are right but not enough. Need to add more telemetry info about the actual attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. > > [TR] Yes, I plan to update the draft with telemetry info based on outcome of draft-doron-dots-telemetry-00. > > 7.Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested > > [TR] Changed to minutes > > 8.Page 15 last paragraph: Not sure that target port or target protocol can define a protected entity. IP, FQDN, URI are the only “stand alone” attributes , port and protocol are companion attributes. See also figure 9 . > > [TR] Good point, fixed. > > 9.Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is related ? “policy ID” ? I think the best is have another attribute to define the priority of mitigation requests > > [TR] policy-id is specific to a DOTS client, DOTS server need not compare the policy-id of one customer with the policy-id of another customer. Policy-ids are only compared b/w multiple mitigation requests from the same DOTS client to determine the priority. DOTS signaling channel runs over UDP, and packets may arrive out-of-order; this was also one of the reasons to introduce policy-id. > > [Ehud] Consider to update the text in page 15 with your explanations here, mainly regarding the “per customer uniqueness of DOTS”. > > [TR2] NEW: > > The relative order of two mitigation requests from a DOTS client is determined by comparing their respective policy-id values. > > 10.Page 21 table: The return status are right but not enough. Need to add more telemetry info about the actual mitigation going on (how much traffic was mitigated) and the attack that are mitigated, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. > > [TR] Same response as 6; for now will update the draft to convey the following telemetry info from the DOTS server : total dropped byte count, average dropped bytes per second, total dropped packet count and average dropped packets per second. The list is not complete, what kind of telemetry info is required for L7 attacks (e.g. attack at TLS, partial HTTP request, garbage request etc.) and how do we deal with new type of DDOS attacks (Do we keep updating the spec as and when a new DDOS attack is discovered) ? > > [Ehud] Agreed with the bytes / packets count drop you proposed. For the Layer 7 telemetries and for DDoS attacks list , I think we should first get to an agreement about the needs for this attributes and then figure out the best way to signal this information. Personally I don’t believe we should update the spec for each attack, therefor we need to figure out an efficient means to signal this information. > > [TR2] Agreed. > > 11.Page 15 : Need to find the way to bind the target-ip*s* with target-port-range*s* and target-protocol*s*, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth. > > [TR] Yes, it’s possible; create different aliases for IP1 TCP port 80 and IP 2 UDP port 53 using DOTS data channel and convey the aliases in DOTS signal channel. > > 12.Page 21 last paragraph: This is very strong point. > > [TR] Thanks. > > 13.Page 25 : Regarding attack status, same point about telemetry. > > [TR] Same response as above. > > 14.Page 25 chapter 5.4: I believe it can valuable to add a short high level description about the proposed API flow, same as you did for 5.3 . > > [TR] 5.3 gives background how GET, POST, DELETE and PUT will be used, hence did not see a need to add a high level description in Section 5.4. > > 15.Page 27: The necessity of policy_id here is not clear enough, are the “Signal Channel Session Configuration” define only “single” DOTS session or the entire communication between Client and Server for several DOTS request for mitigation? > > [TR] It’s for a single DOTS session between DOTS client and server, a single DOTS session can be used for several DOTS requests and responses. > > 16.Page 27: Not sure about the reason for “at least one of the attributes heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor MUST be present.” Also consider to change to “presented”. > > [TR] what is the point in conveying a POST request without any configuration parameters/attributes ? > [Ehud] OK, understood. So I think you need to emphasize that in cases not all attributes are defined, need to use default values. In page 26 you wrote something about “need not be default”. Consider to re-write. > [TR2] NEW: > The DOTS agents MUST use the negotiated values for message transmission > parameters and default values for non-negotiated message transmission > parameters. The signaling channel session configuration is > applicable to a single DOTS signal channel session between the DOTS > agents. > > -Tiru > > 17.Page 30 chapter 5.5: Need to specify the overall scenario, in reaction to which signal (or API transaction POST of Mitigation Request , unidirectional notification from Server as describes in page 23 in page 21 ?) the redirection occurred ? > > [TR] Both, updated draft. > > -Tiru > > *_Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel draft-reddy-dots-data-channel-03_* > > 1.General comment: For all signal in the draft, need to add means to allow vendor specific attributes as part of all signals transactions > > 2.Page 5 second paragraph: Why it is required to configure the DOTS signal channel session ? > > 3.Page 8 chapter 3.2.1 : Any reason for not including these identifiers in the DOTS signal channel draft ? > > 4.Page 9 figure 3 : Need to find the way to bind the target-ip*s* with target-port-range*s* and target-protocol*s*, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth. > > 5.Page 13 chapter 3.3 : Need to emphasize that filtering rules are relevant for both client server direct communication and through a DOTS gateway. The chapter is a bit confusing. > > 6.Page 14 chapter 3.3 : I am missing the white-list installation, is it by using the permit action ? > > 7.Page 15 figure 8: For DDoS it is highly valuable to have rate limit as an action. Consider adding such action (if already defined need to explain where and how). > > 8.Page 15 figure 8: Need to consider adding priority to an ACL to support cases when several filtering rules are conflicting. > > 9.Page 15 : The action field cannot be optional attribute. > > 10.Page 16 chapter 3.3.3: Need to add more telemetry info about the actual traffic that was blocked (bps, pps and so on), but as I believe this might be another issue… > > Thanks, > > ** > > *Ehud Doron *| Senior Architect, *Radware* CTO office | *M:*+972-54-7575503 | *T:* +972-72-3917120 > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------D525075E6005AF2E5EEF4901 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Tiru,

I'd like to add a comment on lifetime attribute in signal-channel

> 7.       Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested
> [TR] Changed to minutes

I prefer seconds than minutes because I think granularity of minutes is rough.
If we are to leverage programmable and automated feature of DOTS, lifetime in "seconds" is fine.

thank you,
Kaname


On 2017/02/16 23:00, Tirumaleswar Reddy (tireddy) wrote:

Hi Ehud,

 

Please see inline [TR2]

 

From: Ehud Doron [mailto:EhudD@Radware.com]
Sent: Thursday, February 16, 2017 6:43 PM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru Hi

 

Thanks for your response and clarifications.

Please see inline (Followed after [Ehud] )

 

Thanks,

 

Ehud Doron |  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Tuesday, February 14, 2017 4:53 PM
To: Ehud Doron <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Ehud,

 

Thanks for the detailed review, Please see inline (I will respond to data channel comments in a separate mail)

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru and authors Hi

 

Attached please find my comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

 

Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy-dots-signal-channel-07

 

1.       General comment: For all signals in the draft, need to add means to allow vendor specific attributes as part of all signals transactions

 

[TR] Yes, will update draft.

 

2.       General comment: Just for clarity, need to explicitly mention on each figure when it is an example or the actual API

 

[TR] Done.

 

3.       Page 3 second paragraph : DOTS should not be limited to “enterprise network” only

 

[TR] Agreed, fixed.

 

4.       Page 4 chapter 4: The overall context of the “happy eyeballs” and its relations (or coexistence) to CoAP is not clear.  

 

[TR] Happy eyeballs mechanism is used to reduce connection delay to setup (D)TLS session with the DOTS server. Happy eyeballs mechanism is not related to CoAP.

 

5.       Page 7 chapter 5.2.1: The need for YANG model cannot be understood from text. What are the needs for YANG models? What is the relation to the JSONs in the other chapters in the draft

 

[TR] YANG is a data modeling language used to model configuration and state data;  The configuration and state data defined using YANG can be represented in JSON or CBOR or XML. Since CBOR is binary, JSON is used in the draft but only for illustrative purpose.

 

6.       Page 14 figure 5: The mitigation request attributes are right but not enough. Need to add more telemetry info about the actual attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG.

 

[TR] Yes, I plan to update the draft with telemetry info based on outcome of draft-doron-dots-telemetry-00.

 

7.       Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested

 

[TR] Changed to minutes

 

8.       Page 15 last paragraph: Not sure that target port or target protocol can define a protected entity. IP, FQDN, URI are the only “stand alone” attributes , port and protocol are companion attributes. See also figure 9 .

 

[TR] Good point, fixed.

 

9.       Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is related ?   “policy ID” ? I think the best is have another attribute to define the priority of mitigation requests

[TR] policy-id is specific to a DOTS client, DOTS server need not compare the policy-id of one customer with the policy-id of another customer. Policy-ids are only compared b/w multiple mitigation requests from the same DOTS client to determine the priority. DOTS signaling channel runs over UDP, and packets may arrive out-of-order; this was also one of the reasons to introduce policy-id.

[Ehud] Consider to update the text in page 15 with your explanations here, mainly regarding the “per customer uniqueness of DOTS”.

 

[TR2] NEW:

The relative order of two mitigation requests from a DOTS client is determined by comparing their respective policy-id values.

 

10.   Page 21 table: The return status are right but not enough. Need to add more telemetry info about the actual mitigation going on (how much traffic was mitigated) and the attack that are mitigated, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG.

 

[TR] Same response as 6; for now will update the draft to convey the following telemetry info from the DOTS server : total dropped byte count, average dropped bytes per second, total dropped packet count and average dropped packets per second. The list is not complete, what kind of telemetry info is required for L7 attacks (e.g. attack at TLS, partial HTTP request, garbage request etc.) and how do we deal with new type of DDOS attacks (Do we keep updating the spec as and when a new DDOS attack is discovered) ?

[Ehud] Agreed with the bytes / packets count drop you proposed. For the Layer 7 telemetries and for DDoS attacks list , I think we should first get to an agreement about the needs for this attributes and then figure out the best way to signal this information. Personally I don’t believe we should update the spec for each attack, therefor we need to figure out an efficient means to signal this information.  

 

[TR2] Agreed.

 

11.   Page 15 : Need to find the way to bind the target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

[TR] Yes, it’s possible; create different aliases for IP1 TCP port 80 and IP 2 UDP port 53 using DOTS data channel and convey the aliases in DOTS signal channel.

 

12.   Page 21 last paragraph: This is very strong point.

 

[TR] Thanks.

 

13.   Page 25 : Regarding attack status, same point about telemetry.

 

[TR] Same response as above.

 

14.   Page 25 chapter 5.4: I believe it can valuable to add a short high level description about the proposed API flow, same as you did for 5.3 .

 

[TR] 5.3 gives background how GET, POST, DELETE and PUT will be used, hence did not see a need to add a high level description in Section 5.4.

 

 

15.   Page 27:  The necessity of policy_id here is not clear enough, are the “Signal Channel Session Configuration” define only “single” DOTS session or the entire communication between Client and Server for several DOTS request for mitigation?

 

[TR]  It’s for a single DOTS session between DOTS client and server, a single DOTS session can be used for several DOTS requests and responses.

 

16.   Page 27: Not sure about the reason for “at least one of the attributes heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor MUST be present.” Also consider to change to “presented”.

 

[TR] what is the point in conveying a POST request without any configuration parameters/attributes ?
[Ehud] OK, understood. So I think you need to emphasize that in cases not all attributes are defined, need to use default values. In page 26 you wrote something about “need not be default”. Consider to re-write. 
 
[TR2] NEW:
The DOTS agents MUST use the negotiated values for message transmission
parameters and default values for non-negotiated message transmission
parameters.  The signaling channel session configuration is
applicable to a single DOTS signal channel session between the DOTS
agents. 

 

-Tiru

 

17.   Page 30 chapter 5.5: Need to specify the overall scenario, in reaction to which signal (or API transaction POST of Mitigation Request , unidirectional notification from Server as describes in page 23 in page 21 ?) the  redirection occurred ?

 

[TR] Both, updated draft.

 

-Tiru

 

Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-dots-data-channel-03

 

1.       General comment: For all signal in the draft, need to add means to allow vendor specific attributes as part of all signals transactions

 

2.       Page 5 second paragraph: Why it is required to configure the DOTS signal channel session ?  

 

3.       Page 8 chapter 3.2.1 : Any reason for not including these identifiers in the DOTS signal channel draft ?

 

4.       Page 9 figure 3 : Need to find the way to bind the target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

5.       Page 13 chapter 3.3 : Need to emphasize that filtering rules are relevant for both client server direct communication and through a DOTS gateway. The chapter is a bit confusing.

 

6.       Page 14 chapter 3.3 : I am missing the white-list installation, is it by using the permit action ?

 

7.       Page 15 figure 8: For DDoS it is highly valuable to have rate limit as an action. Consider adding such action (if already defined need to explain where and how).

 

8.       Page 15 figure 8: Need to consider adding priority to an ACL to support cases when several filtering rules are conflicting.

 

9.       Page 15 : The action field cannot be optional attribute.

 

10.   Page 16 chapter 3.3.3: Need to add more telemetry info about the actual traffic that was blocked (bps, pps and so on), but as I believe this might be another issue…

 

 

 

Thanks,

 

Ehud Doron |  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

 



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

--------------D525075E6005AF2E5EEF4901-- From nobody Thu Feb 23 21:02:27 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3886212955B for ; Thu, 23 Feb 2017 21:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 p8kuHXL6fqj4 for ; Thu, 23 Feb 2017 21:02:23 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id AA5FD129558 for ; Thu, 23 Feb 2017 21:02:22 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 39DF425F69B; Fri, 24 Feb 2017 14:02:21 +0900 (JST) Received: from DHCP-141.nttv6.jp (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id F3DC7759042; Fri, 24 Feb 2017 14:02:20 +0900 (JST) To: "Xialiang (Frank)" , Dave Dolson References: From: kaname nishizuka Message-ID: <77f0cbb8-3e88-f7b3-ba2c-5875f309d3ec@nttv6.jp> Date: Fri, 24 Feb 2017 14:02:19 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B495AFC5686D0E23D4D84A70" Archived-At: Cc: "Mortensen, Andrew" , "dots@ietf.org" Subject: Re: [Dots] feedback on draft-ietf-dots-requirements X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 24 Feb 2017 05:02:26 -0000 This is a multi-part message in MIME format. --------------B495AFC5686D0E23D4D84A70 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I'd like to add a comment on item 1, see [kaname] On 2017/02/22 18:03, Xialiang (Frank) wrote: > > Hi Dave, > > Please see my comments inline: > > *发件人:*Dots [mailto:dots-bounces@ietf.org] *代表 *Dave Dolson > *发é€ć—¶é—´:*2017ĺą´2ćś22ć—Ą5:20 > *收件人:*Mortensen, Andrew > *抄é€:*dots@ietf.org > *主é˘:*Re: [Dots] feedback on draft-ietf-dots-requirements > > I feel some disconnect. Maybe folks could share their views on the following questions: > > 1.Is a dots signal-channel request a command or an advisory? I.e., MUST the server mitigate, or does the server simply consider it a data-point in the ongoing battle? > > [My opinion: advisory; the client is not always right or trustworthy, or mitigation is not always available] > > [Frank]: I share the same idea with you. For example, in OP-004, I don’t understand why DOTS server MUST cease mitigation ASAP in response to DOTS client’s withdraw request? > [kaname] I think DOTS server MUST cease mitigation in response to DOTS client’s withdraw request when it comes to Multi-homed scenario. When the DOTS client is not satisfied with the efficacy of the protection from the DOTS server A, it would try to change the protection point from DOTS server A to B. Then, if DOTS server A stick to its mitigation, it could cause unexpected side-effect especially on routing. regards, Kaname > > 2.Is there a question of overlapping resources? I.e., May different clients ask for mitigation of the same scope? (If not, how is ownership of resources determined?) > > [My opinion: there is ownership, so overlap is not possible. Negotiated in data channel.] > > [Frank]: agree. > > 3.Is a session required (like Diameter)? Or can each request stand alone (like DNS)? > > [My opinion: session is not required, and by its complexity harmful.] > > [Frank]: DOTS architecture draft has the definition about DOTS signaling session. I think it’s useful since DOTS protocol has some kinds of transaction feature. > > -Dave > > *From:*Mortensen, Andrew [mailto:amortensen@arbor.net] > *Sent:* Monday, February 20, 2017 1:31 PM > *To:* Dave Dolson > *Cc:* dots@ietf.org > *Subject:* Re: feedback on draft-ietf-dots-requirements > > Thanks, Dave. This is very helpful. My (extremely tardy) responses are inline. I’ve snipped most of the minor rephrasing suggestions. All comments are me speaking for myself, not necessarily for the other requirements draft editors. > > I’ve opened issues on github for most of these comments. > > On Nov 26, 2016, at 9:31 PM, Dave Dolson > wrote: > > …snip... > > 1.2 > > …snip... > > For “countermeasure”, this sounds like only packet filtering. Is that accurate and complete? Could tar-pit or routing changes be included in countermeasures? > > I don’t want the document to restrict the definition of countermeasure, but I’m also not keen to enshrine specific types of countermeasure, either. I’ll revise to make it clearer. > > Is “signal channel” intended to be the same thing as the “session” mentioned in the architecture? I think so, and terminology should be made consistent between the docs. If not, I don’t understand the difference between channel and session. > > Speaking for myself, the “channel” distinction is meant to distinguish the unreliable, lightweight SOS messages to be used when under attack from the reliable messaging required to e.g. manage filters and resource aliases. The “signaling session” in the architecture document is active messaging between DOTS agents over the signal channel. > > Should “Filter” be limited to the two actions of rate-limiting or discarding? Is filter really intended to include action, or just the match criteria? > > It sounds like you’re really asking whether we should leave the definition of “filtering” up to the DOTS server/mitigator. I worry that leaving “filtering” loosely defined will lead to confusion further down the line. I think we need explicit actions: discard is very different from rate-limit. > > As I see it, filtering is distinct from vendor extensions which might include countermeasure specifics. I don’t think DOTS is a general purpose interface for countermeasure configuration. > > Similarly for “Blacklist”: is block the only valid action for black-listed addresses? > > Yes, that’s the distinguishing characteristic of a blacklisted source. A whitelisted source is always allowed to pass. The DOTS client has full control over the black-/white-lists, though the scope is restricted by the DOTS server to prefixes/resources belonging to the DOTS client. > > 2. > > The second paragraph says “DOTS is an advisory protocol.” I thought this might mean that (a) a client’s request for aid may be ignored and (b) mitigation may be done prior to request or after withdrawal. Would that idea be accurate? > > I think (a) is correct, though ignoring a request without providing a reason when a service agreement is in place seems like a poor way to manage a service. In general a DOTS request for mitigation should result in mitigation, assuming business or service agreements are in place, but mitigating the attack might involve more than just a > > In calling DOTS “advisory” I was trying to emphasize two points: the difficulty of maintaining reliable messaging under attack conditions (with the corollary that a DOTS server may not be able to help even if a request gets through); and the fact that DOTS is not a general purpose mitigation API. > > Maybe I should clarify that further. I believe the DOTS *signal channel* is not a general purpose mitigation API. The DOTS data channel could evolve into that as a sort of DOTS control protocol, in which the impact of an attack on the communication layer between client and server is not a concern. > > (My thinking is that a DOTS server may know better than the client based on a wider source of telemetry.) > > Agreed. Once a mitigator begins filtering traffic bound for the domain of the DOTS client, the DOTS client’s view into the attack is skewed. > > - in GEN-004, consider picking a specific MTU size, like 500 bytes, because otherwise there is no way to judge if the protocol meets requirements. > > This has become more important since you suggested it, in light of the recent thread on telemetry. draft-reddy-dots-signal-channel is suggesting 500 bytes in the event the client can’t discern path MTU. I’m comfortable with text to the effect that clients SHOULD try to determine path MTU, and fall back to 500 bytes if it can’t be discovered. > > In 2.2, > > … snip ... > > OP-004: This requirement has several ideas in it, which I think should be broken into multiple requirements: > > (a)The idea that messages be acknowledged with a status code. > > -But it is unclear whether the status must be delivered immediately, or reported later. I expect there could be an immediate “I hear your request”, which doesn’t necessarily mean anything can be done. There should be a way for the client to later ask, “how are you doing with that request?” > > I meant this to be less restrictive than what you’ve described. There should be some way for the DOTS client to detect that its messages are being received/processed or lost, and the same is true for the DOTS server. That doesn’t have to mean an HTTP-like model. For example, in the protocol draft Nik Teague and I have put together, the signal channel is ongoing, periodic communication between client and server. The client does not need to send a separate message to ask about request status, since the DOTS server will send it in a few seconds anyway. > > (b)Whether the server MUST do as it is told. > > -On this point, I think the “MUST cease mitigation activity” is wrong, since the server may have other evidence or other clients requesting the mitigation. This is acknowledged by the “may continue mitigating” later in the paragraph. So at minimum the MUST is too strong. > > The full phrase is “MUST cease mitigation as quickly as possible”, by which I meant to express the importance of allowing the server to maintain the mitigation for a short period to reduce the impact of a DOTS client rapidly toggling mitigation. It sounds like the duration of that short period needs to be defined. > > I think two things should be clear in the final text: > > 1) The DOTS client can cease to be the cause for a mitigation at any time by sending a mitigation termination request, but cannot consider a mitigation terminated until confirmation from the server. (Mitigation lifetime is there to handle the cases where the server’s confirmation is not delivered.) > > 2) Once a DOTS client tells a DOTS server to stop mitigating, the DOTS client is no longer responsible for the mitigation. The DOTS server/mitigator can continue mitigating arbitrarily, but after the mitigation termination grace period elapses and the client hasn’t renewed a request for mitigation, all responsibility for the mitigation is borne by the DOTS server domain. > > OP-006. I would like to see all of specific scopes precisely defined as required or optional, but not as examples. > > Yes, this is a good suggestion. > > Also, I’m not clear on what DNS name filtering means: is this for filtering DNS packets, or for looking up the name and filtering the corresponding addresses? > > It’s not DNS name filtering, but indicating which FQDNs need mitigation. > > OP-008. I hope there isn’t going to be an argument about this, but… I believe it is not a client error to ask for a mitigation that conflicts with another client (how could it even know?). Rather, it is up to the server to weigh the various requests and act for the overall good. As paragraph 2 of section 2 says, “DOTS is an advisory protocol”. > > I don’t even think an overlapping prefix range is an error; rather both clients have identified the same attack. > > This is a fair counterpoint. “Act for the overall good” is unfortunately not concrete enough for a requirement. Cases like two DOTS clients requesting mitigation for the same resources are easy to handle—the server just lets the losing client know mitigation is already in progress—but partially overlapping mitigation requests are harder to handle. Does the server notify each client that the actual mitigation scope is larger than originally requested? > > 2.5 - Data model requirements > > I’m not sure what to make of this section. I think I just want to review the data model. > > I’m comfortable just removing this section. With Flemming's draft apparently evolving more toward information model, do we need to discuss data model at all outside of the solutions drafts? > > andrew > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------B495AFC5686D0E23D4D84A70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi,

I'd like to add a comment on item 1, see [kaname]

On 2017/02/22 18:03, Xialiang (Frank) wrote:

Hi Dave,

Please see my comments inline:

 

发件人: Dots [mailto:dots-bounces@ietf.org] 代表 Dave Dolson
发é€ć—¶é—´: 2017ĺą´2ćś22ć—Ą 5:20
收件人: Mortensen, Andrew
抄é€: dots@ietf.org
主é˘: Re: [Dots] feedback on draft-ietf-dots-requirements

 

I feel some disconnect. Maybe folks could share their views on the following questions:

 

1.       Is a dots signal-channel request a command or an advisory? I.e., MUST the server mitigate, or does the server simply consider it a data-point in the ongoing battle?

[My opinion: advisory; the client is not always right or trustworthy, or mitigation is not always available]

[Frank]: I share the same idea with you. For example, in OP-004, I don’t understand why DOTS server MUST cease mitigation ASAP in response to DOTS client’s withdraw request?

 

[kaname] I think DOTS server MUST cease mitigation in response to DOTS client’s withdraw request when it comes to Multi-homed scenario.
When the DOTS client is not satisfied with the efficacy of the protection from the DOTS server A, it would try to change the protection point from DOTS server A to B.
Then, if DOTS server A stick to its mitigation, it could cause unexpected side-effect especially on routing.

regards,
Kaname

2.       Is there a question of overlapping resources? I.e., May different clients ask for mitigation of the same scope? (If not, how is ownership of resources determined?)

[My opinion: there is ownership, so overlap is not possible. Negotiated in data channel.]

[Frank]: agree.

 

3.       Is a session required (like Diameter)? Or can each request stand alone (like DNS)?

[My opinion: session is not required, and by its complexity harmful.]

[Frank]: DOTS architecture draft has the definition about DOTS signaling session. I think it’s useful since DOTS protocol has some kinds of transaction feature.

 

 

-Dave

 

 

 

From: Mortensen, Andrew [mailto:amortensen@arbor.net]
Sent: Monday, February 20, 2017 1:31 PM
To: Dave Dolson
Cc: dots@ietf.org
Subject: Re: feedback on draft-ietf-dots-requirements

 

Thanks, Dave. This is very helpful. My (extremely tardy) responses are inline. I’ve snipped most of the minor rephrasing suggestions. All comments are me speaking for myself, not necessarily for the other requirements draft editors.

 

I’ve opened issues on github for most of these comments.

 

On Nov 26, 2016, at 9:31 PM, Dave Dolson <ddolson@sandvine.com> wrote:

 

…snip...

1.2

…snip...

For “countermeasure”, this sounds like only packet filtering. Is that accurate and complete? Could tar-pit or routing changes be included in countermeasures?

 

I don’t want the document to restrict the definition of countermeasure, but I’m also not keen to enshrine specific types of countermeasure, either. I’ll revise to make it clearer.

 

Is “signal channel” intended to be the same thing as the “session” mentioned in the architecture? I think so, and terminology should be made consistent between the docs. If not, I don’t understand the difference between channel and session.

 

Speaking for myself, the “channel” distinction is meant to distinguish the unreliable, lightweight SOS messages to be used when under attack from the reliable messaging required to e.g. manage filters and resource aliases. The “signaling session” in the architecture document is active messaging between DOTS agents over the signal channel.

 

Should “Filter” be limited to the two actions of rate-limiting or discarding?  Is filter really intended to include action, or just the match criteria?

 

It sounds like you’re really asking whether we should leave the definition of “filtering” up to the DOTS server/mitigator. I worry that leaving “filtering” loosely defined will lead to confusion further down the line. I think we need explicit actions: discard is very different from rate-limit.

 

As I see it, filtering is distinct from vendor extensions which might include countermeasure specifics. I don’t think DOTS is a general purpose interface for countermeasure configuration.

 

Similarly for “Blacklist”: is block the only valid action for black-listed addresses?

 

Yes, that’s the distinguishing characteristic of a blacklisted source. A whitelisted source is always allowed to pass. The DOTS client has full control over the black-/white-lists, though the scope is restricted by the DOTS server to prefixes/resources belonging to the DOTS client.

 

2.

The second paragraph says “DOTS is an advisory protocol.” I thought this might mean that (a) a client’s request for aid may be ignored and (b) mitigation may be done prior to request or after withdrawal. Would that idea be accurate?

 

I think (a) is correct, though ignoring a request without providing a reason when a service agreement is in place seems like a poor way to manage a service. In general a DOTS request for mitigation should result in mitigation, assuming business or service agreements are in place, but mitigating the attack might involve more than just a 

 

In calling DOTS “advisory” I was trying to emphasize two points: the difficulty of maintaining reliable messaging under attack conditions (with the corollary that a DOTS server may not be able to help even if a request gets through); and the fact that DOTS is not a general purpose mitigation API.

 

Maybe I should clarify that further. I believe the DOTS *signal channel* is not a general purpose mitigation API. The DOTS data channel could evolve into that as a sort of DOTS control protocol, in which the impact of an attack on the communication layer between client and server is not a concern.

 

(My thinking is that a DOTS server may know better than the client based on a wider source of telemetry.)

 

Agreed. Once a mitigator begins filtering traffic bound for the domain of the DOTS client, the DOTS client’s view into the attack is skewed.

 

 

- in GEN-004, consider picking a specific MTU size, like 500 bytes, because otherwise there is no way to judge if the protocol meets requirements.

 

This has become more important since you suggested it, in light of the recent thread on telemetry. draft-reddy-dots-signal-channel is suggesting 500 bytes in the event the client can’t discern path MTU. I’m comfortable with text to the effect that clients SHOULD try to determine path MTU, and fall back to 500 bytes if it can’t be discovered.

 

 

In 2.2,

… snip ...

OP-004: This requirement has several ideas in it, which I think should be broken into multiple requirements:

(a)    The idea that messages be acknowledged with a status code.

-          But it is unclear whether the status must be delivered immediately, or reported later. I expect there could be an immediate “I hear your request”, which doesn’t necessarily mean anything can be done. There should be a way for the client to later ask, “how are you doing with that request?”

 

I meant this to be less restrictive than what you’ve described. There should be some way for the DOTS client to detect that its messages are being received/processed or lost, and the same is true for the DOTS server. That doesn’t have to mean an HTTP-like model. For example, in the protocol draft Nik Teague and I have put together, the signal channel is ongoing, periodic communication between client and server. The client does not need to send a separate message to ask about request status, since the DOTS server will send it in a few seconds anyway.

 

(b)   Whether the server MUST do as it is told.

-          On this point, I think the “MUST cease mitigation activity” is wrong, since the server may have other evidence or other clients requesting the mitigation. This is acknowledged by the “may continue mitigating” later in the paragraph. So at minimum the MUST is too strong.

 

The full phrase is “MUST cease mitigation as quickly as possible”, by which I meant to express the importance of allowing the server to maintain the mitigation for a short period to reduce the impact of a DOTS client rapidly toggling mitigation. It sounds like the duration of that short period needs to be defined.

 

I think two things should be clear in the final text:

 

1) The DOTS client can cease to be the cause for a mitigation at any time by sending a mitigation termination request, but cannot consider a mitigation terminated until confirmation from the server. (Mitigation lifetime is there to handle the cases where the server’s confirmation is not delivered.)

 

2) Once a DOTS client tells a DOTS server to stop mitigating, the DOTS client is no longer responsible for the mitigation. The DOTS server/mitigator can continue mitigating arbitrarily, but after the mitigation termination grace period elapses and the client hasn’t renewed a request for mitigation, all responsibility for the mitigation is borne by the DOTS server domain.

 

OP-006. I would like to see all of specific scopes precisely defined as required or optional, but not as examples.

 

Yes, this is a good suggestion.

 

Also, I’m not clear on what DNS name filtering means: is this for filtering DNS packets, or for looking up the name and filtering the corresponding addresses?

 

It’s not DNS name filtering, but indicating which FQDNs need mitigation.

 

 

OP-008. I hope there isn’t going to be an argument about this, but… I believe it is not a client error to ask for a mitigation that conflicts with another client (how could it even know?). Rather, it is up to the server to weigh the various requests and act for the overall good. As paragraph 2 of section 2 says, “DOTS is an advisory protocol”.

I don’t even think an overlapping prefix range is an error; rather both clients have identified the same attack.

 

This is a fair counterpoint. “Act for the overall good” is unfortunately not concrete enough for a requirement. Cases like two DOTS clients requesting mitigation for the same resources are easy to handle—the server just lets the losing client know mitigation is already in progress—but partially overlapping mitigation requests are harder to handle. Does the server notify each client that the actual mitigation scope is larger than originally requested? 

 

 

2.5  - Data model requirements

I’m not sure what to make of this section. I think I just want to review the data model.

 

I’m comfortable just removing this section. With Flemming's draft apparently evolving more toward information model, do we need to discuss data model at all outside of the solutions drafts?

 

andrew



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

--------------B495AFC5686D0E23D4D84A70-- From nobody Mon Feb 27 06:35:18 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BF2129FF2 for ; Mon, 27 Feb 2017 06:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 NsSDd0MkHdrD for ; Mon, 27 Feb 2017 06:35:16 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DE81298BD for ; Mon, 27 Feb 2017 06:35:15 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v1REZEWx024908 for ; Mon, 27 Feb 2017 09:35:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1488206114; bh=X76FM6UapxcaV2/erKmYqPgh7Ry+r1OuykhEzgn//c0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=iXRukyhnVk5wNGJYXHRpnRdHoHt4WuVF3v7WpxMLR4YbgPDMVXG2jy/A8rcgQQ6XW lyCeqkSRdf0fwx/fqt79hnR4w7XD45wosfGVSGSF8MRsO+rIS4vOAPM7W3HnmzfTHG QCI5JeVQMfRzDHZbX4bnlNNe/HK80FhpvQH/XMcM= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id v1REZB0G002490 for ; Mon, 27 Feb 2017 09:35:11 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0319.002; Mon, 27 Feb 2017 09:35:10 -0500 From: "Roman D. Danyliw" To: "dots@ietf.org" Thread-Topic: Preliminary IETF 98 agenda and related preparation Thread-Index: AdKRBlCtpO6PVF3iT52NwSb1gwdskA== Date: Mon, 27 Feb 2017 14:35:10 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104F0CCCA@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Preliminary IETF 98 agenda and related preparation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 14:35:17 -0000 Hello WG! The preliminary agenda for IETF 98 has been published at https://datatracke= r.ietf.org/meeting/98/agenda.txt. DOTS is tentatively scheduled for: TUESDAY, March 28, 2017 1640-1840 Afternoon Session III Zurich G SEC dots DDoS Open Threat Signaling WG Please keep in mind that the final agenda won't be published until 2017-03= -03 (Friday). The Internet Draft submission cut-off (for all drafts, including -00) for t= his meeting will be on 2017-03-13 (Monday) UTC 23:59. If you are interested in presenting please send your requests to the chairs= . Roman From nobody Mon Feb 27 10:42:48 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C87A12A2D3 for ; Mon, 27 Feb 2017 10:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com 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 TBUa9w3l0t7c for ; Mon, 27 Feb 2017 10:42:44 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0110.outbound.protection.outlook.com [104.47.36.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93DC12A2D6 for ; Mon, 27 Feb 2017 10:42:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Tz5W0vLLK+jSd0WuPFVsxQza3/dTrRzXDZmI71OI38g=; b=G4UYSQWqU82zMu5c3sK+kvxdVIrwMIEBTKkvmPI5sPROfYfmwIFpT2sJ5XqJyX5E28+8r5K5CfBw+UIenu/2l89tqM21YYDSh+Je4Eawbdr7l42nHhzjOxoIbgfXeu8o2M9mer9tK0l5ylO2NaKHM0O6tenmdX+vGOBx5zJczCI= Received: from MWHPR0101MB3118.prod.exchangelabs.com (10.174.167.145) by MWHPR0101MB3117.prod.exchangelabs.com (10.174.166.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Mon, 27 Feb 2017 18:42:43 +0000 Received: from MWHPR0101MB3118.prod.exchangelabs.com ([10.174.167.145]) by MWHPR0101MB3118.prod.exchangelabs.com ([10.174.167.145]) with mapi id 15.01.0933.019; Mon, 27 Feb 2017 18:42:43 +0000 From: "Mortensen, Andrew" To: "dots@ietf.org" Thread-Topic: merging requirements and use cases drafts? Thread-Index: AQHSkSlHPjfCqL/HTUaPO9bSB5JdCA== Date: Mon, 27 Feb 2017 18:42:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=amortensen@arbor.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [216.130.192.3] x-ms-office365-filtering-correlation-id: 40ac5ba4-71db-4d15-a370-08d45f406a55 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:MWHPR0101MB3117; x-microsoft-exchange-diagnostics: 1; MWHPR0101MB3117; 7:5lSUmsGXoySbYlQNIFavyg71JH/LzMwrVJrihgdAOESZhm+sTadvX/UKhimxnRWlNMlcq5pFw/caHsTU0JvTZTBaZJq7ZKPgoq4BtwXD5/RQ5ZYJMs+NZcV9/pOkhMoiXwmN7NUGKmte+fhkbHyrwHsHqQhDbi8ixp4vQrGx4/kvnNkGk7/bTnzt9rTsKGOVszJ4f19tkgf7jxf19SEJ3JMHE15BMQrg+S3vvV3yNEgPjYtexYRh/y7O7IjxEYP+A1eltk+e/b3GPdFu0pUacTpXtlLSFt0OEZtBQxxpGl04UnbnBHoKChHdf0fSpU06I/VGDIe6DxQLfz5BKZxZ8g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:MWHPR0101MB3117; BCL:0; PCL:0; RULEID:; SRVR:MWHPR0101MB3117; x-forefront-prvs: 02318D10FB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(199003)(189002)(77096006)(6486002)(66066001)(81156014)(6506006)(8676002)(1730700003)(305945005)(81166006)(8936002)(6436002)(3660700001)(25786008)(5640700003)(3280700002)(450100001)(82746002)(2906002)(99286003)(102836003)(6116002)(3846002)(7736002)(6512007)(83716003)(68736007)(189998001)(122556002)(38730400002)(110136004)(50986999)(97736004)(54356999)(92566002)(2501003)(101416001)(6916009)(53936002)(106116001)(105586002)(106356001)(36756003)(5660300001)(2900100001)(86362001)(2351001)(33656002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR0101MB3117; H:MWHPR0101MB3118.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2017 18:42:43.0750 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0101MB3117 Archived-At: Subject: [Dots] merging requirements and use cases drafts? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 18:42:46 -0000 RHVyaW5nIHRoZSBpbnRlcmltIG1lZXRpbmcsIEthdGhsZWVuIE1vcmlhcnR5IG9ic2VydmVkIHRo YXQgaXQgbWlnaHQgYmUgYmVuZWZpY2lhbCB0byBtZXJnZSB0aGUgcmVxdWlyZW1lbnRzIGFuZCB1 c2UgY2FzZXMgZHJhZnRzLCBzaW5jZSB0aGUgSUVTRyB0ZW5kcyB0byBsb29rIG1vcmUgZmF2b3Jh Ymx5IG9uIHN1Y2ggZHJhZnRzLg0KDQpXZSBkaWQgbm90IGNvbnRpbnVlIHRoYXQgZGlzY3Vzc2lv biBkdXJpbmcgdGhlIGludGVyaW0gbWVldGluZywgZHVlIHRvIGxpbWl0ZWQgdGltZSwgYnV0IEkg dGhpbmsgaXTigJlzIHNvbWV0aGluZyB3ZSBuZWVkIHRvIGRpc2N1c3MgYWhlYWQgb2YgdGhlIG1l ZXRpbmcgaW4gQ2hpY2Fnby4gVG8gYmVnaW4gd2l0aCwgSeKAmWQgbGlrZSB0byBoZWFyIGEgbGl0 dGxlIG1vcmUgZnJvbSBLYXRobGVlbiBhYm91dCB3aHkgYSBtZXJnZWQgZHJhZnQgaXMgbGlrZWx5 IHRvIGJlIG1vcmUgcGFsYXRhYmxlIHRvIHRoZSBJRVNHLiBJZiBub3RoaW5nIGVsc2UsIGl04oCZ ZCBiZSBuaWNlIHRvIGF2b2lkIGNvbWluZyB0byB0aGUgdG9waWMgY29sZCBpbiBDaGljYWdvLg0K DQphbmRyZXc= From nobody Mon Feb 27 10:54:37 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E4B12A2DB for ; Mon, 27 Feb 2017 10:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 a3SARYPhLttP for ; Mon, 27 Feb 2017 10:54:33 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 70526129B0F for ; Mon, 27 Feb 2017 10:54:33 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id s186so111917016qkb.1 for ; Mon, 27 Feb 2017 10:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iARkTucedVA3bbom+4Z3NF+QKu/kpkrU6Z+7FySx4u8=; b=Xd1an8Pha9t98DkbcZ6GmVuA+s6ubB9hFoqpXJ98hUZDQCfwZ3ryppF2V27IsY2x5b seqW2sSwp/jdgY92uP3RVWheqJI0J1TCELaPaj2++AcG5iksm4HaJYsiOVGoaDd6cSJW c2ayIDri85EMDH18dfzzremSjl0DYrmx/2vJidBb2kZOsqumdEDaSoEf5fQ5khVlPzhH EeWHdygehduOMRI7hUwaKkq+jwdJrPOC8KaCkIQMv+bE7WT7fSEhyLgbrwaMl4zMN/jH qM4IcjzMAKBZCx2WI7AO0ffysXTQahBieZAs5eVTv4qcaock1sa6Xag3+GWxXPPvsYMx HOjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iARkTucedVA3bbom+4Z3NF+QKu/kpkrU6Z+7FySx4u8=; b=f9BjqLAmlMp5Hl1Si30DmX0qeKOVljSY6AtYdxmTH05BzEk9vHJSr0ZXohL7zJd1XN 980QHVt06C7hSqyqpnsK8y3o2+8/XleuC6bLThAPxh+pRsx5FrnWAVOJFKH9KSjFFpsh 20PwgamdtqMTauYPH7BlVMHMZdksJptKVpQpAbi1iFS+f4oVvJKbGS90fZjpIHfaZP5H G0L5bxcw/DrgdwPrC0tB1hLvkoqYmlWFSB/Xz3hkIT+t+g9Xw86vJy5ZcZJBK7a6zqel PDHRLkCJkaW6vmZFTBQ3/UJu+KX6++e9TiKb1q3CP5MKJF3ZXCbKkGZETg2Drz3gKfzm B6xA== X-Gm-Message-State: AMke39lkcJEit3OKBpBweg704KNAfo+uQIc1pNgPD8sydBjKtUXf4vZg21ZJF7lWbgRyocoWFN1DymQKbHo4tg== X-Received: by 10.200.42.213 with SMTP id c21mr14335580qta.257.1488221672524; Mon, 27 Feb 2017 10:54:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.140.78 with HTTP; Mon, 27 Feb 2017 10:54:32 -0800 (PST) In-Reply-To: References: From: Kathleen Moriarty Date: Mon, 27 Feb 2017 13:54:32 -0500 Message-ID: To: "Mortensen, Andrew" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] merging requirements and use cases drafts? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 18:54:35 -0000 Hi Andrew, Thanks for raising this on list. inline. On Mon, Feb 27, 2017 at 1:42 PM, Mortensen, Andrew w= rote: > During the interim meeting, Kathleen Moriarty observed that it might be b= eneficial to merge the requirements and use cases drafts, since the IESG te= nds to look more favorably on such drafts. > > We did not continue that discussion during the interim meeting, due to li= mited time, but I think it=E2=80=99s something we need to discuss ahead of = the meeting in Chicago. To begin with, I=E2=80=99d like to hear a little mo= re from Kathleen about why a merged draft is likely to be more palatable to= the IESG. If nothing else, it=E2=80=99d be nice to avoid coming to the top= ic cold in Chicago. If the WG would like to publish both the use case document and the requirements (which is fine to do), it might take less work cycles for IETF review, IESG review, and document processing if it were combined into one document. On the other hand, if the WG decides that they don't need to publish the documents formally, that the expired drafts are enough, that's also fine. Here is the IESG statement on these types of support documents, hence my comment on the call: https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html Thanks. > > andrew > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --=20 Best regards, Kathleen From nobody Tue Feb 28 00:07:27 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA711128B44 for ; Tue, 28 Feb 2017 00:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 L0y9XaJx-FLP for ; Tue, 28 Feb 2017 00:07:24 -0800 (PST) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0BB1289B0 for ; Tue, 28 Feb 2017 00:07:24 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 0E84120486; Tue, 28 Feb 2017 09:07:23 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id D142D1C007D; Tue, 28 Feb 2017 09:07:22 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0319.002; Tue, 28 Feb 2017 09:07:22 +0100 From: To: "Mortensen, Andrew" , "dots@ietf.org" Thread-Topic: merging requirements and use cases drafts? Thread-Index: AQHSkSlHPjfCqL/HTUaPO9bSB5JdCKF+D3eQ Date: Tue, 28 Feb 2017 08:07:21 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E1989A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] merging requirements and use cases drafts? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 08:07:26 -0000 SGkgQW5kcmV3LCBhbGwsIA0KDQpJIGhhdmUgYW4gYWx0ZXJuYXRlIHByb3Bvc2FsOiANCiogTWFp bnRhaW4gdGhlIHJlcXVpcmVtZW50cyBkcmFmdCB3aXRoIGl0cyBpbml0aWFsIHNjb3BlLg0KKiBB YmFuZG9uIHRoZSB1c2UgY2FzZXMgZHJhZnQuIA0KDQpJIGRvbid0IHNlZSBtdWNoIHZhbHVlIGlu IHB1Ymxpc2hpbmcgdGhlIHVzZSBjYXNlIEktRCBhcyBhbiBSRkMuIFRoZSByZXF1aXJlbWVudHMg SS1EIGlzIHJlYWxseSBpbXBvcnRhbnQgYXMgaXQgc2tldGNoZXMgdGhlIHNjb3BlIGFuZCByZXF1 aXJlZCBET1RTIGZ1bmN0aW9uYWxpdGllcy4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGll dGYub3JnXSBEZSBsYSBwYXJ0IGRlIE1vcnRlbnNlbiwgQW5kcmV3DQo+IEVudm95w6nCoDogbHVu ZGkgMjcgZsOpdnJpZXIgMjAxNyAxOTo0Mw0KPiDDgMKgOiBkb3RzQGlldGYub3JnDQo+IE9iamV0 wqA6IFtEb3RzXSBtZXJnaW5nIHJlcXVpcmVtZW50cyBhbmQgdXNlIGNhc2VzIGRyYWZ0cz8NCj4g DQo+IER1cmluZyB0aGUgaW50ZXJpbSBtZWV0aW5nLCBLYXRobGVlbiBNb3JpYXJ0eSBvYnNlcnZl ZCB0aGF0IGl0IG1pZ2h0IGJlDQo+IGJlbmVmaWNpYWwgdG8gbWVyZ2UgdGhlIHJlcXVpcmVtZW50 cyBhbmQgdXNlIGNhc2VzIGRyYWZ0cywgc2luY2UgdGhlIElFU0cNCj4gdGVuZHMgdG8gbG9vayBt b3JlIGZhdm9yYWJseSBvbiBzdWNoIGRyYWZ0cy4NCj4gDQo+IFdlIGRpZCBub3QgY29udGludWUg dGhhdCBkaXNjdXNzaW9uIGR1cmluZyB0aGUgaW50ZXJpbSBtZWV0aW5nLCBkdWUgdG8NCj4gbGlt aXRlZCB0aW1lLCBidXQgSSB0aGluayBpdOKAmXMgc29tZXRoaW5nIHdlIG5lZWQgdG8gZGlzY3Vz cyBhaGVhZCBvZiB0aGUNCj4gbWVldGluZyBpbiBDaGljYWdvLiBUbyBiZWdpbiB3aXRoLCBJ4oCZ ZCBsaWtlIHRvIGhlYXIgYSBsaXR0bGUgbW9yZSBmcm9tDQo+IEthdGhsZWVuIGFib3V0IHdoeSBh IG1lcmdlZCBkcmFmdCBpcyBsaWtlbHkgdG8gYmUgbW9yZSBwYWxhdGFibGUgdG8gdGhlDQo+IElF U0cuIElmIG5vdGhpbmcgZWxzZSwgaXTigJlkIGJlIG5pY2UgdG8gYXZvaWQgY29taW5nIHRvIHRo ZSB0b3BpYyBjb2xkIGluDQo+IENoaWNhZ28uDQo+IA0KPiBhbmRyZXcNCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRG90cyBtYWlsaW5nIGxpc3QN Cj4gRG90c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RvdHMNCg== From nobody Tue Feb 28 01:08:21 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBD612706D for ; Tue, 28 Feb 2017 01:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 zcsHcOvSf2gO for ; Tue, 28 Feb 2017 01:08:18 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B2A126D74 for ; Tue, 28 Feb 2017 01:08:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2542; q=dns/txt; s=iport; t=1488272898; x=1489482498; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XGLmx3K4hRGrFmzfhBbpJp4UbRT0iewFGfhBODvQK38=; b=gvjjDuAaVKSSvhh5AS6EDTqe4+OdfqoZ2K7hD/SxhtpwfUM++fNzxcf+ 5yVIue2e47GetXEGPTfkP8tW16nxiBgQk6HbFkyGehFWSdPKxZC+vHHkt 8hH9r8gYh1Btj5hRM9Z2XKbecZTNDdy/NcYaUiJRDjSvWkPf6Bw68NyaE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DyAQB/PbVY/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1BhgQkHg1SKCJFjlTWCDR8LhXgCGoINPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?wAQEBBAEBIRE6FwQCAQgRBAEBAwIjAwICAiULFAEICAIEARIIiWwOsCmCJos1A?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VBhG+EMIMqgl8FlW+GMgGSIJEhkzA?= =?us-ascii?q?BHziBAVQVPoRPHYFhdYdrgTCBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,218,1484006400"; d="scan'208";a="389934312" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Feb 2017 09:08:17 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v1S98Hdd023341 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Feb 2017 09:08:17 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.1210.3; Tue, 28 Feb 2017 03:08:16 -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.1210.000; Tue, 28 Feb 2017 03:08:16 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" , "Mortensen, Andrew" , "dots@ietf.org" Thread-Topic: merging requirements and use cases drafts? Thread-Index: AQHSkSlHPjfCqL/HTUaPO9bSB5JdCKF+D3eQgAARtRA= Date: Tue, 28 Feb 2017 09:08:16 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933009E1989A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E1989A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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.89.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] merging requirements and use cases drafts? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 09:08:19 -0000 SSBwcmVmZXIgdG8ga2VlcCB0aGVtIHNlcGFyYXRlLg0KDQotVGlydQ0KIA0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YNCj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiBTZW50 OiBUdWVzZGF5LCBGZWJydWFyeSAyOCwgMjAxNyAxOjM3IFBNDQo+IFRvOiBNb3J0ZW5zZW4sIEFu ZHJldyA8YW1vcnRlbnNlbkBhcmJvci5uZXQ+OyBkb3RzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBbRG90c10gbWVyZ2luZyByZXF1aXJlbWVudHMgYW5kIHVzZSBjYXNlcyBkcmFmdHM/DQo+IA0K PiBIaSBBbmRyZXcsIGFsbCwNCj4gDQo+IEkgaGF2ZSBhbiBhbHRlcm5hdGUgcHJvcG9zYWw6DQo+ ICogTWFpbnRhaW4gdGhlIHJlcXVpcmVtZW50cyBkcmFmdCB3aXRoIGl0cyBpbml0aWFsIHNjb3Bl Lg0KPiAqIEFiYW5kb24gdGhlIHVzZSBjYXNlcyBkcmFmdC4NCj4gDQo+IEkgZG9uJ3Qgc2VlIG11 Y2ggdmFsdWUgaW4gcHVibGlzaGluZyB0aGUgdXNlIGNhc2UgSS1EIGFzIGFuIFJGQy4gVGhlDQo+ IHJlcXVpcmVtZW50cyBJLUQgaXMgcmVhbGx5IGltcG9ydGFudCBhcyBpdCBza2V0Y2hlcyB0aGUg c2NvcGUgYW5kIHJlcXVpcmVkDQo+IERPVFMgZnVuY3Rpb25hbGl0aWVzLg0KPiANCj4gQ2hlZXJz LA0KPiBNZWQNCj4gDQo+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gRGXCoDog RG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBNb3J0ZW5z ZW4sDQo+ID4gQW5kcmV3IEVudm95w6nCoDogbHVuZGkgMjcgZsOpdnJpZXIgMjAxNyAxOTo0MyDD gMKgOiBkb3RzQGlldGYub3JnIE9iamV0wqA6DQo+ID4gW0RvdHNdIG1lcmdpbmcgcmVxdWlyZW1l bnRzIGFuZCB1c2UgY2FzZXMgZHJhZnRzPw0KPiA+DQo+ID4gRHVyaW5nIHRoZSBpbnRlcmltIG1l ZXRpbmcsIEthdGhsZWVuIE1vcmlhcnR5IG9ic2VydmVkIHRoYXQgaXQgbWlnaHQNCj4gPiBiZSBi ZW5lZmljaWFsIHRvIG1lcmdlIHRoZSByZXF1aXJlbWVudHMgYW5kIHVzZSBjYXNlcyBkcmFmdHMs IHNpbmNlDQo+ID4gdGhlIElFU0cgdGVuZHMgdG8gbG9vayBtb3JlIGZhdm9yYWJseSBvbiBzdWNo IGRyYWZ0cy4NCj4gPg0KPiA+IFdlIGRpZCBub3QgY29udGludWUgdGhhdCBkaXNjdXNzaW9uIGR1 cmluZyB0aGUgaW50ZXJpbSBtZWV0aW5nLCBkdWUgdG8NCj4gPiBsaW1pdGVkIHRpbWUsIGJ1dCBJ IHRoaW5rIGl04oCZcyBzb21ldGhpbmcgd2UgbmVlZCB0byBkaXNjdXNzIGFoZWFkIG9mDQo+ID4g dGhlIG1lZXRpbmcgaW4gQ2hpY2Fnby4gVG8gYmVnaW4gd2l0aCwgSeKAmWQgbGlrZSB0byBoZWFy IGEgbGl0dGxlIG1vcmUNCj4gPiBmcm9tIEthdGhsZWVuIGFib3V0IHdoeSBhIG1lcmdlZCBkcmFm dCBpcyBsaWtlbHkgdG8gYmUgbW9yZSBwYWxhdGFibGUNCj4gPiB0byB0aGUgSUVTRy4gSWYgbm90 aGluZyBlbHNlLCBpdOKAmWQgYmUgbmljZSB0byBhdm9pZCBjb21pbmcgdG8gdGhlDQo+ID4gdG9w aWMgY29sZCBpbiBDaGljYWdvLg0KPiA+DQo+ID4gYW5kcmV3DQo+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBEb3RzIG1haWxpbmcgbGlzdA0K PiA+IERvdHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RvdHMNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gRG90c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg== From nobody Tue Feb 28 01:14:05 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E390F12706D for ; Tue, 28 Feb 2017 01:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.512 X-Spam-Level: X-Spam-Status: No, score=-14.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 FrC-RKPHf05i for ; Tue, 28 Feb 2017 01:14:00 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E6A126D74 for ; Tue, 28 Feb 2017 01:14:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49384; q=dns/txt; s=iport; t=1488273240; x=1489482840; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=as+LuLANZz+hWwr2MJAElwHyBZ35GwbJx/+++1CfuO8=; b=a5ZaaI90FWXuxeAaqwbytiUXOJniNwuiAFc0F1o3jqT/zlaWEpg8WxN0 MTen6UdWN3I6VAFU/tFl9FNrMV0sfPdIdPDC4d7/hUEdGmzuIf2MzKyaX R0trSg8LfuEE4A4rlQHWFto2M00kDrwktQs1wm/iZ3Ba+lFcQDxUKjsfH 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQD6PrVY/5JdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5iYYEJB41ckWOVNYIKAx8BCoV4AoInPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?wAQEBAwEBARgTQQQHBQsCAQgRBAEBIQECBAcnCxQJCAEBBAENBQgRiVMIDrJRK?= =?us-ascii?q?4sKAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGTIRvhDABBgEBBR0HHgoChS0FlW+?= =?us-ascii?q?GMgGKGYgHggSFIIl9iDyKdAEfOIEBVBU+hEwDHRmBSHWHawEOF4EKgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,218,1484006400"; d="scan'208,217";a="211843115" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Feb 2017 09:13:46 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v1S9DjX3025805 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Feb 2017 09:13:45 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.1210.3; Tue, 28 Feb 2017 03:13:45 -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.1210.000; Tue, 28 Feb 2017 03:13:45 -0600 From: "Tirumaleswar Reddy (tireddy)" To: kaname nishizuka , Ehud Doron , "'dots'" Thread-Topic: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . Thread-Index: AdKCER/slEaaT/pbTQCa8ffUgEh/YgEvK4mgADZ1NNAALTMmUAGLtzkAAMXdMkA= Date: Tue, 28 Feb 2017 09:13:45 +0000 Message-ID: <5cbbc9aa610c43c28ae7c501ef8da35b@XCH-RCD-017.cisco.com> References: <331a77a5ec074db69cf2bc2715a7645e@XCH-RCD-017.cisco.com> <3bab57f083c346cfb491c29c7ff369dd@XCH-RCD-017.cisco.com> <7dcc6611-18f5-7d89-2386-8e5ee22c94b6@nttv6.jp> In-Reply-To: <7dcc6611-18f5-7d89-2386-8e5ee22c94b6@nttv6.jp> 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.89.55] Content-Type: multipart/alternative; boundary="_000_5cbbc9aa610c43c28ae7c501ef8da35bXCHRCD017ciscocom_" MIME-Version: 1.0 Archived-At: Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 09:14:04 -0000 --_000_5cbbc9aa610c43c28ae7c501ef8da35bXCHRCD017ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: kaname nishizuka [mailto:kaname@nttv6.jp] Sent: Friday, February 24, 2017 10:17 AM To: Tirumaleswar Reddy (tireddy) ; Ehud Doron ; 'dots' Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 . Hi Tiru, I'd like to add a comment on lifetime attribute in signal-channel > 7. Page 15 Life time attribute: More reasonable to have this attrib= ute in minutes rather than seconds, bigger default can also suggested > [TR] Changed to minutes I prefer seconds than minutes because I think granularity of minutes is rou= gh. If we are to leverage programmable and automated feature of DOTS, lifetime = in "seconds" is fine. Works for me. Ehud - Any specific reason for suggesting minutes ? -Tiru thank you, Kaname On 2017/02/16 23:00, Tirumaleswar Reddy (tireddy) wrote: Hi Ehud, Please see inline [TR2] From: Ehud Doron [mailto:EhudD@Radware.com] Sent: Thursday, February 16, 2017 6:43 PM To: Tirumaleswar Reddy (tireddy) ; 'dots' Cc: David Aviv Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 a= nd draft-reddy-dots-data-channel-03 . Tiru Hi Thanks for your response and clarifications. Please see inline (Followed after [Ehud] ) Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Tuesday, February 14, 2017 4:53 PM To: Ehud Doron >; 'dots' > Cc: David Aviv > Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 a= nd draft-reddy-dots-data-channel-03 . Hi Ehud, Thanks for the detailed review, Please see inline (I will respond to data c= hannel comments in a separate mail) From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron Sent: Wednesday, February 8, 2017 7:21 PM To: 'dots' > Cc: David Aviv > Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-0= 7 and draft-reddy-dots-data-channel-03 . Tiru and authors Hi Attached please find my comments and feedbacks to draft-reddy-dots-signal-c= hannel-07 and draft-reddy-dots-data-channel-03 . Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel = draft-reddy-dots-signal-channel-07 1. General comment: For all signals in the draft, need to add means t= o allow vendor specific attributes as part of all signals transactions [TR] Yes, will update draft. 2. General comment: Just for clarity, need to explicitly mention on e= ach figure when it is an example or the actual API [TR] Done. 3. Page 3 second paragraph : DOTS should not be limited to "enterpris= e network" only [TR] Agreed, fixed. 4. Page 4 chapter 4: The overall context of the "happy eyeballs" and = its relations (or coexistence) to CoAP is not clear. [TR] Happy eyeballs mechanism is used to reduce connection delay to setup (= D)TLS session with the DOTS server. Happy eyeballs mechanism is not related= to CoAP. 5. Page 7 chapter 5.2.1: The need for YANG model cannot be understood= from text. What are the needs for YANG models? What is the relation to the= JSONs in the other chapters in the draft [TR] YANG is a data modeling language used to model configuration and state= data; The configuration and state data defined using YANG can be represen= ted in JSON or CBOR or XML. Since CBOR is binary, JSON is used in the draft= but only for illustrative purpose. 6. Page 14 figure 5: The mitigation request attributes are right but = not enough. Need to add more telemetry info about the actual attack that it= is required to mitigate, need to consider attributes in draft-doron-dots-t= elemetry-00 as part of the discussion in the WG. [TR] Yes, I plan to update the draft with telemetry info based on outcome o= f draft-doron-dots-telemetry-00. 7. Page 15 Life time attribute: More reasonable to have this attribut= e in minutes rather than seconds, bigger default can also suggested [TR] Changed to minutes 8. Page 15 last paragraph: Not sure that target port or target protoc= ol can define a protected entity. IP, FQDN, URI are the only "stand alone" = attributes , port and protocol are companion attributes. See also figure 9 = . [TR] Good point, fixed. 9. Page 15 last paragraph: The mitigation request is not clear, to wh= ich identifier the text is related ? "policy ID" ? I think the best is ha= ve another attribute to define the priority of mitigation requests [TR] policy-id is specific to a DOTS client, DOTS server need not compare t= he policy-id of one customer with the policy-id of another customer. Policy= -ids are only compared b/w multiple mitigation requests from the same DOTS = client to determine the priority. DOTS signaling channel runs over UDP, and= packets may arrive out-of-order; this was also one of the reasons to intro= duce policy-id. [Ehud] Consider to update the text in page 15 with your explanations here, = mainly regarding the "per customer uniqueness of DOTS". [TR2] NEW: The relative order of two mitigation requests from a DOTS client is determi= ned by comparing their respective policy-id values. 10. Page 21 table: The return status are right but not enough. Need to ad= d more telemetry info about the actual mitigation going on (how much traffi= c was mitigated) and the attack that are mitigated, need to consider attrib= utes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. [TR] Same response as 6; for now will update the draft to convey the follow= ing telemetry info from the DOTS server : total dropped byte count, average= dropped bytes per second, total dropped packet count and average dropped p= ackets per second. The list is not complete, what kind of telemetry info is= required for L7 attacks (e.g. attack at TLS, partial HTTP request, garbage= request etc.) and how do we deal with new type of DDOS attacks (Do we keep= updating the spec as and when a new DDOS attack is discovered) ? [Ehud] Agreed with the bytes / packets count drop you proposed. For the Lay= er 7 telemetries and for DDoS attacks list , I think we should first get to= an agreement about the needs for this attributes and then figure out the b= est way to signal this information. Personally I don't believe we should up= date the spec for each attack, therefor we need to figure out an efficient = means to signal this information. [TR2] Agreed. 11. Page 15 : Need to find the way to bind the target-ips with target-por= t-ranges and target-protocols, meaning that the server needs to understand = the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on = so forth. [TR] Yes, it's possible; create different aliases for IP1 TCP port 80 and I= P 2 UDP port 53 using DOTS data channel and convey the aliases in DOTS sign= al channel. 12. Page 21 last paragraph: This is very strong point. [TR] Thanks. 13. Page 25 : Regarding attack status, same point about telemetry. [TR] Same response as above. 14. Page 25 chapter 5.4: I believe it can valuable to add a short high le= vel description about the proposed API flow, same as you did for 5.3 . [TR] 5.3 gives background how GET, POST, DELETE and PUT will be used, hence= did not see a need to add a high level description in Section 5.4. 15. Page 27: The necessity of policy_id here is not clear enough, are th= e "Signal Channel Session Configuration" define only "single" DOTS session = or the entire communication between Client and Server for several DOTS requ= est for mitigation? [TR] It's for a single DOTS session between DOTS client and server, a sing= le DOTS session can be used for several DOTS requests and responses. 16. Page 27: Not sure about the reason for "at least one of the attribute= s heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor = MUST be present." Also consider to change to "presented". [TR] what is the point in conveying a POST request without any configuratio= n parameters/attributes ? [Ehud] OK, understood. So I think you need to emphasize that in cases not a= ll attributes are defined, need to use default values. In page 26 you wrote= something about "need not be default". Consider to re-write. [TR2] NEW: The DOTS agents MUST use the negotiated values for message transmission parameters and default values for non-negotiated message transmission parameters. The signaling channel session configuration is applicable to a single DOTS signal channel session between the DOTS agents. -Tiru 17. Page 30 chapter 5.5: Need to specify the overall scenario, in reactio= n to which signal (or API transaction POST of Mitigation Request , unidirec= tional notification from Server as describes in page 23 in page 21 ?) the = redirection occurred ? [TR] Both, updated draft. -Tiru Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel dr= aft-reddy-dots-data-channel-03 1. General comment: For all signal in the draft, need to add means to= allow vendor specific attributes as part of all signals transactions 2. Page 5 second paragraph: Why it is required to configure the DOTS = signal channel session ? 3. Page 8 chapter 3.2.1 : Any reason for not including these identifi= ers in the DOTS signal channel draft ? 4. Page 9 figure 3 : Need to find the way to bind the target-ips with= target-port-ranges and target-protocols, meaning that the server needs to = understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53= and so on so forth. 5. Page 13 chapter 3.3 : Need to emphasize that filtering rules are r= elevant for both client server direct communication and through a DOTS gate= way. The chapter is a bit confusing. 6. Page 14 chapter 3.3 : I am missing the white-list installation, is= it by using the permit action ? 7. Page 15 figure 8: For DDoS it is highly valuable to have rate limi= t as an action. Consider adding such action (if already defined need to exp= lain where and how). 8. Page 15 figure 8: Need to consider adding priority to an ACL to su= pport cases when several filtering rules are conflicting. 9. Page 15 : The action field cannot be optional attribute. 10. Page 16 chapter 3.3.3: Need to add more telemetry info about the actu= al traffic that was blocked (bps, pps and so on), but as I believe this mig= ht be another issue... Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_5cbbc9aa610c43c28ae7c501ef8da35bXCHRCD017ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From:= kaname nishizuka [mailto:kaname@nttv6.jp]
Sent: Friday, February 24, 2017 10:17 AM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; Ehud Dor= on <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signa= l-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru,

I'd like to add a comment on lifetime attribute in signal-channel

> 7.       Page 15 Life time attribute: Mo= re reasonable to have this attribute in minutes rather than seconds, bigger= default can also suggested
> [TR] Changed to minutes

I prefer seconds than minutes because I think granularity of minutes is rou= gh.
If we are to leverage programmable and automated feature of DOTS, lifetime = in "seconds" is fine.

Works for me.

Ehud – Any specific reason for suggesting minutes ?

-Tiru

 



thank you,
Kaname

On 2017/02/16 23:00, Tirumaleswar Reddy (tireddy) wr= ote:

Hi Ehud,

 

Please see inline [TR2= ]

 

From: Ehud Doron [mailto:EhudD@Radware.com]
Sent: Thursday, February 16, 2017 6:43 PM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radw= are.com>
Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 .

 

Tiru Hi

 

Thanks for your respon= se and clarifications.

Please see inline (Fol= lowed after [Ehud] )

 

Thanks,

 

Ehud Doron <= span dir=3D"RTL">|  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Tuesday, February 14, 2017 4:53 PM
To: Ehud Doron <EhudD@Radwar= e.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radw= are.com>
Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 .

 

Hi Ehud,

 

Thanks for the detaile= d review, Please see inline (I will respond to data channel comments in a s= eparate mail)

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <dots@ietf.org>= ;
Cc: David Aviv <DavidA@Radw= are.com>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-ch= annel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru and authors Hi

 

Attached please find m= y comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-re= ddy-dots-data-channel-03 .

 

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy= -dots-signal-channel-07

 

1.     &= nbsp; General comment: For all signals in the draft, need= to add means to allow vendor specific attributes as part of all signals tr= ansactions

 

[TR] Yes, will update draft.

 

2.     &= nbsp; General comment: Just for clarity, need to explicit= ly mention on each figure when it is an example or the actual API

 

[TR] Done.

 

3.     &= nbsp; Page 3 second paragraph : DOTS should not be limite= d to “enterprise network” only

 

[TR] Agreed, fixed.

 

4.     &= nbsp; Page 4 chapter 4: The overall context of the “= ;happy eyeballs” and its relations (or coexistence) to CoAP is not cl= ear.  

 

[TR] Happy eyeballs me= chanism is used to reduce connection delay to setup (D)TLS session with the= DOTS server. Happy eyeballs mechanism is not related to CoAP.<= /o:p>

 

5.     &= nbsp; Page 7 chapter 5.2.1: The need for YANG model canno= t be understood from text. What are the needs for YANG models? What is the = relation to the JSONs in the other chapters in the draft

 

[TR] YANG is a data mo= deling language used to model configuration and state data;  The confi= guration and state data defined using YANG can be represented in JSON or CB= OR or XML. Since CBOR is binary, JSON is used in the draft but only for illustrative purpose.

 

6.     &= nbsp; Page 14 figure 5: The mitigation request attributes= are right but not enough. Need to add more telemetry info about the actual= attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

[TR] Yes, I plan to up= date the draft with telemetry info based on outcome of draft-doron-dots-tel= emetry-00.

 

7.     &= nbsp; Page 15 Life time attribute: More reasonable to have this attribute in minutes rather tha= n seconds, bigger default can also suggested

 

[TR] Changed to minute= s

 

8.     &= nbsp; Page 15 last paragraph: Not sure that target port or target protocol can define a protect= ed entity. IP, FQDN, URI are the only “stand alone” attributes = , port and protocol are companion attributes. See also figure 9 .

 

[TR] Good point, fixed= .

 

9.     &= nbsp; Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is relate= d ?   “policy ID” ? I think the best is have another = attribute to define the priority of mitigation requests

[TR] policy-id is spec= ific to a DOTS client, DOTS server need not compare the policy-id of one cu= stomer with the policy-id of another customer. Policy-ids are only compared= b/w multiple mitigation requests from the same DOTS client to determine the priority. DOTS signaling channel run= s over UDP, and packets may arrive out-of-order; this was also one of the r= easons to introduce policy-id.

[Ehud] Consider to upd= ate the text in page 15 with your explanations here, mainly regarding the &= #8220;per customer uniqueness of DOTS”.

 

[TR2] NEW:=

The relative order of = two mitigation requests from a DOTS client is determined by comparing their= respective policy-id values.

 

10.   Page 21 table: The return status are right but not = enough. Need to add more telemetry info about the actual mitigation going o= n (how much traffic was mitigated) and the attack that are mitigated, need = to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

[TR] Same response as 6; for now will update the draft to convey the following telemetry info fro= m the DOTS server : total dropped byte count, average dropped byt= es per second, total dropped packet count and average dropped packets per s= econd. The list is not complete, what kind of telemetry info is required fo= r L7 attacks (e.g. attack at TLS, partial HTTP request, garbage request etc.) and how do we deal with new ty= pe of DDOS attacks (Do we keep updating the spec as and when a new DDOS att= ack is discovered) ?

[Ehud] Agreed with the= bytes / packets count drop you proposed. For the Layer 7 telemetries and f= or DDoS attacks list , I think we should first get to an agreement about th= e needs for this attributes and then figure out the best way to signal this information. Personally I don’= ;t believe we should update the spec for each attack, therefor we need to f= igure out an efficient means to signal this information.  =

 

[TR2] Agreed.

 

11.   Page 15 : Need to find the way to bind the target-i= ps with target-port-ranges and target-protocols, meani= ng that the server needs to understand the exact scope of attack, e.g. IP1 = TCP port 80, IP2 UDP port 53 and so on so forth.

 

[TR] Yes, it’s p= ossible; create different aliases for IP1 TCP port 80 and IP 2 UDP port 53 = using DOTS data channel and convey the aliases in DOTS signal channel.

 

12.   Page 21 last paragraph: This is very strong point.<= o:p>

 

[TR] Thanks.

 

13.   Page 25 : Regarding attack status, same point about= telemetry.

 

[TR] Same response as above.

 

14.   Page 25 chapter 5.4: I believe it can valuable to a= dd a short high level description about the proposed API flow, same as you = did for 5.3 .

 

[TR] 5.3 gives backgro= und how GET, POST, DELETE and PUT will be used, hence did not see a need to= add a high level description in Section 5.4.

 

 

15.   Page 27:  The necessity of policy_id here is n= ot clear enough, are the “Signal Channel Session Configuration”= define only “single” DOTS session or the entire communication = between Client and Server for several DOTS request for mitigation?

 

[TR]  It’s = for a single DOTS session between DOTS client and server, a single DOTS ses= sion can be used for several DOTS requests and responses.=

 

16.   Page 27: Not sure about the reason for “at le= ast one of the attributes heartbeat-interval or max-retransmit or ack-timeo= ut or ack-random-factor MUST be present.” Also consider to change to = “presented”.

 

[TR] what is the point in conveying a POST request with=
out any configuration parameters/attributes ?
[Ehud] OK, understood. So I think you need to emphasize=
 that in cases not all attributes are defined, need to use default values. =
In page 26 you wrote something about “need not be default”. Con=
sider to re-write. 
 
[TR2] NEW:
The DOTS agents MUST use the negotiated values for message transmissio=
n
parameters and default values for non-negotiated message transmission<=
o:p>
parameters.  The signaling channel session configuration is<=
/o:p>
applicable to a single DOTS signal channel session between the DOTS
agents. 

 

-Tiru

 

17.   Page 30 chapter 5.5: Need to specify the overall sc= enario, in reaction to which signal (or API transaction POST of Mitigation = Request , unidirectional notification from Server as describes in page 23 i= n page 21 ?) the  redirection occurred ?

 

[TR] Both, updated dra= ft.

 

-Tiru

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-d= ots-data-channel-03

 

1.     &= nbsp; General comment: For all signal in the draft, need = to add means to allow vendor specific attributes as part of all signals tra= nsactions

 

2.     &= nbsp; Page 5 second paragraph: Why it is required to conf= igure the DOTS signal channel session ?  

 

3.     &= nbsp; Page 8 chapter 3.2.1 : Any reason for not including= these identifiers in the DOTS signal channel draft ?

 

4.     &= nbsp; Page 9 figure 3 : Need to find the way to bind the = target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e= .g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

5.     &= nbsp; Page 13 chapter 3.3 : Need to emphasize that filter= ing rules are relevant for both client server direct communication and thro= ugh a DOTS gateway. The chapter is a bit confusing.

 

6.     &= nbsp; Page 14 chapter 3.3 : I am missing the white-list i= nstallation, is it by using the permit action ?

 

7.     &= nbsp; Page 15 figure 8: For DDoS it is highly valuable to= have rate limit as an action. Consider adding such action (if already defi= ned need to explain where and how).

 

8.     &= nbsp; Page 15 figure 8: Need to consider adding priority = to an ACL to support cases when several filtering rules are conflicting.

 

9.     &= nbsp; Page 15 : The action field cannot be optional attri= bute.

 

10.   Page 16 chapter 3.3.3: Need to add more telemetry i= nfo about the actual traffic that was blocked (bps, pps and so on), but as = I believe this might be another issue…

 

 

 

Thanks,

 

Ehud Doron <= span dir=3D"RTL">|  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

 




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

 

--_000_5cbbc9aa610c43c28ae7c501ef8da35bXCHRCD017ciscocom_-- From nobody Tue Feb 28 01:14:22 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633DE126D74 for ; Tue, 28 Feb 2017 01:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 KMpUQFY3BFL6 for ; Tue, 28 Feb 2017 01:14:12 -0800 (PST) Received: from mailout1.radware.com (mailout1.radware.com [192.115.180.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5741294C6 for ; Tue, 28 Feb 2017 01:14:11 -0800 (PST) Received: from ILMB2.corp.radware.com ([169.254.2.155]) by ILCAS1.corp.radware.com ([176.200.120.121]) with mapi id 14.03.0319.002; Tue, 28 Feb 2017 11:14:09 +0200 From: Ehud Doron To: "Tirumaleswar Reddy (tireddy)" , "mohamed.boucadair@orange.com" , "Mortensen, Andrew" , "dots@ietf.org" Thread-Topic: merging requirements and use cases drafts? Thread-Index: AQHSkSlHPjfCqL/HTUaPO9bSB5JdCKF+D3eQgAARtRCAAAJBUA== Date: Tue, 28 Feb 2017 09:14:08 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933009E1989A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [176.200.120.205] x-tm-as-product-ver: SMEX-11.0.0.4179-8.100.1062-22912.006 x-tm-as-result: No--21.840000-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] merging requirements and use cases drafts? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 09:14:16 -0000 QWxsDQoNCisxIG9uIHRoYXQsIEkgcHJlZmVyIHRvIGtlZXAgdGhlbSBzZXBhcmF0ZS4NCg0KVGhh bmtzLCBFaHVkDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEb3RzIFttYWls dG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGlydW1hbGVzd2FyIFJlZGR5 ICh0aXJlZGR5KQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMjgsIDIwMTcgMTE6MDggQU0NClRv OiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBNb3J0ZW5zZW4sIEFuZHJldyA8YW1vcnRl bnNlbkBhcmJvci5uZXQ+OyBkb3RzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RvdHNdIG1lcmdp bmcgcmVxdWlyZW1lbnRzIGFuZCB1c2UgY2FzZXMgZHJhZnRzPw0KDQpJIHByZWZlciB0byBrZWVw IHRoZW0gc2VwYXJhdGUuDQoNCi1UaXJ1DQogDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiANCj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiBTZW50OiBUdWVzZGF5LCBGZWJy dWFyeSAyOCwgMjAxNyAxOjM3IFBNDQo+IFRvOiBNb3J0ZW5zZW4sIEFuZHJldyA8YW1vcnRlbnNl bkBhcmJvci5uZXQ+OyBkb3RzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbRG90c10gbWVyZ2lu ZyByZXF1aXJlbWVudHMgYW5kIHVzZSBjYXNlcyBkcmFmdHM/DQo+IA0KPiBIaSBBbmRyZXcsIGFs bCwNCj4gDQo+IEkgaGF2ZSBhbiBhbHRlcm5hdGUgcHJvcG9zYWw6DQo+ICogTWFpbnRhaW4gdGhl IHJlcXVpcmVtZW50cyBkcmFmdCB3aXRoIGl0cyBpbml0aWFsIHNjb3BlLg0KPiAqIEFiYW5kb24g dGhlIHVzZSBjYXNlcyBkcmFmdC4NCj4gDQo+IEkgZG9uJ3Qgc2VlIG11Y2ggdmFsdWUgaW4gcHVi bGlzaGluZyB0aGUgdXNlIGNhc2UgSS1EIGFzIGFuIFJGQy4gVGhlIA0KPiByZXF1aXJlbWVudHMg SS1EIGlzIHJlYWxseSBpbXBvcnRhbnQgYXMgaXQgc2tldGNoZXMgdGhlIHNjb3BlIGFuZCANCj4g cmVxdWlyZWQgRE9UUyBmdW5jdGlvbmFsaXRpZXMuDQo+IA0KPiBDaGVlcnMsDQo+IE1lZA0KPiAN Cj4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiBEZcKgOiBEb3RzIFttYWlsdG86 ZG90cy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE1vcnRlbnNlbiwgDQo+ID4gQW5k cmV3IEVudm95w6nCoDogbHVuZGkgMjcgZsOpdnJpZXIgMjAxNyAxOTo0MyDDgMKgOiBkb3RzQGll dGYub3JnIE9iamV0wqA6DQo+ID4gW0RvdHNdIG1lcmdpbmcgcmVxdWlyZW1lbnRzIGFuZCB1c2Ug Y2FzZXMgZHJhZnRzPw0KPiA+DQo+ID4gRHVyaW5nIHRoZSBpbnRlcmltIG1lZXRpbmcsIEthdGhs ZWVuIE1vcmlhcnR5IG9ic2VydmVkIHRoYXQgaXQgbWlnaHQgDQo+ID4gYmUgYmVuZWZpY2lhbCB0 byBtZXJnZSB0aGUgcmVxdWlyZW1lbnRzIGFuZCB1c2UgY2FzZXMgZHJhZnRzLCBzaW5jZSANCj4g PiB0aGUgSUVTRyB0ZW5kcyB0byBsb29rIG1vcmUgZmF2b3JhYmx5IG9uIHN1Y2ggZHJhZnRzLg0K PiA+DQo+ID4gV2UgZGlkIG5vdCBjb250aW51ZSB0aGF0IGRpc2N1c3Npb24gZHVyaW5nIHRoZSBp bnRlcmltIG1lZXRpbmcsIGR1ZSANCj4gPiB0byBsaW1pdGVkIHRpbWUsIGJ1dCBJIHRoaW5rIGl0 4oCZcyBzb21ldGhpbmcgd2UgbmVlZCB0byBkaXNjdXNzIGFoZWFkIA0KPiA+IG9mIHRoZSBtZWV0 aW5nIGluIENoaWNhZ28uIFRvIGJlZ2luIHdpdGgsIEnigJlkIGxpa2UgdG8gaGVhciBhIGxpdHRs ZSANCj4gPiBtb3JlIGZyb20gS2F0aGxlZW4gYWJvdXQgd2h5IGEgbWVyZ2VkIGRyYWZ0IGlzIGxp a2VseSB0byBiZSBtb3JlIA0KPiA+IHBhbGF0YWJsZSB0byB0aGUgSUVTRy4gSWYgbm90aGluZyBl bHNlLCBpdOKAmWQgYmUgbmljZSB0byBhdm9pZCBjb21pbmcgDQo+ID4gdG8gdGhlIHRvcGljIGNv bGQgaW4gQ2hpY2Fnby4NCj4gPg0KPiA+IGFuZHJldw0KPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiBE b3RzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k b3RzDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IERvdHMgbWFpbGluZyBsaXN0DQo+IERvdHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KRG90cyBtYWlsaW5nIGxpc3QNCkRvdHNAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0K From nobody Tue Feb 28 06:57:31 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFF11295BC for ; Tue, 28 Feb 2017 06:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 gonyVgThgvWo for ; Tue, 28 Feb 2017 06:57:26 -0800 (PST) Received: from mailout1.radware.com (mailout1.radware.com [192.115.180.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27871295B8 for ; Tue, 28 Feb 2017 06:57:25 -0800 (PST) Received: from ILMB2.corp.radware.com ([169.254.2.155]) by ILCAS1.corp.radware.com ([176.200.120.121]) with mapi id 14.03.0319.002; Tue, 28 Feb 2017 16:57:23 +0200 From: Ehud Doron To: "Tirumaleswar Reddy (tireddy)" , kaname nishizuka , 'dots' Thread-Topic: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . Thread-Index: AdKCER/slEaaT/pbTQCa8ffUgEh/YgEvK4mgADZ1NNAALTMmUAF687AAANJ9IoAAD6XWwA== Date: Tue, 28 Feb 2017 14:57:23 +0000 Message-ID: References: <331a77a5ec074db69cf2bc2715a7645e@XCH-RCD-017.cisco.com> <3bab57f083c346cfb491c29c7ff369dd@XCH-RCD-017.cisco.com> <7dcc6611-18f5-7d89-2386-8e5ee22c94b6@nttv6.jp> <5cbbc9aa610c43c28ae7c501ef8da35b@XCH-RCD-017.cisco.com> In-Reply-To: <5cbbc9aa610c43c28ae7c501ef8da35b@XCH-RCD-017.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [176.200.121.207] x-tm-as-product-ver: SMEX-11.0.0.4179-8.100.1062-22912.007 x-tm-as-result: No--19.522900-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E58182C4A35A8E498E553AD3D33FA00101171A9467ILMB2corpradw_" MIME-Version: 1.0 Archived-At: Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 14:57:30 -0000 --_000_E58182C4A35A8E498E553AD3D33FA00101171A9467ILMB2corpradw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tiru, Kaname As this attribute is defined as the lifetime of the all mitigation request = (i.e. the entire attack period), as per my knowledge this kind of period ca= n typically be relatively long (hours and more), so that why minutes can b= e more comfortable to operate. However if Kaname thinks seconds is better as it is more granular, this can= be suggested here as well. Thanks, Ehud From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Tuesday, February 28, 2017 11:14 AM To: kaname nishizuka ; Ehud Doron ; 'do= ts' Cc: David Aviv Subject: RE: [Dots] Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 . From: kaname nishizuka [mailto:kaname@nttv6.jp] Sent: Friday, February 24, 2017 10:17 AM To: Tirumaleswar Reddy (tireddy) >; Ehud Doron >; 'dots' > Cc: David Aviv > Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 . Hi Tiru, I'd like to add a comment on lifetime attribute in signal-channel > 7. Page 15 Life time attribute: More reasonable to have this attrib= ute in minutes rather than seconds, bigger default can also suggested > [TR] Changed to minutes I prefer seconds than minutes because I think granularity of minutes is rou= gh. If we are to leverage programmable and automated feature of DOTS, lifetime = in "seconds" is fine. Works for me. Ehud - Any specific reason for suggesting minutes ? -Tiru thank you, Kaname On 2017/02/16 23:00, Tirumaleswar Reddy (tireddy) wrote: Hi Ehud, Please see inline [TR2] From: Ehud Doron [mailto:EhudD@Radware.com] Sent: Thursday, February 16, 2017 6:43 PM To: Tirumaleswar Reddy (tireddy) ; 'dots' Cc: David Aviv Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 a= nd draft-reddy-dots-data-channel-03 . Tiru Hi Thanks for your response and clarifications. Please see inline (Followed after [Ehud] ) Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Tuesday, February 14, 2017 4:53 PM To: Ehud Doron >; 'dots' > Cc: David Aviv > Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 a= nd draft-reddy-dots-data-channel-03 . Hi Ehud, Thanks for the detailed review, Please see inline (I will respond to data c= hannel comments in a separate mail) From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron Sent: Wednesday, February 8, 2017 7:21 PM To: 'dots' > Cc: David Aviv > Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-0= 7 and draft-reddy-dots-data-channel-03 . Tiru and authors Hi Attached please find my comments and feedbacks to draft-reddy-dots-signal-c= hannel-07 and draft-reddy-dots-data-channel-03 . Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel = draft-reddy-dots-signal-channel-07 1. General comment: For all signals in the draft, need to add means t= o allow vendor specific attributes as part of all signals transactions [TR] Yes, will update draft. 2. General comment: Just for clarity, need to explicitly mention on e= ach figure when it is an example or the actual API [TR] Done. 3. Page 3 second paragraph : DOTS should not be limited to "enterpris= e network" only [TR] Agreed, fixed. 4. Page 4 chapter 4: The overall context of the "happy eyeballs" and = its relations (or coexistence) to CoAP is not clear. [TR] Happy eyeballs mechanism is used to reduce connection delay to setup (= D)TLS session with the DOTS server. Happy eyeballs mechanism is not related= to CoAP. 5. Page 7 chapter 5.2.1: The need for YANG model cannot be understood= from text. What are the needs for YANG models? What is the relation to the= JSONs in the other chapters in the draft [TR] YANG is a data modeling language used to model configuration and state= data; The configuration and state data defined using YANG can be represen= ted in JSON or CBOR or XML. Since CBOR is binary, JSON is used in the draft= but only for illustrative purpose. 6. Page 14 figure 5: The mitigation request attributes are right but = not enough. Need to add more telemetry info about the actual attack that it= is required to mitigate, need to consider attributes in draft-doron-dots-t= elemetry-00 as part of the discussion in the WG. [TR] Yes, I plan to update the draft with telemetry info based on outcome o= f draft-doron-dots-telemetry-00. 7. Page 15 Life time attribute: More reasonable to have this attribut= e in minutes rather than seconds, bigger default can also suggested [TR] Changed to minutes 8. Page 15 last paragraph: Not sure that target port or target protoc= ol can define a protected entity. IP, FQDN, URI are the only "stand alone" = attributes , port and protocol are companion attributes. See also figure 9 = . [TR] Good point, fixed. 9. Page 15 last paragraph: The mitigation request is not clear, to wh= ich identifier the text is related ? "policy ID" ? I think the best is ha= ve another attribute to define the priority of mitigation requests [TR] policy-id is specific to a DOTS client, DOTS server need not compare t= he policy-id of one customer with the policy-id of another customer. Policy= -ids are only compared b/w multiple mitigation requests from the same DOTS = client to determine the priority. DOTS signaling channel runs over UDP, and= packets may arrive out-of-order; this was also one of the reasons to intro= duce policy-id. [Ehud] Consider to update the text in page 15 with your explanations here, = mainly regarding the "per customer uniqueness of DOTS". [TR2] NEW: The relative order of two mitigation requests from a DOTS client is determi= ned by comparing their respective policy-id values. 10. Page 21 table: The return status are right but not enough. Need to ad= d more telemetry info about the actual mitigation going on (how much traffi= c was mitigated) and the attack that are mitigated, need to consider attrib= utes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. [TR] Same response as 6; for now will update the draft to convey the follow= ing telemetry info from the DOTS server : total dropped byte count, average= dropped bytes per second, total dropped packet count and average dropped p= ackets per second. The list is not complete, what kind of telemetry info is= required for L7 attacks (e.g. attack at TLS, partial HTTP request, garbage= request etc.) and how do we deal with new type of DDOS attacks (Do we keep= updating the spec as and when a new DDOS attack is discovered) ? [Ehud] Agreed with the bytes / packets count drop you proposed. For the Lay= er 7 telemetries and for DDoS attacks list , I think we should first get to= an agreement about the needs for this attributes and then figure out the b= est way to signal this information. Personally I don't believe we should up= date the spec for each attack, therefor we need to figure out an efficient = means to signal this information. [TR2] Agreed. 11. Page 15 : Need to find the way to bind the target-ips with target-por= t-ranges and target-protocols, meaning that the server needs to understand = the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on = so forth. [TR] Yes, it's possible; create different aliases for IP1 TCP port 80 and I= P 2 UDP port 53 using DOTS data channel and convey the aliases in DOTS sign= al channel. 12. Page 21 last paragraph: This is very strong point. [TR] Thanks. 13. Page 25 : Regarding attack status, same point about telemetry. [TR] Same response as above. 14. Page 25 chapter 5.4: I believe it can valuable to add a short high le= vel description about the proposed API flow, same as you did for 5.3 . [TR] 5.3 gives background how GET, POST, DELETE and PUT will be used, hence= did not see a need to add a high level description in Section 5.4. 15. Page 27: The necessity of policy_id here is not clear enough, are th= e "Signal Channel Session Configuration" define only "single" DOTS session = or the entire communication between Client and Server for several DOTS requ= est for mitigation? [TR] It's for a single DOTS session between DOTS client and server, a sing= le DOTS session can be used for several DOTS requests and responses. 16. Page 27: Not sure about the reason for "at least one of the attribute= s heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor = MUST be present." Also consider to change to "presented". [TR] what is the point in conveying a POST request without any configuratio= n parameters/attributes ? [Ehud] OK, understood. So I think you need to emphasize that in cases not a= ll attributes are defined, need to use default values. In page 26 you wrote= something about "need not be default". Consider to re-write. [TR2] NEW: The DOTS agents MUST use the negotiated values for message transmission parameters and default values for non-negotiated message transmission parameters. The signaling channel session configuration is applicable to a single DOTS signal channel session between the DOTS agents. -Tiru 17. Page 30 chapter 5.5: Need to specify the overall scenario, in reactio= n to which signal (or API transaction POST of Mitigation Request , unidirec= tional notification from Server as describes in page 23 in page 21 ?) the = redirection occurred ? [TR] Both, updated draft. -Tiru Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel dr= aft-reddy-dots-data-channel-03 1. General comment: For all signal in the draft, need to add means to= allow vendor specific attributes as part of all signals transactions 2. Page 5 second paragraph: Why it is required to configure the DOTS = signal channel session ? 3. Page 8 chapter 3.2.1 : Any reason for not including these identifi= ers in the DOTS signal channel draft ? 4. Page 9 figure 3 : Need to find the way to bind the target-ips with= target-port-ranges and target-protocols, meaning that the server needs to = understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53= and so on so forth. 5. Page 13 chapter 3.3 : Need to emphasize that filtering rules are r= elevant for both client server direct communication and through a DOTS gate= way. The chapter is a bit confusing. 6. Page 14 chapter 3.3 : I am missing the white-list installation, is= it by using the permit action ? 7. Page 15 figure 8: For DDoS it is highly valuable to have rate limi= t as an action. Consider adding such action (if already defined need to exp= lain where and how). 8. Page 15 figure 8: Need to consider adding priority to an ACL to su= pport cases when several filtering rules are conflicting. 9. Page 15 : The action field cannot be optional attribute. 10. Page 16 chapter 3.3.3: Need to add more telemetry info about the actu= al traffic that was blocked (bps, pps and so on), but as I believe this mig= ht be another issue... Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_E58182C4A35A8E498E553AD3D33FA00101171A9467ILMB2corpradw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru, Kaname <= /o:p>

 

As this attribute is d= efined as the lifetime of the all mitigation request (i.e. the entire attac= k period), as per my knowledge this kind of period can typically be relativ= ely long (hours and more),  so that why minutes can be more comfortable to operate.

However if Kaname thin= ks seconds is better as it is more granular, this can be suggested here as = well.

 

Thanks, Ehud

 

From:= Tirumaleswar Reddy (tireddy) [mailto:tire= ddy@cisco.com]
Sent: Tuesday, February 28, 2017 11:14 AM
To: kaname nishizuka <kaname@nttv6.jp>; Ehud Doron <EhudD@R= adware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: RE: [Dots] Comments and feedbacks on draft-reddy-dots-signa= l-channel-07 and draft-reddy-dots-data-channel-03 .

 

From:= kaname nishizuka [mailto:kaname@nttv6.jp]
Sent: Friday, February 24, 2017 10:17 AM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; Ehud Doron <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radw= are.com>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signa= l-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru,

I'd like to add a comment on lifetime attribute in signal-channel

> 7.       Page 15 Life time attribute: Mo= re reasonable to have this attribute in minutes rather than seconds, bigger= default can also suggested
> [TR] Changed to minutes

I prefer seconds than minutes because I think granularity of minutes is rou= gh.
If we are to leverage programmable and automated feature of DOTS, lifetime = in "seconds" is fine.

Works for me.

Ehud – Any specific reason for suggesting minutes ?

-Tiru

 



thank you,
Kaname

On 2017/02/16 23:00, Tirumaleswar Reddy (tireddy) wr= ote:

Hi Ehud,

 

Please see inline [TR2= ]

 

From: Ehud Doron [mailto:EhudD@Radware.com]
Sent: Thursday, February 16, 2017 6:43 PM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radw= are.com>
Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 .

 

Tiru Hi

 

Thanks for your respon= se and clarifications.

Please see inline (Fol= lowed after [Ehud] )

 

Thanks,

 

Ehud Doron |=  Senior Architect, Radware CTO office | M:<= span style=3D"font-size:10.0pt;font-family:"Tahoma",sans-serif;co= lor:#999999"> +972-54-7575503 | T: +972-72-3917120

 

 

 

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Tuesday, February 14, 2017 4:53 PM
To: Ehud Doron <EhudD@Radwar= e.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radw= are.com>
Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 .

 

Hi Ehud,

 

Thanks for the detaile= d review, Please see inline (I will respond to data channel comments in a s= eparate mail)

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <dots@ietf.org>= ;
Cc: David Aviv <DavidA@Radw= are.com>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-ch= annel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru and authors Hi

 

Attached please find m= y comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-re= ddy-dots-data-channel-03 .

 

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy= -dots-signal-channel-07

 

1.     &= nbsp; General comment: For all s= ignals in the draft, need to add means to allow vendor specific attributes = as part of all signals transactions

 

[TR] Yes, will update draft.

 

2.     &= nbsp; General comment: Just for = clarity, need to explicitly mention on each figure when it is an example or= the actual API

 

[TR] Done.

 

3.     &= nbsp; Page 3 second paragraph : = DOTS should not be limited to “enterprise network” only

 

[TR] Agreed, fixed.

 

4.     &= nbsp; Page 4 chapter 4: The over= all context of the “happy eyeballs” and its relations (or coexi= stence) to CoAP is not clear.  

 

[TR] Happy eyeballs me= chanism is used to reduce connection delay to setup (D)TLS session with the= DOTS server. Happy eyeballs mechanism is not related to CoAP.<= /o:p>

 

5.     &= nbsp; Page 7 chapter 5.2.1: The = need for YANG model cannot be understood from text. What are the needs for = YANG models? What is the relation to the JSONs in the other chapters in the= draft

 

[TR] YANG is a data mo= deling language used to model configuration and state data;  The confi= guration and state data defined using YANG can be represented in JSON or CB= OR or XML. Since CBOR is binary, JSON is used in the draft but only for illustrative purpose.

 

6.     &= nbsp; Page 14 figure 5: The miti= gation request attributes are right but not enough. Need to add more teleme= try info about the actual attack that it is required to mitigate, need to c= onsider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

[TR] Yes, I plan to up= date the draft with telemetry info based on outcome of draft-doron-dots-tel= emetry-00.

 

7.     &= nbsp; Page 15 Life time attribut= e: More reasonable to have this attrib= ute in minutes rather than seconds, bigger default can also suggested

 

[TR] Changed to minute= s

 

8.     &= nbsp; Page 15 last paragraph: Not sure that target port or target prot= ocol can define a protected entity. IP, FQDN, URI are the only “stand= alone” attributes , port and protocol are companion attributes. See also figure 9 .

 

[TR] Good point, fixed= .

 

9.     &= nbsp; Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is= related ?   “policy ID” ? I think the best is have a= nother attribute to define the priority of mitigation requests

[TR] policy-id is spec= ific to a DOTS client, DOTS server need not compare the policy-id of one cu= stomer with the policy-id of another customer. Policy-ids are only compared= b/w multiple mitigation requests from the same DOTS client to determine the priority. DOTS signaling channel run= s over UDP, and packets may arrive out-of-order; this was also one of the r= easons to introduce policy-id.

[Ehud] Consider to upd= ate the text in page 15 with your explanations here, mainly regarding the &= #8220;per customer uniqueness of DOTS”.

 

[TR2] NEW:=

The relative order of = two mitigation requests from a DOTS client is determined by comparing their= respective policy-id values.

 

10.   Page 21 table: The return = status are right but not enough. Need to add more telemetry info about the = actual mitigation going on (how much traffic was mitigated) and the attack = that are mitigated, need to consider attributes in draft-doron-dots-telemetry-00 = as part of the discussion in the WG.

 

[TR] Same response as 6; for now will update the draft to convey the following telemetry info fro= m the DOTS server : total dropped byte count, average dropped byt= es per second, total dropped packet count and average dropped packets per s= econd. The list is not complete, what kind of telemetry info is required fo= r L7 attacks (e.g. attack at TLS, partial HTTP request, garbage request etc.) and how do we deal with new ty= pe of DDOS attacks (Do we keep updating the spec as and when a new DDOS att= ack is discovered) ?

[Ehud] Agreed with the= bytes / packets count drop you proposed. For the Layer 7 telemetries and f= or DDoS attacks list , I think we should first get to an agreement about th= e needs for this attributes and then figure out the best way to signal this information. Personally I don’= ;t believe we should update the spec for each attack, therefor we need to f= igure out an efficient means to signal this information.  =

 

[TR2] Agreed.

 

11.   Page 15 : Need to find the= way to bind the target-ips with target-port-ranges and targe= t-protocols, meaning that the server needs to understand the exact s= cope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

[TR] Yes, it’s p= ossible; create different aliases for IP1 TCP port 80 and IP 2 UDP port 53 = using DOTS data channel and convey the aliases in DOTS signal channel.

 

12.   Page 21 last paragraph: Th= is is very strong point.

 

[TR] Thanks.

 

13.   Page 25 : Regarding attack= status, same point about telemetry.

 

[TR] Same response as above.

 

14.   Page 25 chapter 5.4: I bel= ieve it can valuable to add a short high level description about the propos= ed API flow, same as you did for 5.3 .

 

[TR] 5.3 gives backgro= und how GET, POST, DELETE and PUT will be used, hence did not see a need to= add a high level description in Section 5.4.

 

 

15.   Page 27:  The necessi= ty of policy_id here is not clear enough, are the “Signal Channel Ses= sion Configuration” define only “single” DOTS session or = the entire communication between Client and Server for several DOTS request for mitigation?

 

[TR]  It’s = for a single DOTS session between DOTS client and server, a single DOTS ses= sion can be used for several DOTS requests and responses.=

 

16.   Page 27: Not sure about th= e reason for “at least one of the attributes heartbeat-interval or ma= x-retransmit or ack-timeout or ack-random-factor MUST be present.” Al= so consider to change to “presented”.

 

[TR] what is the point in conveying a POST request with=
out any configuration parameters/attributes ?
[Ehud] OK, understood. So I think you need to emphasize=
 that in cases not all attributes are defined, need to use default values. =
In page 26 you wrote something about “need not be default”. Con=
sider to re-write. 
 
[TR2] NEW:
The DOTS agents MUST use the negotiated values for message transmissio=
n
parameters and default values for non-negotiated message transmission<=
o:p>
parameters.  The signaling channel session configuration is<=
/o:p>
applicable to a single DOTS signal channel session between the DOTS
agents. 

 

-Tiru

 

17.   Page 30 chapter 5.5: Need = to specify the overall scenario, in reaction to which signal (or API transa= ction POST of Mitigation Request , unidirectional notification from Server = as describes in page 23 in page 21 ?) the  redirection occurred ?

 

[TR] Both, updated dra= ft.

 

-Tiru

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-d= ots-data-channel-03

 

1.     &= nbsp; General comment: For all s= ignal in the draft, need to add means to allow vendor specific attributes a= s part of all signals transactions

 

2.     &= nbsp; Page 5 second paragraph: W= hy it is required to configure the DOTS signal channel session ?  

 

3.     &= nbsp; Page 8 chapter 3.2.1 : Any= reason for not including these identifiers in the DOTS signal channel draf= t ?

 

4.     &= nbsp; Page 9 figure 3 : Need to = find the way to bind the target-ips with target-port-ranges a= nd target-protocols, meaning that the server needs to understand the= exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

5.     &= nbsp; Page 13 chapter 3.3 : Need= to emphasize that filtering rules are relevant for both client server dire= ct communication and through a DOTS gateway. The chapter is a bit confusing= .

 

6.     &= nbsp; Page 14 chapter 3.3 : I am= missing the white-list installation, is it by using the permit action ?

 

7.     &= nbsp; Page 15 figure 8: For DDoS= it is highly valuable to have rate limit as an action. Consider adding suc= h action (if already defined need to explain where and how).

 

8.     &= nbsp; Page 15 figure 8: Need to = consider adding priority to an ACL to support cases when several filtering = rules are conflicting.

 

9.     &= nbsp; Page 15 : The action field= cannot be optional attribute.

 

10.   Page 16 chapter 3.3.3: Nee= d to add more telemetry info about the actual traffic that was blocked (bps= , pps and so on), but as I believe this might be another issue…

 

 

 

Thanks,

 

Ehud Doron |=  Senior Architect, Radware CTO office | M:<= span style=3D"font-size:10.0pt;font-family:"Tahoma",sans-serif;co= lor:#999999"> +972-54-7575503 | T: +972-72-3917120

 

 

 

 



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

 

--_000_E58182C4A35A8E498E553AD3D33FA00101171A9467ILMB2corpradw_-- From nobody Tue Feb 28 11:26:49 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB17D129693 for ; Tue, 28 Feb 2017 11:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.245 X-Spam-Level: X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=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 gMzzCJB0rG_L for ; Tue, 28 Feb 2017 11:26:46 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D507C1294FD for ; Tue, 28 Feb 2017 11:26:45 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Tue, 28 Feb 2017 14:26:43 -0500 From: Dave Dolson To: Ehud Doron , "Tirumaleswar Reddy (tireddy)" , kaname nishizuka , 'dots' Thread-Topic: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . Thread-Index: AdKCER/slEaaT/pbTQCa8ffUgEh/YgEvK4mgADZ1NNAALTMmUAGJnsgAANJ9IoAADABSgAABKgcA Date: Tue, 28 Feb 2017 19:26:43 +0000 Message-ID: References: <331a77a5ec074db69cf2bc2715a7645e@XCH-RCD-017.cisco.com> <3bab57f083c346cfb491c29c7ff369dd@XCH-RCD-017.cisco.com> <7dcc6611-18f5-7d89-2386-8e5ee22c94b6@nttv6.jp> <5cbbc9aa610c43c28ae7c501ef8da35b@XCH-RCD-017.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E987052C944wtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 19:26:48 -0000 --_000_E8355113905631478EFF04F5AA706E987052C944wtlexchp1sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In my opinion, units of seconds are preferable in a protocol, if only becau= se they are the base S.I. unit. Any user interface (or programming interface) can easily convert minutes to= seconds if desired. From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron Sent: Tuesday, February 28, 2017 9:57 AM To: Tirumaleswar Reddy (tireddy); kaname nishizuka; 'dots' Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 . Hi Tiru, Kaname As this attribute is defined as the lifetime of the all mitigation request = (i.e. the entire attack period), as per my knowledge this kind of period ca= n typically be relatively long (hours and more), so that why minutes can b= e more comfortable to operate. However if Kaname thinks seconds is better as it is more granular, this can= be suggested here as well. Thanks, Ehud From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Tuesday, February 28, 2017 11:14 AM To: kaname nishizuka ; Ehud Doron ; 'do= ts' Cc: David Aviv Subject: RE: [Dots] Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 . From: kaname nishizuka [mailto:kaname@nttv6.jp] Sent: Friday, February 24, 2017 10:17 AM To: Tirumaleswar Reddy (tireddy) >; Ehud Doron >; 'dots' > Cc: David Aviv > Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 . Hi Tiru, I'd like to add a comment on lifetime attribute in signal-channel > 7. Page 15 Life time attribute: More reasonable to have this attrib= ute in minutes rather than seconds, bigger default can also suggested > [TR] Changed to minutes I prefer seconds than minutes because I think granularity of minutes is rou= gh. If we are to leverage programmable and automated feature of DOTS, lifetime = in "seconds" is fine. Works for me. Ehud - Any specific reason for suggesting minutes ? -Tiru thank you, Kaname On 2017/02/16 23:00, Tirumaleswar Reddy (tireddy) wrote: Hi Ehud, Please see inline [TR2] From: Ehud Doron [mailto:EhudD@Radware.com] Sent: Thursday, February 16, 2017 6:43 PM To: Tirumaleswar Reddy (tireddy) ; 'dots' Cc: David Aviv Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 a= nd draft-reddy-dots-data-channel-03 . Tiru Hi Thanks for your response and clarifications. Please see inline (Followed after [Ehud] ) Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Tuesday, February 14, 2017 4:53 PM To: Ehud Doron >; 'dots' > Cc: David Aviv > Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 a= nd draft-reddy-dots-data-channel-03 . Hi Ehud, Thanks for the detailed review, Please see inline (I will respond to data c= hannel comments in a separate mail) From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron Sent: Wednesday, February 8, 2017 7:21 PM To: 'dots' > Cc: David Aviv > Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-0= 7 and draft-reddy-dots-data-channel-03 . Tiru and authors Hi Attached please find my comments and feedbacks to draft-reddy-dots-signal-c= hannel-07 and draft-reddy-dots-data-channel-03 . Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel = draft-reddy-dots-signal-channel-07 1. General comment: For all signals in the draft, need to add means t= o allow vendor specific attributes as part of all signals transactions [TR] Yes, will update draft. 2. General comment: Just for clarity, need to explicitly mention on e= ach figure when it is an example or the actual API [TR] Done. 3. Page 3 second paragraph : DOTS should not be limited to "enterpris= e network" only [TR] Agreed, fixed. 4. Page 4 chapter 4: The overall context of the "happy eyeballs" and = its relations (or coexistence) to CoAP is not clear. [TR] Happy eyeballs mechanism is used to reduce connection delay to setup (= D)TLS session with the DOTS server. Happy eyeballs mechanism is not related= to CoAP. 5. Page 7 chapter 5.2.1: The need for YANG model cannot be understood= from text. What are the needs for YANG models? What is the relation to the= JSONs in the other chapters in the draft [TR] YANG is a data modeling language used to model configuration and state= data; The configuration and state data defined using YANG can be represen= ted in JSON or CBOR or XML. Since CBOR is binary, JSON is used in the draft= but only for illustrative purpose. 6. Page 14 figure 5: The mitigation request attributes are right but = not enough. Need to add more telemetry info about the actual attack that it= is required to mitigate, need to consider attributes in draft-doron-dots-t= elemetry-00 as part of the discussion in the WG. [TR] Yes, I plan to update the draft with telemetry info based on outcome o= f draft-doron-dots-telemetry-00. 7. Page 15 Life time attribute: More reasonable to have this attribut= e in minutes rather than seconds, bigger default can also suggested [TR] Changed to minutes 8. Page 15 last paragraph: Not sure that target port or target protoc= ol can define a protected entity. IP, FQDN, URI are the only "stand alone" = attributes , port and protocol are companion attributes. See also figure 9 = . [TR] Good point, fixed. 9. Page 15 last paragraph: The mitigation request is not clear, to wh= ich identifier the text is related ? "policy ID" ? I think the best is ha= ve another attribute to define the priority of mitigation requests [TR] policy-id is specific to a DOTS client, DOTS server need not compare t= he policy-id of one customer with the policy-id of another customer. Policy= -ids are only compared b/w multiple mitigation requests from the same DOTS = client to determine the priority. DOTS signaling channel runs over UDP, and= packets may arrive out-of-order; this was also one of the reasons to intro= duce policy-id. [Ehud] Consider to update the text in page 15 with your explanations here, = mainly regarding the "per customer uniqueness of DOTS". [TR2] NEW: The relative order of two mitigation requests from a DOTS client is determi= ned by comparing their respective policy-id values. 10. Page 21 table: The return status are right but not enough. Need to ad= d more telemetry info about the actual mitigation going on (how much traffi= c was mitigated) and the attack that are mitigated, need to consider attrib= utes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. [TR] Same response as 6; for now will update the draft to convey the follow= ing telemetry info from the DOTS server : total dropped byte count, average= dropped bytes per second, total dropped packet count and average dropped p= ackets per second. The list is not complete, what kind of telemetry info is= required for L7 attacks (e.g. attack at TLS, partial HTTP request, garbage= request etc.) and how do we deal with new type of DDOS attacks (Do we keep= updating the spec as and when a new DDOS attack is discovered) ? [Ehud] Agreed with the bytes / packets count drop you proposed. For the Lay= er 7 telemetries and for DDoS attacks list , I think we should first get to= an agreement about the needs for this attributes and then figure out the b= est way to signal this information. Personally I don't believe we should up= date the spec for each attack, therefor we need to figure out an efficient = means to signal this information. [TR2] Agreed. 11. Page 15 : Need to find the way to bind the target-ips with target-por= t-ranges and target-protocols, meaning that the server needs to understand = the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on = so forth. [TR] Yes, it's possible; create different aliases for IP1 TCP port 80 and I= P 2 UDP port 53 using DOTS data channel and convey the aliases in DOTS sign= al channel. 12. Page 21 last paragraph: This is very strong point. [TR] Thanks. 13. Page 25 : Regarding attack status, same point about telemetry. [TR] Same response as above. 14. Page 25 chapter 5.4: I believe it can valuable to add a short high le= vel description about the proposed API flow, same as you did for 5.3 . [TR] 5.3 gives background how GET, POST, DELETE and PUT will be used, hence= did not see a need to add a high level description in Section 5.4. 15. Page 27: The necessity of policy_id here is not clear enough, are th= e "Signal Channel Session Configuration" define only "single" DOTS session = or the entire communication between Client and Server for several DOTS requ= est for mitigation? [TR] It's for a single DOTS session between DOTS client and server, a sing= le DOTS session can be used for several DOTS requests and responses. 16. Page 27: Not sure about the reason for "at least one of the attribute= s heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor = MUST be present." Also consider to change to "presented". [TR] what is the point in conveying a POST request without any configuratio= n parameters/attributes ? [Ehud] OK, understood. So I think you need to emphasize that in cases not a= ll attributes are defined, need to use default values. In page 26 you wrote= something about "need not be default". Consider to re-write. [TR2] NEW: The DOTS agents MUST use the negotiated values for message transmission parameters and default values for non-negotiated message transmission parameters. The signaling channel session configuration is applicable to a single DOTS signal channel session between the DOTS agents. -Tiru 17. Page 30 chapter 5.5: Need to specify the overall scenario, in reactio= n to which signal (or API transaction POST of Mitigation Request , unidirec= tional notification from Server as describes in page 23 in page 21 ?) the = redirection occurred ? [TR] Both, updated draft. -Tiru Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel dr= aft-reddy-dots-data-channel-03 1. General comment: For all signal in the draft, need to add means to= allow vendor specific attributes as part of all signals transactions 2. Page 5 second paragraph: Why it is required to configure the DOTS = signal channel session ? 3. Page 8 chapter 3.2.1 : Any reason for not including these identifi= ers in the DOTS signal channel draft ? 4. Page 9 figure 3 : Need to find the way to bind the target-ips with= target-port-ranges and target-protocols, meaning that the server needs to = understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53= and so on so forth. 5. Page 13 chapter 3.3 : Need to emphasize that filtering rules are r= elevant for both client server direct communication and through a DOTS gate= way. The chapter is a bit confusing. 6. Page 14 chapter 3.3 : I am missing the white-list installation, is= it by using the permit action ? 7. Page 15 figure 8: For DDoS it is highly valuable to have rate limi= t as an action. Consider adding such action (if already defined need to exp= lain where and how). 8. Page 15 figure 8: Need to consider adding priority to an ACL to su= pport cases when several filtering rules are conflicting. 9. Page 15 : The action field cannot be optional attribute. 10. Page 16 chapter 3.3.3: Need to add more telemetry info about the actu= al traffic that was blocked (bps, pps and so on), but as I believe this mig= ht be another issue... Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_E8355113905631478EFF04F5AA706E987052C944wtlexchp1sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In my opinion, units o= f seconds are preferable in a protocol, if only because they are the base S= .I. unit.

 

Any user interface (or= programming interface) can easily convert minutes to seconds if desired.

 

 

 

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron
Sent: Tuesday, February 28, 2017 9:57 AM
To: Tirumaleswar Reddy (tireddy); kaname nishizuka; 'dots'
Cc: David Aviv
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signa= l-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru, Kaname <= /o:p>

 

As this attribute is d= efined as the lifetime of the all mitigation request (i.e. the entire attac= k period), as per my knowledge this kind of period can typically be relativ= ely long (hours and more),  so that why minutes can be more comfortable to operate.

However if Kaname thin= ks seconds is better as it is more granular, this can be suggested here as = well.

 

Thanks, Ehud

 

From:= Tirumaleswar Reddy (tireddy) [mailto:tire= ddy@cisco.com]
Sent: Tuesday, February 28, 2017 11:14 AM
To: kaname nishizuka <kaname@nttv6.jp>; Ehud Doron <EhudD@R= adware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: RE: [Dots] Comments and feedbacks on draft-reddy-dots-signa= l-channel-07 and draft-reddy-dots-data-channel-03 .

 

From:= kaname nishizuka [mailto:kaname@nttv6.jp]
Sent: Friday, February 24, 2017 10:17 AM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; Ehud Doron <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radw= are.com>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signa= l-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru,

I'd like to add a comment on lifetime attribute in signal-channel

> 7.       Page 15 Life time attribute: Mo= re reasonable to have this attribute in minutes rather than seconds, bigger= default can also suggested
> [TR] Changed to minutes

I prefer seconds than minutes because I think granularity of minutes is rou= gh.
If we are to leverage programmable and automated feature of DOTS, lifetime = in "seconds" is fine.

Works for me.

Ehud – Any specific reason for suggesting minutes ?

-Tiru

 



thank you,
Kaname

On 2017/02/16 23:00, Tirumaleswar Reddy (tireddy) wr= ote:

Hi Ehud,

 

Please see inline [TR2= ]

 

From: Ehud Doron [mailto:EhudD@Radware.com]
Sent: Thursday, February 16, 2017 6:43 PM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radw= are.com>
Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 .

 

Tiru Hi

 

Thanks for your respon= se and clarifications.

Please see inline (Fol= lowed after [Ehud] )

 

Thanks,

 

Ehud Doron |  Senior Architect, Radware CTO office | M:= +972-54-7575503 | T:&nb= sp;+972-72-3917120

 

 

 

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Tuesday, February 14, 2017 4:53 PM
To: Ehud Doron <EhudD@Radwar= e.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radw= are.com>
Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 .

 

Hi Ehud,

 

Thanks for the detaile= d review, Please see inline (I will respond to data channel comments in a s= eparate mail)

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <dots@ietf.org>= ;
Cc: David Aviv <DavidA@Radw= are.com>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-ch= annel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru and authors Hi

 

Attached please find m= y comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-re= ddy-dots-data-channel-03 .

 

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy= -dots-signal-channel-07

 

1.     &= nbsp; General comment: For all signals in the draft, need= to add means to allow vendor specific attributes as part of all signals tr= ansactions

 

[TR] Yes, will update draft.

 

2.     &= nbsp; General comment: Just for clarity, need to explicit= ly mention on each figure when it is an example or the actual API

 

[TR] Done.

 

3.     &= nbsp; Page 3 second paragraph : DOTS should not be limite= d to “enterprise network” only

 

[TR] Agreed, fixed.

 

4.     &= nbsp; Page 4 chapter 4: The overall context of the “= ;happy eyeballs” and its relations (or coexistence) to CoAP is not cl= ear.  

 

[TR] Happy eyeballs me= chanism is used to reduce connection delay to setup (D)TLS session with the= DOTS server. Happy eyeballs mechanism is not related to CoAP.<= /o:p>

 

5.     &= nbsp; Page 7 chapter 5.2.1: The need for YANG model canno= t be understood from text. What are the needs for YANG models? What is the = relation to the JSONs in the other chapters in the draft

 

[TR] YANG is a data mo= deling language used to model configuration and state data;  The confi= guration and state data defined using YANG can be represented in JSON or CB= OR or XML. Since CBOR is binary, JSON is used in the draft but only for illustrative purpose.

 

6.     &= nbsp; Page 14 figure 5: The mitigation request attributes= are right but not enough. Need to add more telemetry info about the actual= attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

[TR] Yes, I plan to up= date the draft with telemetry info based on outcome of draft-doron-dots-tel= emetry-00.

 

7.     &= nbsp; Page 15 Life time attribute: More reasonable to have this attribute in minutes rather tha= n seconds, bigger default can also suggested

 

[TR] Changed to minute= s

 

8.     &= nbsp; Page 15 last paragraph: Not sure that target port or target protocol can define a protect= ed entity. IP, FQDN, URI are the only “stand alone” attributes = , port and protocol are companion attributes. See also figure 9 .

 

[TR] Good point, fixed= .

 

9.     &= nbsp; Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is relate= d ?   “policy ID” ? I think the best is have another = attribute to define the priority of mitigation requests

[TR] policy-id is spec= ific to a DOTS client, DOTS server need not compare the policy-id of one cu= stomer with the policy-id of another customer. Policy-ids are only compared= b/w multiple mitigation requests from the same DOTS client to determine the priority. DOTS signaling channel run= s over UDP, and packets may arrive out-of-order; this was also one of the r= easons to introduce policy-id.

[Ehud] Consider to upd= ate the text in page 15 with your explanations here, mainly regarding the &= #8220;per customer uniqueness of DOTS”.

 

[TR2] NEW:=

The relative order of = two mitigation requests from a DOTS client is determined by comparing their= respective policy-id values.

 

10.   Page 21 table: The return status are right but not = enough. Need to add more telemetry info about the actual mitigation going o= n (how much traffic was mitigated) and the attack that are mitigated, need = to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

[TR] Same response as 6; for now will update the draft to convey the following telemetry info fro= m the DOTS server : total dropped byte count, average dropped byt= es per second, total dropped packet count and average dropped packets per s= econd. The list is not complete, what kind of telemetry info is required fo= r L7 attacks (e.g. attack at TLS, partial HTTP request, garbage request etc.) and how do we deal with new ty= pe of DDOS attacks (Do we keep updating the spec as and when a new DDOS att= ack is discovered) ?

[Ehud] Agreed with the= bytes / packets count drop you proposed. For the Layer 7 telemetries and f= or DDoS attacks list , I think we should first get to an agreement about th= e needs for this attributes and then figure out the best way to signal this information. Personally I don’= ;t believe we should update the spec for each attack, therefor we need to f= igure out an efficient means to signal this information.  =

 

[TR2] Agreed.

 

11.   Page 15 : Need to find the way to bind the target-i= ps with target-port-ranges and target-protocols, meani= ng that the server needs to understand the exact scope of attack, e.g. IP1 = TCP port 80, IP2 UDP port 53 and so on so forth.

 

[TR] Yes, it’s p= ossible; create different aliases for IP1 TCP port 80 and IP 2 UDP port 53 = using DOTS data channel and convey the aliases in DOTS signal channel.

 

12.   Page 21 last paragraph: This is very strong point.<= o:p>

 

[TR] Thanks.

 

13.   Page 25 : Regarding attack status, same point about= telemetry.

 

[TR] Same response as above.

 

14.   Page 25 chapter 5.4: I believe it can valuable to a= dd a short high level description about the proposed API flow, same as you = did for 5.3 .

 

[TR] 5.3 gives backgro= und how GET, POST, DELETE and PUT will be used, hence did not see a need to= add a high level description in Section 5.4.

 

 

15.   Page 27:  The necessity of policy_id here is n= ot clear enough, are the “Signal Channel Session Configuration”= define only “single” DOTS session or the entire communication = between Client and Server for several DOTS request for mitigation?

 

[TR]  It’s = for a single DOTS session between DOTS client and server, a single DOTS ses= sion can be used for several DOTS requests and responses.=

 

16.   Page 27: Not sure about the reason for “at le= ast one of the attributes heartbeat-interval or max-retransmit or ack-timeo= ut or ack-random-factor MUST be present.” Also consider to change to = “presented”.

 

[TR] what is the point in conveying a POST =
request without any configuration parameters/attributes ?=

[Ehud] OK, understood. So I think you need =
to emphasize that in cases not all attributes are defined, need to use defa=
ult values. In page 26 you wrote something about “need not be default=
”. Consider to re-write. 
 
[TR2] NEW:
The DOTS agents MUST use the negotiated values for message transmissio=
n
parameters and default values for non-negotiated message transmission<=
o:p>
parameters.  The signaling channel session configuration is<=
/o:p>
applicable to a single DOTS signal channel session between the DOTS
agents. 

 

-Tiru

 

17.   Page 30 chapter 5.5: Need to specify the overall sc= enario, in reaction to which signal (or API transaction POST of Mitigation = Request , unidirectional notification from Server as describes in page 23 i= n page 21 ?) the  redirection occurred ?

 

[TR] Both, updated dra= ft.

 

-Tiru

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-d= ots-data-channel-03

 

1.     &= nbsp; General comment: For all signal in the draft, need = to add means to allow vendor specific attributes as part of all signals tra= nsactions

 

2.     &= nbsp; Page 5 second paragraph: Why it is required to conf= igure the DOTS signal channel session ?  

 

3.     &= nbsp; Page 8 chapter 3.2.1 : Any reason for not including= these identifiers in the DOTS signal channel draft ?

 

4.     &= nbsp; Page 9 figure 3 : Need to find the way to bind the = target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e= .g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

5.     &= nbsp; Page 13 chapter 3.3 : Need to emphasize that filter= ing rules are relevant for both client server direct communication and thro= ugh a DOTS gateway. The chapter is a bit confusing.

 

6.     &= nbsp; Page 14 chapter 3.3 : I am missing the white-list i= nstallation, is it by using the permit action ?

 

7.     &= nbsp; Page 15 figure 8: For DDoS it is highly valuable to= have rate limit as an action. Consider adding such action (if already defi= ned need to explain where and how).

 

8.     &= nbsp; Page 15 figure 8: Need to consider adding priority = to an ACL to support cases when several filtering rules are conflicting.

 

9.     &= nbsp; Page 15 : The action field cannot be optional attri= bute.

 

10.   Page 16 chapter 3.3.3: Need to add more telemetry i= nfo about the actual traffic that was blocked (bps, pps and so on), but as = I believe this might be another issue…

 

 

 

Thanks,

 <= /o:p>

Ehud Doron |  Senior Architect, Radware CTO office | M:= +972-54-7575503 | T:&nb= sp;+972-72-3917120

 

 

 

 

=  

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

 

--_000_E8355113905631478EFF04F5AA706E987052C944wtlexchp1sandvi_-- From nobody Tue Feb 28 18:05:21 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A1C129434 for ; Tue, 28 Feb 2017 18:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ck7jH-zce9kA for ; Tue, 28 Feb 2017 18:05:17 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81F7126DFB for ; Tue, 28 Feb 2017 18:05:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56927; q=dns/txt; s=iport; t=1488333916; x=1489543516; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bSODH1SnsraGRjm6baQb1w0HjKz8bQs09OPMbURuYZw=; b=bxgogRuQXc8A9QmrqR2xYAruhzp6ti6J6IjKM6YyumrM/PWp7+TQI1Ap 75fuIVplfUy7G02azjg4hdd0DYm/EfrRWfmdEBTbm8cj0ZKbz/M5YKNnR 8yPIGQ0x5eb7ULlwS6WutMc/aqv06trRy45/GzPHE9WLEDeyabyqZDayr s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQAvK7ZY/4gNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5iYYEJB41ckWSVNYIKAx8BCoV4AoIuPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?wAQEBAwEBARgTQQQHBQsCAQgOAwQBASEBAgQHJwsUCQgCBAENBQgRiVYIDrQEK?= =?us-ascii?q?4p7AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGTINmgQmEMAEGAQEFHQceCgKFLQW?= =?us-ascii?q?VcYYyAYoZiAmCBIUgiX2IPIp1AR84gQFUFT6ETAMdGYFIdYczAQ4XgQqBDQEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.35,222,1484006400"; d="scan'208,217";a="218005874" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Mar 2017 02:05:14 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2125EZp001992 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Mar 2017 02:05:14 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.1210.3; Tue, 28 Feb 2017 20:05:13 -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.1210.000; Tue, 28 Feb 2017 20:05:13 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Dave Dolson , Ehud Doron , "kaname nishizuka" , "'dots'" Thread-Topic: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . Thread-Index: AdKCER/slEaaT/pbTQCa8ffUgEh/YgEvK4mgADZ1NNAALTMmUAGLtzkAAMXdMkAAGKBCgAAJaAeAAAFQmbA= Date: Wed, 1 Mar 2017 02:05:13 +0000 Message-ID: <80cd41e5b7434b5ab145ff8621fa182a@XCH-RCD-017.cisco.com> References: <331a77a5ec074db69cf2bc2715a7645e@XCH-RCD-017.cisco.com> <3bab57f083c346cfb491c29c7ff369dd@XCH-RCD-017.cisco.com> <7dcc6611-18f5-7d89-2386-8e5ee22c94b6@nttv6.jp> <5cbbc9aa610c43c28ae7c501ef8da35b@XCH-RCD-017.cisco.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.65.92.170] Content-Type: multipart/alternative; boundary="_000_80cd41e5b7434b5ab145ff8621fa182aXCHRCD017ciscocom_" MIME-Version: 1.0 Archived-At: Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 02:05:19 -0000 --_000_80cd41e5b7434b5ab145ff8621fa182aXCHRCD017ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Wednesday, March 1, 2017 12:57 AM To: Ehud Doron ; Tirumaleswar Reddy (tireddy) ; kaname nishizuka ; 'dots' Cc: David Aviv Subject: RE: [Dots] Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 . In my opinion, units of seconds are preferable in a protocol, if only becau= se they are the base S.I. unit. Agreed, fixed in my local copy. -Tiru Any user interface (or programming interface) can easily convert minutes to= seconds if desired. From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron Sent: Tuesday, February 28, 2017 9:57 AM To: Tirumaleswar Reddy (tireddy); kaname nishizuka; 'dots' Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 . Hi Tiru, Kaname As this attribute is defined as the lifetime of the all mitigation request = (i.e. the entire attack period), as per my knowledge this kind of period ca= n typically be relatively long (hours and more), so that why minutes can b= e more comfortable to operate. However if Kaname thinks seconds is better as it is more granular, this can= be suggested here as well. Thanks, Ehud From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Tuesday, February 28, 2017 11:14 AM To: kaname nishizuka >; Ehud Doron = >; 'dots' > Cc: David Aviv > Subject: RE: [Dots] Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 . From: kaname nishizuka [mailto:kaname@nttv6.jp] Sent: Friday, February 24, 2017 10:17 AM To: Tirumaleswar Reddy (tireddy) >; Ehud Doron >; 'dots' > Cc: David Aviv > Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 . Hi Tiru, I'd like to add a comment on lifetime attribute in signal-channel > 7. Page 15 Life time attribute: More reasonable to have this attrib= ute in minutes rather than seconds, bigger default can also suggested > [TR] Changed to minutes I prefer seconds than minutes because I think granularity of minutes is rou= gh. If we are to leverage programmable and automated feature of DOTS, lifetime = in "seconds" is fine. Works for me. Ehud - Any specific reason for suggesting minutes ? -Tiru thank you, Kaname On 2017/02/16 23:00, Tirumaleswar Reddy (tireddy) wrote: Hi Ehud, Please see inline [TR2] From: Ehud Doron [mailto:EhudD@Radware.com] Sent: Thursday, February 16, 2017 6:43 PM To: Tirumaleswar Reddy (tireddy) ; 'dots' Cc: David Aviv Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 a= nd draft-reddy-dots-data-channel-03 . Tiru Hi Thanks for your response and clarifications. Please see inline (Followed after [Ehud] ) Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Tuesday, February 14, 2017 4:53 PM To: Ehud Doron >; 'dots' > Cc: David Aviv > Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 a= nd draft-reddy-dots-data-channel-03 . Hi Ehud, Thanks for the detailed review, Please see inline (I will respond to data c= hannel comments in a separate mail) From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron Sent: Wednesday, February 8, 2017 7:21 PM To: 'dots' > Cc: David Aviv > Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-0= 7 and draft-reddy-dots-data-channel-03 . Tiru and authors Hi Attached please find my comments and feedbacks to draft-reddy-dots-signal-c= hannel-07 and draft-reddy-dots-data-channel-03 . Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel = draft-reddy-dots-signal-channel-07 1. General comment: For all signals in the draft, need to add means t= o allow vendor specific attributes as part of all signals transactions [TR] Yes, will update draft. 2. General comment: Just for clarity, need to explicitly mention on e= ach figure when it is an example or the actual API [TR] Done. 3. Page 3 second paragraph : DOTS should not be limited to "enterpris= e network" only [TR] Agreed, fixed. 4. Page 4 chapter 4: The overall context of the "happy eyeballs" and = its relations (or coexistence) to CoAP is not clear. [TR] Happy eyeballs mechanism is used to reduce connection delay to setup (= D)TLS session with the DOTS server. Happy eyeballs mechanism is not related= to CoAP. 5. Page 7 chapter 5.2.1: The need for YANG model cannot be understood= from text. What are the needs for YANG models? What is the relation to the= JSONs in the other chapters in the draft [TR] YANG is a data modeling language used to model configuration and state= data; The configuration and state data defined using YANG can be represen= ted in JSON or CBOR or XML. Since CBOR is binary, JSON is used in the draft= but only for illustrative purpose. 6. Page 14 figure 5: The mitigation request attributes are right but = not enough. Need to add more telemetry info about the actual attack that it= is required to mitigate, need to consider attributes in draft-doron-dots-t= elemetry-00 as part of the discussion in the WG. [TR] Yes, I plan to update the draft with telemetry info based on outcome o= f draft-doron-dots-telemetry-00. 7. Page 15 Life time attribute: More reasonable to have this attribut= e in minutes rather than seconds, bigger default can also suggested [TR] Changed to minutes 8. Page 15 last paragraph: Not sure that target port or target protoc= ol can define a protected entity. IP, FQDN, URI are the only "stand alone" = attributes , port and protocol are companion attributes. See also figure 9 = . [TR] Good point, fixed. 9. Page 15 last paragraph: The mitigation request is not clear, to wh= ich identifier the text is related ? "policy ID" ? I think the best is ha= ve another attribute to define the priority of mitigation requests [TR] policy-id is specific to a DOTS client, DOTS server need not compare t= he policy-id of one customer with the policy-id of another customer. Policy= -ids are only compared b/w multiple mitigation requests from the same DOTS = client to determine the priority. DOTS signaling channel runs over UDP, and= packets may arrive out-of-order; this was also one of the reasons to intro= duce policy-id. [Ehud] Consider to update the text in page 15 with your explanations here, = mainly regarding the "per customer uniqueness of DOTS". [TR2] NEW: The relative order of two mitigation requests from a DOTS client is determi= ned by comparing their respective policy-id values. 10. Page 21 table: The return status are right but not enough. Need to ad= d more telemetry info about the actual mitigation going on (how much traffi= c was mitigated) and the attack that are mitigated, need to consider attrib= utes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. [TR] Same response as 6; for now will update the draft to convey the follow= ing telemetry info from the DOTS server : total dropped byte count, average= dropped bytes per second, total dropped packet count and average dropped p= ackets per second. The list is not complete, what kind of telemetry info is= required for L7 attacks (e.g. attack at TLS, partial HTTP request, garbage= request etc.) and how do we deal with new type of DDOS attacks (Do we keep= updating the spec as and when a new DDOS attack is discovered) ? [Ehud] Agreed with the bytes / packets count drop you proposed. For the Lay= er 7 telemetries and for DDoS attacks list , I think we should first get to= an agreement about the needs for this attributes and then figure out the b= est way to signal this information. Personally I don't believe we should up= date the spec for each attack, therefor we need to figure out an efficient = means to signal this information. [TR2] Agreed. 11. Page 15 : Need to find the way to bind the target-ips with target-por= t-ranges and target-protocols, meaning that the server needs to understand = the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on = so forth. [TR] Yes, it's possible; create different aliases for IP1 TCP port 80 and I= P 2 UDP port 53 using DOTS data channel and convey the aliases in DOTS sign= al channel. 12. Page 21 last paragraph: This is very strong point. [TR] Thanks. 13. Page 25 : Regarding attack status, same point about telemetry. [TR] Same response as above. 14. Page 25 chapter 5.4: I believe it can valuable to add a short high le= vel description about the proposed API flow, same as you did for 5.3 . [TR] 5.3 gives background how GET, POST, DELETE and PUT will be used, hence= did not see a need to add a high level description in Section 5.4. 15. Page 27: The necessity of policy_id here is not clear enough, are th= e "Signal Channel Session Configuration" define only "single" DOTS session = or the entire communication between Client and Server for several DOTS requ= est for mitigation? [TR] It's for a single DOTS session between DOTS client and server, a sing= le DOTS session can be used for several DOTS requests and responses. 16. Page 27: Not sure about the reason for "at least one of the attribute= s heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor = MUST be present." Also consider to change to "presented". [TR] what is the point in conveying a POST request without any configuratio= n parameters/attributes ? [Ehud] OK, understood. So I think you need to emphasize that in cases not a= ll attributes are defined, need to use default values. In page 26 you wrote= something about "need not be default". Consider to re-write. [TR2] NEW: The DOTS agents MUST use the negotiated values for message transmission parameters and default values for non-negotiated message transmission parameters. The signaling channel session configuration is applicable to a single DOTS signal channel session between the DOTS agents. -Tiru 17. Page 30 chapter 5.5: Need to specify the overall scenario, in reactio= n to which signal (or API transaction POST of Mitigation Request , unidirec= tional notification from Server as describes in page 23 in page 21 ?) the = redirection occurred ? [TR] Both, updated draft. -Tiru Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel dr= aft-reddy-dots-data-channel-03 1. General comment: For all signal in the draft, need to add means to= allow vendor specific attributes as part of all signals transactions 2. Page 5 second paragraph: Why it is required to configure the DOTS = signal channel session ? 3. Page 8 chapter 3.2.1 : Any reason for not including these identifi= ers in the DOTS signal channel draft ? 4. Page 9 figure 3 : Need to find the way to bind the target-ips with= target-port-ranges and target-protocols, meaning that the server needs to = understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53= and so on so forth. 5. Page 13 chapter 3.3 : Need to emphasize that filtering rules are r= elevant for both client server direct communication and through a DOTS gate= way. The chapter is a bit confusing. 6. Page 14 chapter 3.3 : I am missing the white-list installation, is= it by using the permit action ? 7. Page 15 figure 8: For DDoS it is highly valuable to have rate limi= t as an action. Consider adding such action (if already defined need to exp= lain where and how). 8. Page 15 figure 8: Need to consider adding priority to an ACL to su= pport cases when several filtering rules are conflicting. 9. Page 15 : The action field cannot be optional attribute. 10. Page 16 chapter 3.3.3: Need to add more telemetry info about the actu= al traffic that was blocked (bps, pps and so on), but as I believe this mig= ht be another issue... Thanks, Ehud Doron | Senior Architect, Radware CTO office | M: +972-54-7575503 | T= : +972-72-3917120 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_80cd41e5b7434b5ab145ff8621fa182aXCHRCD017ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From:= Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Wednesday, March 1, 2017 12:57 AM
To: Ehud Doron <EhudD@Radware.com>; Tirumaleswar Reddy (tiredd= y) <tireddy@cisco.com>; kaname nishizuka <kaname@nttv6.jp>; 'do= ts' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: RE: [Dots] Comments and feedbacks on draft-reddy-dots-signa= l-channel-07 and draft-reddy-dots-data-channel-03 .

 

In my opinion, units o= f seconds are preferable in a protocol, if only because they are the base S= .I. unit.

 

Agreed, fixed in my= local copy.

 

-Tiru

 

Any user interface (or= programming interface) can easily convert minutes to seconds if desired.

 

 

 

 

From: Dots [mailto:dots-bounces@ietf.o= rg] On Behalf Of Ehud Doron
Sent: Tuesday, February 28, 2017 9:57 AM
To: Tirumaleswar Reddy (tireddy); kaname nishizuka; 'dots'
Cc: David Aviv
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signa= l-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru, Kaname <= /o:p>

 

As this attribute is d= efined as the lifetime of the all mitigation request (i.e. the entire attac= k period), as per my knowledge this kind of period can typically be relativ= ely long (hours and more),  so that why minutes can be more comfortable to operate.

However if Kaname thin= ks seconds is better as it is more granular, this can be suggested here as = well.

 

Thanks, Ehud

 

From:= Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Tuesday, February 28, 2017 11:14 AM
To: kaname nishizuka <kaname@n= ttv6.jp>; Ehud Doron <EhudD@= Radware.com>; 'dots' <dots@ietf.= org>
Cc: David Aviv <DavidA@Radw= are.com>
Subject: RE: [Dots] Comments and feedbacks on draft-reddy-dots-signa= l-channel-07 and draft-reddy-dots-data-channel-03 .

 

From:= kaname nishizuka [mailto:kaname@nttv6.jp]
Sent: Friday, February 24, 2017 10:17 AM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; Ehud Doron <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radw= are.com>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signa= l-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru,

I'd like to add a comment on lifetime attribute in signal-channel

> 7.       Page 15 Life time attribute: Mo= re reasonable to have this attribute in minutes rather than seconds, bigger= default can also suggested
> [TR] Changed to minutes

I prefer seconds than minutes because I think granularity of minutes is rou= gh.
If we are to leverage programmable and automated feature of DOTS, lifetime = in "seconds" is fine.

Works for me.

Ehud – Any specific reason for suggesting minutes ?

-Tiru

 



thank you,
Kaname

On 2017/02/16 23:00, Tirumaleswar Reddy (tireddy) wr= ote:

Hi Ehud,

 

Please see inline [TR2= ]

 

From: Ehud Doron [mailto:EhudD@Radware.com]
Sent: Thursday, February 16, 2017 6:43 PM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radw= are.com>
Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 .

 

Tiru Hi

 

Thanks for your respon= se and clarifications.

Please see inline (Fol= lowed after [Ehud] )

 

Thanks,

 

Ehud Doron <= span dir=3D"RTL">|  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Tuesday, February 14, 2017 4:53 PM
To: Ehud Doron <EhudD@Radwar= e.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radw= are.com>
Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-chann= el-07 and draft-reddy-dots-data-channel-03 .

 

Hi Ehud,

 

Thanks for the detaile= d review, Please see inline (I will respond to data channel comments in a s= eparate mail)

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <dots@ietf.org>= ;
Cc: David Aviv <DavidA@Radw= are.com>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-ch= annel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru and authors Hi

 

Attached please find m= y comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-re= ddy-dots-data-channel-03 .

 

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy= -dots-signal-channel-07

 

1.     &= nbsp; General comment: For all signals in the draft, need= to add means to allow vendor specific attributes as part of all signals tr= ansactions

 

[TR] Yes, will update draft.

 

2.     &= nbsp; General comment: Just for clarity, need to explicit= ly mention on each figure when it is an example or the actual API

 

[TR] Done.

 

3.     &= nbsp; Page 3 second paragraph : DOTS should not be limite= d to “enterprise network” only

 

[TR] Agreed, fixed.

 

4.     &= nbsp; Page 4 chapter 4: The overall context of the “= ;happy eyeballs” and its relations (or coexistence) to CoAP is not cl= ear.  

 

[TR] Happy eyeballs me= chanism is used to reduce connection delay to setup (D)TLS session with the= DOTS server. Happy eyeballs mechanism is not related to CoAP.<= /o:p>

 

5.     &= nbsp; Page 7 chapter 5.2.1: The need for YANG model canno= t be understood from text. What are the needs for YANG models? What is the = relation to the JSONs in the other chapters in the draft

 

[TR] YANG is a data mo= deling language used to model configuration and state data;  The confi= guration and state data defined using YANG can be represented in JSON or CB= OR or XML. Since CBOR is binary, JSON is used in the draft but only for illustrative purpose.

 

6.     &= nbsp; Page 14 figure 5: The mitigation request attributes= are right but not enough. Need to add more telemetry info about the actual= attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

[TR] Yes, I plan to up= date the draft with telemetry info based on outcome of draft-doron-dots-tel= emetry-00.

 

7.     &= nbsp; Page 15 Life time attribute: More reasonable to have this attribute in minutes rather tha= n seconds, bigger default can also suggested

 

[TR] Changed to minute= s

 

8.     &= nbsp; Page 15 last paragraph: Not sure that target port or target protocol can define a protect= ed entity. IP, FQDN, URI are the only “stand alone” attributes = , port and protocol are companion attributes. See also figure 9 .

 

[TR] Good point, fixed= .

 

9.     &= nbsp; Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is relate= d ?   “policy ID” ? I think the best is have another = attribute to define the priority of mitigation requests

[TR] policy-id is spec= ific to a DOTS client, DOTS server need not compare the policy-id of one cu= stomer with the policy-id of another customer. Policy-ids are only compared= b/w multiple mitigation requests from the same DOTS client to determine the priority. DOTS signaling channel run= s over UDP, and packets may arrive out-of-order; this was also one of the r= easons to introduce policy-id.

[Ehud] Consider to upd= ate the text in page 15 with your explanations here, mainly regarding the &= #8220;per customer uniqueness of DOTS”.

 

[TR2] NEW:=

The relative order of = two mitigation requests from a DOTS client is determined by comparing their= respective policy-id values.

 

10.   Page 21 table: The return status are right but not = enough. Need to add more telemetry info about the actual mitigation going o= n (how much traffic was mitigated) and the attack that are mitigated, need = to consider attributes in draft-doron-dots-telemetry-00 as part = of the discussion in the WG.

 

[TR] Same response as 6; for now will update the draft to convey the following telemetry info fro= m the DOTS server : total dropped byte count, average dropped byt= es per second, total dropped packet count and average dropped packets per s= econd. The list is not complete, what kind of telemetry info is required fo= r L7 attacks (e.g. attack at TLS, partial HTTP request, garbage request etc.) and how do we deal with new ty= pe of DDOS attacks (Do we keep updating the spec as and when a new DDOS att= ack is discovered) ?

[Ehud] Agreed with the= bytes / packets count drop you proposed. For the Layer 7 telemetries and f= or DDoS attacks list , I think we should first get to an agreement about th= e needs for this attributes and then figure out the best way to signal this information. Personally I don’= ;t believe we should update the spec for each attack, therefor we need to f= igure out an efficient means to signal this information.  =

 

[TR2] Agreed.

 

11.   Page 15 : Need to find the way to bind the target-i= ps with target-port-ranges and target-protocols, meani= ng that the server needs to understand the exact scope of attack, e.g. IP1 = TCP port 80, IP2 UDP port 53 and so on so forth.

 

[TR] Yes, it’s p= ossible; create different aliases for IP1 TCP port 80 and IP 2 UDP port 53 = using DOTS data channel and convey the aliases in DOTS signal channel.

 

12.   Page 21 last paragraph: This is very strong point.<= o:p>

 

[TR] Thanks.

 

13.   Page 25 : Regarding attack status, same point about= telemetry.

 

[TR] Same response as above.

 

14.   Page 25 chapter 5.4: I believe it can valuable to a= dd a short high level description about the proposed API flow, same as you = did for 5.3 .

 

[TR] 5.3 gives backgro= und how GET, POST, DELETE and PUT will be used, hence did not see a need to= add a high level description in Section 5.4.

 

 

15.   Page 27:  The necessity of policy_id here is n= ot clear enough, are the “Signal Channel Session Configuration”= define only “single” DOTS session or the entire communication = between Client and Server for several DOTS request for mitigation?

 

[TR]  It’s = for a single DOTS session between DOTS client and server, a single DOTS ses= sion can be used for several DOTS requests and responses.=

 

16.   Page 27: Not sure about the reason for “at le= ast one of the attributes heartbeat-interval or max-retransmit or ack-timeo= ut or ack-random-factor MUST be present.” Also consider to change to = “presented”.

 

[TR] what is the point in conveying a POST request with=
out any configuration parameters/attributes ?
[Ehud] OK, understood. So I think you need to emphasize=
 that in cases not all attributes are defined, need to use default values. =
In page 26 you wrote something about “need not be default”. Con=
sider to re-write. 
 
[TR2] NEW:
The DOTS agents MUST use the negotiated values for message transmissio=
n
parameters and default values for non-negotiated message transmission<=
o:p>
parameters.  The signaling channel session configuration is<=
/o:p>
applicable to a single DOTS signal channel session between the DOTS
agents. 

 

-Tiru

 

17.   Page 30 chapter 5.5: Need to specify the overall sc= enario, in reaction to which signal (or API transaction POST of Mitigation = Request , unidirectional notification from Server as describes in page 23 i= n page 21 ?) the  redirection occurred ?

 

[TR] Both, updated dra= ft.

 

-Tiru

 

Distributed Deni= al-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-d= ots-data-channel-03

 

1.     &= nbsp; General comment: For all signal in the draft, need = to add means to allow vendor specific attributes as part of all signals tra= nsactions

 

2.     &= nbsp; Page 5 second paragraph: Why it is required to conf= igure the DOTS signal channel session ?  

 

3.     &= nbsp; Page 8 chapter 3.2.1 : Any reason for not including= these identifiers in the DOTS signal channel draft ?

 

4.     &= nbsp; Page 9 figure 3 : Need to find the way to bind the = target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e= .g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

5.     &= nbsp; Page 13 chapter 3.3 : Need to emphasize that filter= ing rules are relevant for both client server direct communication and thro= ugh a DOTS gateway. The chapter is a bit confusing.

 

6.     &= nbsp; Page 14 chapter 3.3 : I am missing the white-list i= nstallation, is it by using the permit action ?

 

7.     &= nbsp; Page 15 figure 8: For DDoS it is highly valuable to= have rate limit as an action. Consider adding such action (if already defi= ned need to explain where and how).

 

8.     &= nbsp; Page 15 figure 8: Need to consider adding priority = to an ACL to support cases when several filtering rules are conflicting.

 

9.     &= nbsp; Page 15 : The action field cannot be optional attri= bute.

 

10.   Page 16 chapter 3.3.3: Need to add more telemetry i= nfo about the actual traffic that was blocked (bps, pps and so on), but as = I believe this might be another issue…

 

 

 

Thanks,

 

Ehud Doron <= span dir=3D"RTL">|  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

 

 = 

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

 

--_000_80cd41e5b7434b5ab145ff8621fa182aXCHRCD017ciscocom_-- From nobody Tue Feb 28 18:14:12 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD25612943C for ; Tue, 28 Feb 2017 18:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 BTNJ15pz7Ur8 for ; Tue, 28 Feb 2017 18:14:07 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id 6A118129434 for ; Tue, 28 Feb 2017 18:14:07 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 7B9EA25F69B; Wed, 1 Mar 2017 11:14:06 +0900 (JST) Received: from DHCP-119.nttv6.jp (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 9791B759048; Wed, 1 Mar 2017 11:14:05 +0900 (JST) To: "Tirumaleswar Reddy (tireddy)" , Dave Dolson , Ehud Doron , 'dots' References: <331a77a5ec074db69cf2bc2715a7645e@XCH-RCD-017.cisco.com> <3bab57f083c346cfb491c29c7ff369dd@XCH-RCD-017.cisco.com> <7dcc6611-18f5-7d89-2386-8e5ee22c94b6@nttv6.jp> <5cbbc9aa610c43c28ae7c501ef8da35b@XCH-RCD-017.cisco.com> <80cd41e5b7434b5ab145ff8621fa182a@XCH-RCD-017.cisco.com> From: kaname nishizuka Message-ID: <4e22f356-6109-1bd5-e565-75ac4f78ea37@nttv6.jp> Date: Wed, 1 Mar 2017 11:14:06 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <80cd41e5b7434b5ab145ff8621fa182a@XCH-RCD-017.cisco.com> Content-Type: multipart/alternative; boundary="------------BA1A090BC07377B9E56668FA" Archived-At: Cc: David Aviv Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 02:14:11 -0000 This is a multi-part message in MIME format. --------------BA1A090BC07377B9E56668FA Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 2017/03/01 11:05, Tirumaleswar Reddy (tireddy) wrote: > > *From:*Dave Dolson [mailto:ddolson@sandvine.com] > *Sent:* Wednesday, March 1, 2017 12:57 AM > *To:* Ehud Doron ; Tirumaleswar Reddy (tireddy) ; kaname nishizuka ; 'dots' > *Cc:* David Aviv > *Subject:* RE: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > In my opinion, units of seconds are preferable in a protocol, if only because they are the base S.I. unit. > > Agreed, fixed in my local copy. > Yes. I agree. thank you, Kaname > -Tiru > > Any user interface (or programming interface) can easily convert minutes to seconds if desired. > > *From:*Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Ehud Doron > *Sent:* Tuesday, February 28, 2017 9:57 AM > *To:* Tirumaleswar Reddy (tireddy); kaname nishizuka; 'dots' > *Cc:* David Aviv > *Subject:* Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Hi Tiru, Kaname > > As this attribute is defined as the lifetime of the all mitigation request (i.e. the entire attack period), as per my knowledge this kind of period can typically be relatively long (hours and more), so that why minutes can be more comfortable to operate. > > However if Kaname thinks seconds is better as it is more granular, this can be suggested here as well. > > Thanks, Ehud > > *From:*Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > *Sent:* Tuesday, February 28, 2017 11:14 AM > *To:* kaname nishizuka >; Ehud Doron >; 'dots' > > *Cc:* David Aviv > > *Subject:* RE: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > *From:*kaname nishizuka [mailto:kaname@nttv6.jp] > *Sent:* Friday, February 24, 2017 10:17 AM > *To:* Tirumaleswar Reddy (tireddy) >; Ehud Doron >; 'dots' > > *Cc:* David Aviv > > *Subject:* Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Hi Tiru, > > I'd like to add a comment on lifetime attribute in signal-channel > > > 7. Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested > > [TR] Changed to minutes > > I prefer seconds than minutes because I think granularity of minutes is rough. > If we are to leverage programmable and automated feature of DOTS, lifetime in "seconds" is fine. > > Works for me. > > Ehud – Any specific reason for suggesting minutes ? > > -Tiru > > > > thank you, > Kaname > > On 2017/02/16 23:00, Tirumaleswar Reddy (tireddy) wrote: > > Hi Ehud, > > Please see inline [TR2] > > *From:* Ehud Doron [mailto:EhudD@Radware.com] > *Sent:* Thursday, February 16, 2017 6:43 PM > *To:* Tirumaleswar Reddy (tireddy) ; 'dots' > *Cc:* David Aviv > *Subject:* RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Tiru Hi > > Thanks for your response and clarifications. > > Please see inline (Followed after [Ehud] ) > > Thanks, > > *Ehud Doron *| Senior Architect, *Radware* CTO office | *M:*+972-54-7575503 | *T:* +972-72-3917120 > > *From:* Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > *Sent:* Tuesday, February 14, 2017 4:53 PM > *To:* Ehud Doron >; 'dots' > > *Cc:* David Aviv > > *Subject:* RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Hi Ehud, > > Thanks for the detailed review, Please see inline (I will respond to data channel comments in a separate mail) > > *From:* Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Ehud Doron > *Sent:* Wednesday, February 8, 2017 7:21 PM > *To:* 'dots' > > *Cc:* David Aviv > > *Subject:* [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > Tiru and authors Hi > > Attached please find my comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 . > > *_Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel draft-reddy-dots-signal-channel-07_* > > 1.General comment: For all signals in the draft, need to add means to allow vendor specific attributes as part of all signals transactions > > [TR] Yes, will update draft. > > 2.General comment: Just for clarity, need to explicitly mention on each figure when it is an example or the actual API > > [TR] Done. > > 3.Page 3 second paragraph : DOTS should not be limited to “enterprise network” only > > [TR] Agreed, fixed. > > 4.Page 4 chapter 4: The overall context of the “happy eyeballs” and its relations (or coexistence) to CoAP is not clear. > > [TR] Happy eyeballs mechanism is used to reduce connection delay to setup (D)TLS session with the DOTS server. Happy eyeballs mechanism is not related to CoAP. > > 5.Page 7 chapter 5.2.1: The need for YANG model cannot be understood from text. What are the needs for YANG models? What is the relation to the JSONs in the other chapters in the draft > > [TR] YANG is a data modeling language used to model configuration and state data; The configuration and state data defined using YANG can be represented in JSON or CBOR or XML. Since CBOR is binary, JSON is used in the draft but only for illustrative purpose. > > 6.Page 14 figure 5: The mitigation request attributes are right but not enough. Need to add more telemetry info about the actual attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. > > [TR] Yes, I plan to update the draft with telemetry info based on outcome of draft-doron-dots-telemetry-00. > > 7.Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested > > [TR] Changed to minutes > > 8.Page 15 last paragraph: Not sure that target port or target protocol can define a protected entity. IP, FQDN, URI are the only “stand alone” attributes , port and protocol are companion attributes. See also figure 9 . > > [TR] Good point, fixed. > > 9.Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is related ? “policy ID” ? I think the best is have another attribute to define the priority of mitigation requests > > [TR] policy-id is specific to a DOTS client, DOTS server need not compare the policy-id of one customer with the policy-id of another customer. Policy-ids are only compared b/w multiple mitigation requests from the same DOTS client to determine the priority. DOTS signaling channel runs over UDP, and packets may arrive out-of-order; this was also one of the reasons to introduce policy-id. > > [Ehud] Consider to update the text in page 15 with your explanations here, mainly regarding the “per customer uniqueness of DOTS”. > > [TR2] NEW: > > The relative order of two mitigation requests from a DOTS client is determined by comparing their respective policy-id values. > > 10.Page 21 table: The return status are right but not enough. Need to add more telemetry info about the actual mitigation going on (how much traffic was mitigated) and the attack that are mitigated, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG. > > [TR] Same response as 6; for now will update the draft to convey the following telemetry info from the DOTS server : total dropped byte count, average dropped bytes per second, total dropped packet count and average dropped packets per second. The list is not complete, what kind of telemetry info is required for L7 attacks (e.g. attack at TLS, partial HTTP request, garbage request etc.) and how do we deal with new type of DDOS attacks (Do we keep updating the spec as and when a new DDOS attack is discovered) ? > > [Ehud] Agreed with the bytes / packets count drop you proposed. For the Layer 7 telemetries and for DDoS attacks list , I think we should first get to an agreement about the needs for this attributes and then figure out the best way to signal this information. Personally I don’t believe we should update the spec for each attack, therefor we need to figure out an efficient means to signal this information. > > [TR2] Agreed. > > 11.Page 15 : Need to find the way to bind the target-ip*s* with target-port-range*s* and target-protocol*s*, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth. > > [TR] Yes, it’s possible; create different aliases for IP1 TCP port 80 and IP 2 UDP port 53 using DOTS data channel and convey the aliases in DOTS signal channel. > > 12.Page 21 last paragraph: This is very strong point. > > [TR] Thanks. > > 13.Page 25 : Regarding attack status, same point about telemetry. > > [TR] Same response as above. > > 14.Page 25 chapter 5.4: I believe it can valuable to add a short high level description about the proposed API flow, same as you did for 5.3 . > > [TR] 5.3 gives background how GET, POST, DELETE and PUT will be used, hence did not see a need to add a high level description in Section 5.4. > > 15.Page 27: The necessity of policy_id here is not clear enough, are the “Signal Channel Session Configuration” define only “single” DOTS session or the entire communication between Client and Server for several DOTS request for mitigation? > > [TR] It’s for a single DOTS session between DOTS client and server, a single DOTS session can be used for several DOTS requests and responses. > > 16.Page 27: Not sure about the reason for “at least one of the attributes heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor MUST be present.” Also consider to change to “presented”. > > [TR] what is the point in conveying a POST request without any configuration parameters/attributes ? > > [Ehud] OK, understood. So I think you need to emphasize that in cases not all attributes are defined, need to use default values. In page 26 you wrote something about “need not be default”. Consider to re-write. > > [TR2] NEW: > > The DOTS agents MUST use the negotiated values for message transmission > > parameters and default values for non-negotiated message transmission > > parameters. The signaling channel session configuration is > > applicable to a single DOTS signal channel session between the DOTS > > agents. > > -Tiru > > 17.Page 30 chapter 5.5: Need to specify the overall scenario, in reaction to which signal (or API transaction POST of Mitigation Request , unidirectional notification from Server as describes in page 23 in page 21 ?) the redirection occurred ? > > [TR] Both, updated draft. > > -Tiru > > *_Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel draft-reddy-dots-data-channel-03_* > > 1.General comment: For all signal in the draft, need to add means to allow vendor specific attributes as part of all signals transactions > > 2.Page 5 second paragraph: Why it is required to configure the DOTS signal channel session ? > > 3.Page 8 chapter 3.2.1 : Any reason for not including these identifiers in the DOTS signal channel draft ? > > 4.Page 9 figure 3 : Need to find the way to bind the target-ip*s* with target-port-range*s* and target-protocol*s*, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth. > > 5.Page 13 chapter 3.3 : Need to emphasize that filtering rules are relevant for both client server direct communication and through a DOTS gateway. The chapter is a bit confusing. > > 6.Page 14 chapter 3.3 : I am missing the white-list installation, is it by using the permit action ? > > 7.Page 15 figure 8: For DDoS it is highly valuable to have rate limit as an action. Consider adding such action (if already defined need to explain where and how). > > 8.Page 15 figure 8: Need to consider adding priority to an ACL to support cases when several filtering rules are conflicting. > > 9.Page 15 : The action field cannot be optional attribute. > > 10.Page 16 chapter 3.3.3: Need to add more telemetry info about the actual traffic that was blocked (bps, pps and so on), but as I believe this might be another issue… > > Thanks, > > ** > > *Ehud Doron *| Senior Architect, *Radware* CTO office | *M:*+972-54-7575503 | *T:* +972-72-3917120 > > _______________________________________________ > > 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 --------------BA1A090BC07377B9E56668FA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 2017/03/01 11:05, Tirumaleswar Reddy (tireddy) wrote:

From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Wednesday, March 1, 2017 12:57 AM
To: Ehud Doron <EhudD@Radware.com>; Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; kaname nishizuka <kaname@nttv6.jp>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: RE: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

In my opinion, units of seconds are preferable in a protocol, if only because they are the base S.I. unit.

 

Agreed, fixed in my local copy.

 


Yes. I agree.

thank you,
Kaname

-Tiru

 

Any user interface (or programming interface) can easily convert minutes to seconds if desired.

 

 

 

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron
Sent: Tuesday, February 28, 2017 9:57 AM
To: Tirumaleswar Reddy (tireddy); kaname nishizuka; 'dots'
Cc: David Aviv
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru, Kaname

 

As this attribute is defined as the lifetime of the all mitigation request (i.e. the entire attack period), as per my knowledge this kind of period can typically be relatively long (hours and more),  so that why minutes can be more comfortable to operate.

However if Kaname thinks seconds is better as it is more granular, this can be suggested here as well.

 

Thanks, Ehud

 

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Tuesday, February 28, 2017 11:14 AM
To: kaname nishizuka <kaname@nttv6.jp>; Ehud Doron <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: RE: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

From: kaname nishizuka [mailto:kaname@nttv6.jp]
Sent: Friday, February 24, 2017 10:17 AM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; Ehud Doron <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Tiru,

I'd like to add a comment on lifetime attribute in signal-channel

> 7.       Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested
> [TR] Changed to minutes

I prefer seconds than minutes because I think granularity of minutes is rough.
If we are to leverage programmable and automated feature of DOTS, lifetime in "seconds" is fine.

Works for me.

Ehud – Any specific reason for suggesting minutes ?

-Tiru

 



thank you,
Kaname

On 2017/02/16 23:00, Tirumaleswar Reddy (tireddy) wrote:

Hi Ehud,

 

Please see inline [TR2]

 

From: Ehud Doron [mailto:EhudD@Radware.com]
Sent: Thursday, February 16, 2017 6:43 PM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru Hi

 

Thanks for your response and clarifications.

Please see inline (Followed after [Ehud] )

 

Thanks,

 

Ehud Doron |  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Tuesday, February 14, 2017 4:53 PM
To: Ehud Doron <EhudD@Radware.com>; 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Hi Ehud,

 

Thanks for the detailed review, Please see inline (I will respond to data channel comments in a separate mail)

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <dots@ietf.org>
Cc: David Aviv <DavidA@Radware.com>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

Tiru and authors Hi

 

Attached please find my comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

 

 

Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy-dots-signal-channel-07

 

1.       General comment: For all signals in the draft, need to add means to allow vendor specific attributes as part of all signals transactions

 

[TR] Yes, will update draft.

 

2.       General comment: Just for clarity, need to explicitly mention on each figure when it is an example or the actual API

 

[TR] Done.

 

3.       Page 3 second paragraph : DOTS should not be limited to “enterprise network” only

 

[TR] Agreed, fixed.

 

4.       Page 4 chapter 4: The overall context of the “happy eyeballs” and its relations (or coexistence) to CoAP is not clear.  

 

[TR] Happy eyeballs mechanism is used to reduce connection delay to setup (D)TLS session with the DOTS server. Happy eyeballs mechanism is not related to CoAP.

 

5.       Page 7 chapter 5.2.1: The need for YANG model cannot be understood from text. What are the needs for YANG models? What is the relation to the JSONs in the other chapters in the draft

 

[TR] YANG is a data modeling language used to model configuration and state data;  The configuration and state data defined using YANG can be represented in JSON or CBOR or XML. Since CBOR is binary, JSON is used in the draft but only for illustrative purpose.

 

6.       Page 14 figure 5: The mitigation request attributes are right but not enough. Need to add more telemetry info about the actual attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG.

 

[TR] Yes, I plan to update the draft with telemetry info based on outcome of draft-doron-dots-telemetry-00.

 

7.       Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested

 

[TR] Changed to minutes

 

8.       Page 15 last paragraph: Not sure that target port or target protocol can define a protected entity. IP, FQDN, URI are the only “stand alone” attributes , port and protocol are companion attributes. See also figure 9 .

 

[TR] Good point, fixed.

 

9.       Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is related ?   “policy ID” ? I think the best is have another attribute to define the priority of mitigation requests

[TR] policy-id is specific to a DOTS client, DOTS server need not compare the policy-id of one customer with the policy-id of another customer. Policy-ids are only compared b/w multiple mitigation requests from the same DOTS client to determine the priority. DOTS signaling channel runs over UDP, and packets may arrive out-of-order; this was also one of the reasons to introduce policy-id.

[Ehud] Consider to update the text in page 15 with your explanations here, mainly regarding the “per customer uniqueness of DOTS”.

 

[TR2] NEW:

The relative order of two mitigation requests from a DOTS client is determined by comparing their respective policy-id values.

 

10.   Page 21 table: The return status are right but not enough. Need to add more telemetry info about the actual mitigation going on (how much traffic was mitigated) and the attack that are mitigated, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG.

 

[TR] Same response as 6; for now will update the draft to convey the following telemetry info from the DOTS server : total dropped byte count, average dropped bytes per second, total dropped packet count and average dropped packets per second. The list is not complete, what kind of telemetry info is required for L7 attacks (e.g. attack at TLS, partial HTTP request, garbage request etc.) and how do we deal with new type of DDOS attacks (Do we keep updating the spec as and when a new DDOS attack is discovered) ?

[Ehud] Agreed with the bytes / packets count drop you proposed. For the Layer 7 telemetries and for DDoS attacks list , I think we should first get to an agreement about the needs for this attributes and then figure out the best way to signal this information. Personally I don’t believe we should update the spec for each attack, therefor we need to figure out an efficient means to signal this information.  

 

[TR2] Agreed.

 

11.   Page 15 : Need to find the way to bind the target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

[TR] Yes, it’s possible; create different aliases for IP1 TCP port 80 and IP 2 UDP port 53 using DOTS data channel and convey the aliases in DOTS signal channel.

 

12.   Page 21 last paragraph: This is very strong point.

 

[TR] Thanks.

 

13.   Page 25 : Regarding attack status, same point about telemetry.

 

[TR] Same response as above.

 

14.   Page 25 chapter 5.4: I believe it can valuable to add a short high level description about the proposed API flow, same as you did for 5.3 .

 

[TR] 5.3 gives background how GET, POST, DELETE and PUT will be used, hence did not see a need to add a high level description in Section 5.4.

 

 

15.   Page 27:  The necessity of policy_id here is not clear enough, are the “Signal Channel Session Configuration” define only “single” DOTS session or the entire communication between Client and Server for several DOTS request for mitigation?

 

[TR]  It’s for a single DOTS session between DOTS client and server, a single DOTS session can be used for several DOTS requests and responses.

 

16.   Page 27: Not sure about the reason for “at least one of the attributes heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor MUST be present.” Also consider to change to “presented”.

 

[TR] what is the point in conveying a POST request without any configuration parameters/attributes ?
[Ehud] OK, understood. So I think you need to emphasize that in cases not all attributes are defined, need to use default values. In page 26 you wrote something about “need not be default”. Consider to re-write. 
 
[TR2] NEW:
The DOTS agents MUST use the negotiated values for message transmission
parameters and default values for non-negotiated message transmission
parameters.  The signaling channel session configuration is
applicable to a single DOTS signal channel session between the DOTS
agents. 

 

-Tiru

 

17.   Page 30 chapter 5.5: Need to specify the overall scenario, in reaction to which signal (or API transaction POST of Mitigation Request , unidirectional notification from Server as describes in page 23 in page 21 ?) the  redirection occurred ?

 

[TR] Both, updated draft.

 

-Tiru

 

Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-dots-data-channel-03

 

1.       General comment: For all signal in the draft, need to add means to allow vendor specific attributes as part of all signals transactions

 

2.       Page 5 second paragraph: Why it is required to configure the DOTS signal channel session ?  

 

3.       Page 8 chapter 3.2.1 : Any reason for not including these identifiers in the DOTS signal channel draft ?

 

4.       Page 9 figure 3 : Need to find the way to bind the target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

 

5.       Page 13 chapter 3.3 : Need to emphasize that filtering rules are relevant for both client server direct communication and through a DOTS gateway. The chapter is a bit confusing.

 

6.       Page 14 chapter 3.3 : I am missing the white-list installation, is it by using the permit action ?

 

7.       Page 15 figure 8: For DDoS it is highly valuable to have rate limit as an action. Consider adding such action (if already defined need to explain where and how).

 

8.       Page 15 figure 8: Need to consider adding priority to an ACL to support cases when several filtering rules are conflicting.

 

9.       Page 15 : The action field cannot be optional attribute.

 

10.   Page 16 chapter 3.3.3: Need to add more telemetry info about the actual traffic that was blocked (bps, pps and so on), but as I believe this might be another issue…

 

 

 

Thanks,

 

Ehud Doron |  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

 

 

 

 

 

_______________________________________________
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

--------------BA1A090BC07377B9E56668FA-- From nobody Tue Feb 28 23:37:42 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D77A1294BF for ; Tue, 28 Feb 2017 23:37:41 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 jtmUURXhz2OZ for ; Tue, 28 Feb 2017 23:37:39 -0800 (PST) Received: from mailout1.radware.com (mailout1.radwarecloud.com [192.115.180.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344131294C3 for ; Tue, 28 Feb 2017 23:37:39 -0800 (PST) Received: from ILMB2.corp.radware.com ([169.254.2.155]) by ILCAS1.corp.radware.com ([176.200.120.121]) with mapi id 14.03.0319.002; Wed, 1 Mar 2017 09:37:35 +0200 From: Ehud Doron To: "Roman D. Danyliw" , "dots@ietf.org" Thread-Topic: Preliminary IETF 98 agenda and related preparation Thread-Index: AdKRBlCtpO6PVF3iT52NwSb1gwdskABVYJAw Date: Wed, 1 Mar 2017 07:37:34 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC0104F0CCCA@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0104F0CCCA@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [176.200.121.205] x-tm-as-product-ver: SMEX-11.0.0.4179-8.100.1062-22914.005 x-tm-as-result: No--7.802000-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Preliminary IETF 98 agenda and related preparation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 07:37:41 -0000 Roman Hi Thanks for the update.=20 Do you have any estimation for the day the other DOTS meetings (design team= and other) are planned to be held? Kindly, it can be a great help to get this info in order to finalize my fl= ights.=20 I would prefer to have these meetings no later than Wednesday.=20 Thanks, Ehud -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Monday, February 27, 2017 4:35 PM To: dots@ietf.org Subject: [Dots] Preliminary IETF 98 agenda and related preparation Hello WG! The preliminary agenda for IETF 98 has been published at https://datatracke= r.ietf.org/meeting/98/agenda.txt. DOTS is tentatively scheduled for: TUESDAY, March 28, 2017 1640-1840 Afternoon Session III Zurich G SEC dots DDoS Open Threat Signaling WG Please keep in mind that the final agenda won't be published until 2017-03= -03 (Friday). The Internet Draft submission cut-off (for all drafts, including -00) for t= his meeting will be on 2017-03-13 (Monday) UTC 23:59. If you are interested in presenting please send your requests to the chairs= . Roman _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots