From nobody Wed Apr 1 10:31:53 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC741A0A6A; Wed, 1 Apr 2015 10:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeJYC-7WFxFg; Wed, 1 Apr 2015 10:31:44 -0700 (PDT) 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 8DC221A0084; Wed, 1 Apr 2015 10:31:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUJ88743; Wed, 01 Apr 2015 17:31:41 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 1 Apr 2015 18:31:41 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Wed, 1 Apr 2015 10:31:31 -0700 From: Linda Dunbar To: "Teague, Nik" , "dots@ietf.org" Thread-Topic: scope Thread-Index: AQHQa8ImfNQMx27PokCfZQ+6rvOaCp04aHXg Date: Wed, 1 Apr 2015 17:31:30 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657BFF946@dfweml701-chm> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.214] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657BFF946dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2nsf@ietf.org" Subject: Re: [Dots] scope X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 17:31:51 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657BFF946dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nik, Can you elaborate a bit more on the "peacetime provisioning channel"? What kind of "configuration data" is exchanged on over this channel? What p= rotocol? Is it NETCONF? In parallel to DOTS, there is the I2NSF initiative intended for specifying = the security policies to security functions (primarily the flow based secu= rity functions). https://datatracker.ietf.org/doc/draft-lopez-i2nsf-packet/ has identified t= hree types interfaces to security functions: * Configuration - Device configuration - Network configuration * Signaling - Status - Counters - Queries - Alerts * Provisioning - Capabilities - Policy - Object Configuration I2NSF will focus on the 3rd bullet, i.e. the Provisioning part. Just want to see if the provisioning you mentioned could provide the synerg= y to I2NSF's provisioning. Thanks, Linda From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Teague, Nik Sent: Tuesday, March 31, 2015 9:51 AM To: dots@ietf.org Subject: [Dots] scope Hi, I hope everyone had good journeys home or onward to wherever you may be. I wanted to follow up on the BOF and the outcomes - in particular I wanted = to discuss scope, requirements and some thoughts. Please feedback your tho= ughts/opinions... Firstly applicability - as was clear from the BOF we were defining DDoS mit= igation devices/applications or devices which may have other functions but = contain a DDoS mitigation element. The devices/applications may have eithe= r inline or out of band detection/mitigation capabilities and may be deploy= ed as part of a larger mitigation strategy. Its signaling between these el= ements and an upstream or service provider that we're concerned with. The = term CPE was used which we will clarify to the term 'on-premise' to remove = any confusion as to what we're discussing. These devices/applications already provide a degree of sophisticated analyt= ics based on the traffic they observe. The upstream element may, therefore= , only require data relevant to its needs in identifying that an offramp is= desired and telemetry in order for situational awareness in providing the = correct mitigation strategy. As was discussed feedback from the upstream/s= ervice provider is desirable relating to ongoing attack statistics and also= its conclusion. Characteristics Signaling: >From discussions its clear that the signaling element should include a leve= l of encryption/obfuscation to negate the need for additional vpns, infrast= ructure etc. Signaling should be lightweight and transport should not be s= ession oriented in the classical sense. It may be assumed likely that the = ingress path to the on-premise device may be congested and loss should be e= xpected and tolerated. The ability to optimise as much information as poss= ible into discrete packets is a definite advantage based upon the high prob= ability of link/path congestion. Provisioning: A peacetime provisioning channel has proven effective in various vendor imp= lementations for authentication, key exchange, configuration exchange etc. = and it seems a good way to proceed since the information exchanged is usual= ly weightier and doesn't have restrictions relating to a congested network.= From discussions it was suggested the on-premise device would be in the b= est position to communicate thresholds as to when a traffic swing should be= triggered. The ability to simply signal (without additional qualification= ) that an upstream mitigation is requested is also desirable. This may be = a potential in-road to enabling this on less sophisticated (re DDoS) device= types - e.g. If link >=3D80% then call for help. Thanks, -Nik "This message (including any attachments) is intended only for the use of t= he individual or entity to which it is addressed, and may contain informati= on that is non-public, proprietary, privileged, confidential and exempt fro= m disclosure under applicable law or may be constituted as attorney work pr= oduct. If you are not the intended recipient, you are hereby notified that = any use, dissemination, distribution, or copying of this communication is s= trictly prohibited. If you have received this message in error, notify send= er immediately and delete this message immediately." --_000_4A95BA014132FF49AE685FAB4B9F17F657BFF946dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nik,

 <= /p>

Can you elaborate a bit m= ore on the  “peacetime provisioni= ng channel”?

 

What kind of “confi= guration data” is exchanged on over this channel? What protocol? Is i= t NETCONF?

 <= /p>

In parallel to DOTS, ther= e is the I2NSF initiative intended for specifying the security policies to =  security functions (primarily the flow based security functions).

https://datatracker.ietf.= org/doc/draft-lopez-i2nsf-packet/ has identified three types interfaces to = security functions:

• &nbs= p;     Configuration

– &nbs= p;    Device configurat= ion

– &nbs= p;    Network configura= tion

• &nbs= p;     Signaling

– &nbs= p;    Status=

– &nbs= p;    Counters

– &nbs= p;    Queries

– &nbs= p;    Alerts=

• &nbs= p;     Provisioning=

– &nbs= p;    Capabilities=

– &nbs= p;    Policy=

– &nbs= p;    Object Configurat= ion

 <= /p>

 <= /p>

I2NSF will focus on the 3= rd bullet, i.e. the Provisioning part.

 <= /p>

Just want to see if the p= rovisioning you mentioned could provide the synergy to I2NSF’s provis= ioning.  

 <= /p>

Thanks,

Linda

 <= /p>

From: Dots [ma= ilto:dots-bounces@ietf.org] On Behalf Of Teague, Nik
Sent: Tuesday, March 31, 2015 9:51 AM
To: dots@ietf.org
Subject: [Dots] scope

 

Hi,

 

I hope everyone had good jou= rneys home or onward to wherever you may be.

 

I wanted to follow up on the= BOF and the outcomes – in particular I wanted to discuss scope, requ= irements and some thoughts.  Please feedback your thoughts/opinions= 230;

 

Firstly applicability –= ; as was clear from the BOF we were defining DDoS mitigation devices/applic= ations or devices which may have other functions but contain a DDoS mitigation element.  The devices/applications may have either in= line or out of band detection/mitigation capabilities and may be deployed a= s part of a larger mitigation strategy.  Its signaling between these e= lements and an upstream or service provider that we’re concerned with.  The term CPE was used which we will= clarify to the term ‘on-premise’ to remove any confusion as to= what we’re discussing.

 

These devices/applications a= lready provide a degree of sophisticated analytics based on the traffic the= y observe.  The upstream element may, therefore, only require data relevant to its needs in identifying that an offramp is desired and t= elemetry in order for situational awareness in providing the correct mitiga= tion strategy.  As was discussed feedback from the upstream/service pr= ovider is desirable relating to ongoing attack statistics and also its conclusion.

 

Characteristics 

 

Signaling:=

From discussions its clear t= hat the signaling element should include a level of encryption/obfuscation = to negate the need for additional vpns, infrastructure etc.  Signaling should be lightweight and transport should not be session = oriented in the classical sense.  It may be assumed likely that the in= gress path to the on-premise device may be congested and loss should be exp= ected and tolerated.  The ability to optimise as much information as possible into discrete packets is a definite advant= age based upon the high probability of link/path congestion.

 

Provisioning:

A peacetime provisioning cha= nnel has proven effective in various vendor implementations for authenticat= ion, key exchange, configuration exchange etc. and it seems a good way to proceed since the information exchanged is usually weightier= and doesn’t have restrictions relating to a congested network.  = ;From discussions it was suggested the on-premise device would be in the be= st position to communicate thresholds as to when a traffic swing should be triggered.  The ability to simply sign= al (without additional qualification) that an upstream mitigation is reques= ted is also desirable.  This may be a potential in-road to enabling th= is on less sophisticated (re DDoS) device types – e.g. If link >=3D80% then call for help.

 

Thanks,

 

-Nik

 

 

“This message (including any attachments) is intended only= for the use of the individual or entity to which it is addressed, and may = contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be con= stituted as attorney work product. If you are not the intended recipient, y= ou are hereby notified that any use, dissemination, distribution, or copyin= g of this communication is strictly prohibited. If you have received this message in error, notify sender imme= diately and delete this message immediately.”
--_000_4A95BA014132FF49AE685FAB4B9F17F657BFF946dfweml701chm_-- From nobody Wed Apr 1 12:23:18 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC7F1A036E for ; Wed, 1 Apr 2015 12:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id un_WoBNi65NT for ; Wed, 1 Apr 2015 12:23:14 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (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 D7FF01A6F0A for ; Wed, 1 Apr 2015 12:23:13 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so27622025lbb.0 for ; Wed, 01 Apr 2015 12:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rv4Qyaxpt20ihJk4GhTVnaaLTB5qDnkzeg184v5y0A8=; b=KMK+K5xYt4Lwvc/SjwMF6PXHhrYUtXq0X4NyVd4rKVOySbaI5IRinTNP1pMqGBXCtE OGCh9VGmH5wx+QJZPqSzCvi/ju52fSC3vXYwDRacb5HH157EGTdqpyENycfL6z9dZ0gn AfGX0Mvt1Gym7Hj0IIxIoDZzbGBI7w7yQtB6xJEDVCtThMnoYPkkuVfZmnKS69O8gEfT vtl7EM96tPEf4DXAD7hyThvbc6U1SNfSOXAZDDSe/y84N9Dq1NhC3sAbyzLwDJ0XZqbz Y0Ks5nGPtMmr8Jd/5xJYRqQsCFoqx+F3xZ9s7kWmCO3i5zNh+YuifeSn7QOS9rXZbV21 Y/FQ== MIME-Version: 1.0 X-Received: by 10.112.167.228 with SMTP id zr4mr6043527lbb.113.1427916192403; Wed, 01 Apr 2015 12:23:12 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Wed, 1 Apr 2015 12:23:12 -0700 (PDT) In-Reply-To: <8B8C515B-3D14-4D17-AAD3-72A0EFF99E0D@iab.org> References: <8B8C515B-3D14-4D17-AAD3-72A0EFF99E0D@iab.org> Date: Wed, 1 Apr 2015 15:23:12 -0400 Message-ID: From: Kathleen Moriarty To: "dots@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2432a6ad5ff0512aea5dd Archived-At: Subject: [Dots] Fwd: Date change for CARIS submissions X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 19:23:16 -0000 --001a11c2432a6ad5ff0512aea5dd Content-Type: text/plain; charset=UTF-8 Please note the submission date change to April 10th for the CARIS workshop. We look forward to your submission and participation. Thank you, Kathleen ---------- Forwarded message ---------- From: IAB Chair Date: Wed, Apr 1, 2015 at 3:17 PM Subject: Date change for CARIS submissions To: ietf list , ietf@ietf.org Dear colleagues, The Co-ordinating Attack Response at Internet Scale (CARIS) workshop program committee is extending the deadline for submissions by one week, to 10 April 2015. The call for papers is available from https://www.iab.org/activities/workshops/caris/call-for-papers/. For more information on CARIS, please see https://www.iab.org/activities/workshops/caris/. Best regards, Andrew Sullivan IAB Chair -- Best regards, Kathleen --001a11c2432a6ad5ff0512aea5dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please note the submission date change to April 10th for t= he CARIS workshop.=C2=A0 We look forward to your submission and participati= on.

Thank you,
Kathleen

---------- Forwarded message ----------
From: <= b class=3D"gmail_sendername">IAB Chair <iab-chair@iab.org>
Date: Wed, A= pr 1, 2015 at 3:17 PM
Subject: Date change for CARIS submissions
To: = ietf list <ietf-announce@ietf.= org>, ietf@ietf.org


= Dear colleagues,

The Co-ordinating Attack Response at Internet Scale (CARIS) workshop
program committee is extending the deadline for submissions by one
week, to 10 April 2015.=C2=A0 The call for papers is available from
https://www.iab.org/activities/workshops/caris/call-for-= papers/.=C2=A0 For
more information on CARIS, please see
https://www.iab.org/activities/workshops/caris/.

Best regards,

Andrew Sullivan
IAB Chair




--

Best regards,
Kath= leen
--001a11c2432a6ad5ff0512aea5dd-- From nobody Wed Apr 1 12:30:26 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7BF1A8825 for ; Wed, 1 Apr 2015 12:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=unavailable 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 WgMCgZ63KFtr for ; Wed, 1 Apr 2015 12:30:22 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (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 49FEE1A8725 for ; Wed, 1 Apr 2015 12:30:22 -0700 (PDT) Received: by lagg8 with SMTP id g8so44626995lag.1 for ; Wed, 01 Apr 2015 12:30:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eGuNTL+hSjlqWEkTkqJnVkUWJBvdxPsm/jcO2pPLqTM=; b=Iw89wFybdHb4HLlB5+i/tIdFapiVX9bTE9asct+GfCpqLxCWzIW02IWedObF47jrga WZAiYCK2nHYgIa6IfLOoUWnO1n6UBQf7ofRE7l7P/O8XGzsih7sH11qrejw7QOmbg1ng +mX336R1W0tUUohuO28KSQyD78l0u18WjncTa6SDCSPimVd84caOUunlpnyjCZjc/3Vb mSsuuUSzojf5vrwxiplwdKVNixTtfxvNxQvpFnfjIAKdy/wr4Xuggbp8BxVgi/v8j8h5 y1DW9vsNEQjSV31CBa5RBnzllfJP2CBo2lkPX6TAE3uZ0MUU3DKrsaxVLIfQTUC8tTnL yo6A== X-Gm-Message-State: ALoCoQlBDUrM1zkBJiggkbyOiFFiCaaGwez1C5UA8eWNdpGali+kGI5jwD1RBG2NQ+jRtuwgYxur X-Received: by 10.152.37.69 with SMTP id w5mr37301036laj.15.1427916620701; Wed, 01 Apr 2015 12:30:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.37.4 with HTTP; Wed, 1 Apr 2015 12:30:00 -0700 (PDT) In-Reply-To: References: From: Joseph Lorenzo Hall Date: Wed, 1 Apr 2015 15:30:00 -0400 Message-ID: To: Kathleen Moriarty Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF , "dots@ietf.org" Subject: Re: [Dots] Call for Papers: IAB/ISOC Workshop on Coordinating Attack Response at Internet Scale X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 19:30:24 -0000 Kathleen, I'm seeing some different due dates... you mention 3 April below and the CFP page says the same: https://www.iab.org/activities/workshops/caris/call-for-papers/ However, the home page for the workshop says 10 April: https://www.iab.org/activities/workshops/caris/ Should we obey the earlier or was the change on the main page just not translated down into the CFP? best, Joe (didn't CC MILE as I'm not on that list.) On Mon, Mar 30, 2015 at 8:16 PM, Kathleen Moriarty wrote: > Reminder: submissions are dues for the CARIS workshop on April 3rd. Please > see the notification below for additional information. > > On Wed, Mar 4, 2015 at 3:16 PM, IAB Chair wrote: >> >> Internet Architecture Board (IAB) and Internet Society (ISOC) workshop on >> Coordinating Attack Response at Internet Scale (CARIS) >> >> June 19, 2015, Intercontinental Hotel in Berlin, hosted by the 27th annual >> FIRST Conference >> >> Workshop Information: https://www.iab.org/activities/workshops/caris/ >> >> Numerous incident response efforts exist to mitigate the effects of >> attacks. Some are operator driven focused on specific attack types, while >> others are closed analysis and sharing groups spanning many attack types. >> Many of the operator driven models work with members to mitigate the effects >> of such attacks for all users, but how to contribute information to these >> efforts is not always known or easy to discover. Sharing within closed >> community analysis centers is only practical for very large organizations as >> a result of resource requirements even to be able to use shared data. >> Without coordination, these efforts are not only duplicated, but leave out >> protections for small and medium sized organizations. These organizations >> may be part of the supply chain for larger organizations, a common pathway >> for successful attacks. >> >> This workshop aims to bring together operators, researchers, CSIRT team >> members, service providers, vendors, information sharing and analysis center >> members to discuss approaches to coordinate attack response at Internet >> scale. >> >> The day-long workshop will include a mix of invited and selected speakers >> with opportunities to collaborate throughout, taking full advantage of the >> tremendous value of having these diverse communities with common goals in >> one room. >> >> >> Submission Instructions: >> >> Attendance at the workshop is by invitation only. There is no fee to >> attend the workshop. >> >> For existing attack-mitigation working groups, the survey at >> >> >> https://internetsociety2.wufoo.com/forms/caris-workshop-organisation-template/ >> should be completed by those organizations whose mitigation efforts or use >> case analyses apply. The data gathered through this questionnaire, including >> how to participate or contribute to your attack mitigation working group, >> will be shared with all of the participants at the workshop to better enable >> collaboration with your effort. >> >> Alternatively, submit a 2-page research paper that includes some key >> insight or challenge relevant to the broader group. This may include >> research topics around attack mitigation or information sharing/exchange, >> success stories from your CSIRT, lessons learned, or a deep dive on a >> particular topic such as privacy or trust. >> >> Submissions accepted at: https://easychair.org/conferences/?conf=caris2015 >> Final Submission Deadline: 3 April 2015 >> Notification Deadline: 1 May 2015 >> Workshop Date: 19 June 2015 >> >> All attendees are required to complete the survey or submit a 2-page >> research paper to the CARIS program committee via EasyChair. Accepted >> submissions will be published on the IAB website at: >> https://www.iab.org/activities/workshops/caris/ >> >> Attendees will be selected based on these submissions to ensure the >> workshop will be beneficial to all and has the potential to impact the >> coordination of attack response at Internet scale. >> >> Sponsored by the Internet Architecture Board and the Internet Society. >> http://www.iab.org/ >> http://www.internetsociety.org/ >> >> > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 From nobody Wed Apr 1 12:38:24 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13D61A7018; Wed, 1 Apr 2015 12:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jt_R2a9J03gL; Wed, 1 Apr 2015 12:38:13 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07E21A8794; Wed, 1 Apr 2015 12:38:12 -0700 (PDT) Received: by lahf3 with SMTP id f3so44157976lah.2; Wed, 01 Apr 2015 12:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q53RZdNnIsjbZuxcIP2+UDuRKWVT/1nv9zzdrqkz7Mg=; b=Fg4L7WhOTuVOHEt9siO+zOGDY4XaVxrzMhBemmaYCLIEO+sj7Q7VsVaBAW7Hgqh514 v6r3Rsy28n6YnMXpQxDMyFS3WO0Z5RiwP9GfYwNiT0VnmeEDAzh6YNgK1WZUug8Sjwco zVSNP8+M41Bj7h0V7QZRC7Z9I1K4yicG6wyrAKnYEQPMIXyKPkTy/L+z4Ca6QP4RjLjN kjLA5jPZpjyUReH28kO9vnBm7CGCchflid024FX3WGEEqYsjPunKxQHCusYN1iWlgac9 zFW6uBzltGQwDKnpatiwU7l7rbFyQeuxvUevGxk15BqvujNyywSMMX3hK2m0gi1VWybB feqw== MIME-Version: 1.0 X-Received: by 10.112.188.227 with SMTP id gd3mr38204915lbc.0.1427917091245; Wed, 01 Apr 2015 12:38:11 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Wed, 1 Apr 2015 12:38:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Apr 2015 15:38:11 -0400 Message-ID: From: Kathleen Moriarty To: Joseph Lorenzo Hall Content-Type: multipart/alternative; boundary=001a11c36aa8fe14e40512aeda50 Archived-At: Cc: IETF , "dots@ietf.org" Subject: Re: [Dots] Call for Papers: IAB/ISOC Workshop on Coordinating Attack Response at Internet Scale X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 19:38:19 -0000 --001a11c36aa8fe14e40512aeda50 Content-Type: text/plain; charset=UTF-8 Hi Joe, Thanks for your email. On Wed, Apr 1, 2015 at 3:30 PM, Joseph Lorenzo Hall wrote: > Kathleen, I'm seeing some different due dates... you mention 3 April > below and the CFP page says the same: > > https://www.iab.org/activities/workshops/caris/call-for-papers/ > > However, the home page for the workshop says 10 April: > > https://www.iab.org/activities/workshops/caris/ > > Should we obey the earlier or was the change on the main page just not > translated down into the CFP? > We just extended the submission date and notification pages are in process of being updated. If your submission is ready, please do get it in as that should help in our review and processing of papers or templates. This Friday is both the start of Passover and Good Friday, some may want to be done by then and others needed a little more time. If you notice any other date errors, please do let me or others on the program committee know and we'll get it fixed. Thank you! Kathleen > best, Joe > > (didn't CC MILE as I'm not on that list.) > > > On Mon, Mar 30, 2015 at 8:16 PM, Kathleen Moriarty > wrote: > > Reminder: submissions are dues for the CARIS workshop on April 3rd. > Please > > see the notification below for additional information. > > > > On Wed, Mar 4, 2015 at 3:16 PM, IAB Chair wrote: > >> > >> Internet Architecture Board (IAB) and Internet Society (ISOC) workshop > on > >> Coordinating Attack Response at Internet Scale (CARIS) > >> > >> June 19, 2015, Intercontinental Hotel in Berlin, hosted by the 27th > annual > >> FIRST Conference > >> > >> Workshop Information: https://www.iab.org/activities/workshops/caris/ > >> > >> Numerous incident response efforts exist to mitigate the effects of > >> attacks. Some are operator driven focused on specific attack types, > while > >> others are closed analysis and sharing groups spanning many attack > types. > >> Many of the operator driven models work with members to mitigate the > effects > >> of such attacks for all users, but how to contribute information to > these > >> efforts is not always known or easy to discover. Sharing within closed > >> community analysis centers is only practical for very large > organizations as > >> a result of resource requirements even to be able to use shared data. > >> Without coordination, these efforts are not only duplicated, but leave > out > >> protections for small and medium sized organizations. These > organizations > >> may be part of the supply chain for larger organizations, a common > pathway > >> for successful attacks. > >> > >> This workshop aims to bring together operators, researchers, CSIRT team > >> members, service providers, vendors, information sharing and analysis > center > >> members to discuss approaches to coordinate attack response at Internet > >> scale. > >> > >> The day-long workshop will include a mix of invited and selected > speakers > >> with opportunities to collaborate throughout, taking full advantage of > the > >> tremendous value of having these diverse communities with common goals > in > >> one room. > >> > >> > >> Submission Instructions: > >> > >> Attendance at the workshop is by invitation only. There is no fee to > >> attend the workshop. > >> > >> For existing attack-mitigation working groups, the survey at > >> > >> > >> > https://internetsociety2.wufoo.com/forms/caris-workshop-organisation-template/ > >> should be completed by those organizations whose mitigation efforts or > use > >> case analyses apply. The data gathered through this questionnaire, > including > >> how to participate or contribute to your attack mitigation working > group, > >> will be shared with all of the participants at the workshop to better > enable > >> collaboration with your effort. > >> > >> Alternatively, submit a 2-page research paper that includes some key > >> insight or challenge relevant to the broader group. This may include > >> research topics around attack mitigation or information > sharing/exchange, > >> success stories from your CSIRT, lessons learned, or a deep dive on a > >> particular topic such as privacy or trust. > >> > >> Submissions accepted at: > https://easychair.org/conferences/?conf=caris2015 > >> Final Submission Deadline: 3 April 2015 > >> Notification Deadline: 1 May 2015 > >> Workshop Date: 19 June 2015 > >> > >> All attendees are required to complete the survey or submit a 2-page > >> research paper to the CARIS program committee via EasyChair. Accepted > >> submissions will be published on the IAB website at: > >> https://www.iab.org/activities/workshops/caris/ > >> > >> Attendees will be selected based on these submissions to ensure the > >> workshop will be beneficial to all and has the potential to impact the > >> coordination of attack response at Internet scale. > >> > >> Sponsored by the Internet Architecture Board and the Internet Society. > >> http://www.iab.org/ > >> http://www.internetsociety.org/ > >> > >> > > > > > > > > -- > > > > Best regards, > > Kathleen > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > > > > > > -- > Joseph Lorenzo Hall > Chief Technologist > Center for Democracy & Technology > 1634 I ST NW STE 1100 > Washington DC 20006-4011 > (p) 202-407-8825 > (f) 202-637-0968 > joe@cdt.org > PGP: https://josephhall.org/gpg-key > fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 > -- Best regards, Kathleen --001a11c36aa8fe14e40512aeda50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

Thanks for your email. =C2=A0

On Wed, Apr 1= , 2015 at 3:30 PM, Joseph Lorenzo Hall <joe@cdt.org> wrote:
Kathleen, I'm seeing some different due dates... you ment= ion 3 April
below and the CFP page says the same:

https://www.iab.org/activities/workshops/caris/call-for-= papers/

However, the home page for the workshop says 10 April:

https://www.iab.org/activities/workshops/caris/

Should we obey the earlier or was the change on the main page just not
translated down into the CFP?

We just e= xtended the submission date and notification pages are in process of being = updated.=C2=A0 If your submission is ready, please do get it in as that sho= uld help in our review and processing of papers or templates.=C2=A0 This Fr= iday is both the start of Passover and Good Friday, some may want to be don= e by then and others needed a little more time.

If= you notice any other date errors, please do let me or others on the progra= m committee know and we'll get it fixed.

Thank= you!
Kathleen


best, Joe

(didn't CC MILE as I'm not on that list.)


On Mon, Mar 30, 2015 at 8:16 PM, Kathleen Moriarty
<kathleen.moriarty.i= etf@gmail.com> wrote:
> Reminder: submissions are dues for the CARIS workshop on April 3rd.=C2= =A0 Please
> see the notification below for additional information.
>
> On Wed, Mar 4, 2015 at 3:16 PM, IAB Chair <iab-chair@iab.org> wrote:
>>
>> Internet Architecture Board (IAB) and Internet Society (ISOC) work= shop on
>> Coordinating Attack Response at Internet Scale (CARIS)
>>
>> June 19, 2015, Intercontinental Hotel in Berlin, hosted by the 27t= h annual
>> FIRST Conference
>>
>> Workshop Information: https://www.iab.org/activities/workshops/= caris/
>>
>> Numerous incident response efforts exist to mitigate the effects o= f
>> attacks.=C2=A0 Some are=C2=A0 operator driven focused on specific = attack types, while
>> others are closed analysis and sharing groups spanning many attack= types.
>> Many of the operator driven models work with members to mitigate t= he effects
>> of such attacks for all users, but how to contribute information t= o these
>> efforts is not always known or easy to discover.=C2=A0 Sharing wit= hin closed
>> community analysis centers is only practical for very large organi= zations as
>> a result of resource requirements even to be able to use shared da= ta.
>> Without coordination, these efforts are not only duplicated, but l= eave out
>> protections for small and medium sized organizations.=C2=A0 These = organizations
>> may be part of the supply chain for larger organizations, a common= pathway
>> for successful attacks.
>>
>> This workshop aims to bring together operators, researchers, CSIRT= team
>> members, service providers, vendors, information sharing and analy= sis center
>> members to discuss approaches to coordinate attack response at Int= ernet
>> scale.
>>
>> The day-long workshop will include a mix of invited and selected s= peakers
>> with opportunities to collaborate throughout, taking full advantag= e of the
>> tremendous value of having these diverse communities with common g= oals in
>> one room.
>>
>>
>> Submission Instructions:
>>
>> Attendance at the workshop is by invitation only. There is no fee = to
>> attend the workshop.
>>
>> For existing attack-mitigation working groups, the survey at
>>
>>
>> https://internetsociety2.wufoo.c= om/forms/caris-workshop-organisation-template/
>> should be completed by those organizations whose mitigation effort= s or use
>> case analyses apply. The data gathered through this questionnaire,= including
>> how to participate or contribute to your attack mitigation working= group,
>> will be shared with all of the participants at the workshop to bet= ter enable
>> collaboration with your effort.
>>
>> Alternatively, submit a 2-page research paper that includes some k= ey
>> insight or challenge relevant to the broader group.=C2=A0 This may= include
>> research topics around attack mitigation or information sharing/ex= change,
>> success stories from your CSIRT, lessons learned, or a deep dive o= n a
>> particular topic such as privacy or trust.
>>
>> Submissions accepted at: https://easychair.org/conferences/= ?conf=3Dcaris2015
>> Final Submission Deadline: 3 April 2015
>> Notification Deadline: 1 May 2015
>> Workshop Date: 19 June 2015
>>
>> All attendees are required to complete the survey or submit a 2-pa= ge
>> research paper to the CARIS program committee via EasyChair.=C2=A0= Accepted
>> submissions will be published on the IAB website at:
>> https://www.iab.org/activities/workshops/caris/
>>
>> Attendees will be selected based on these submissions to ensure th= e
>> workshop will be beneficial to all and has the potential to impact= the
>> coordination of attack response at Internet scale.
>>
>> Sponsored by the Internet Architecture Board and the Internet Soci= ety.
>> http://www.iab.o= rg/
>> http= ://www.internetsociety.org/
>>
>>
>
>
>
> --
>
> Best regards,
> Kathleen
>
> ________________________= _______________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots
>



--
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825 (f) 202-637-0968 joe@cdt.org
PGP: https://j= osephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10=C2=A0 1607 5F86 6987 40A9 A871



--
=

Best regards,
Kathleen
--001a11c36aa8fe14e40512aeda50-- From Dave.Larson@corero.com Tue Apr 7 19:17:25 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4541B2B5E for ; Tue, 7 Apr 2015 19:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKfr1Ot7uiex for ; Tue, 7 Apr 2015 19:17:22 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.113]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4FC41B2B5B for ; Tue, 7 Apr 2015 19:17:22 -0700 (PDT) Received: from [216.82.253.243] by server-17.bemta-7.messagelabs.com id D2/05-02438-1BF84255; Wed, 08 Apr 2015 02:17:21 +0000 X-Env-Sender: Dave.Larson@corero.com X-Msg-Ref: server-16.tower-171.messagelabs.com!1428459440!18911644!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10443 invoked from network); 8 Apr 2015 02:17:20 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-16.tower-171.messagelabs.com with AES128-SHA encrypted SMTP; 8 Apr 2015 02:17:20 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0224.002; Tue, 7 Apr 2015 22:17:15 -0400 From: Dave Larson To: "Xialiang (Frank)" , "Teague, Nik" , Scott Barvick Thread-Topic: [Dots] DOTS work scope discussion: //RE: scope Thread-Index: AQHQcaIhLzQhJpbEDkS5B/rKwQEkFg== Date: Wed, 8 Apr 2015 02:17:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [70.192.21.16] Content-Type: multipart/alternative; boundary="_000_D14A0118C9F9davelarsoncorerocom_" MIME-Version: 1.0 Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] DOTS work scope discussion: //RE: scope X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 02:19:27 -0000 --_000_D14A0118C9F9davelarsoncorerocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable HI Frank, I think you raise a few vary important points below: On Wednesday, April 1, 2015 at 1:55 AM, "Xialiang (Frank)" > wrote: Here are my thoughts about DOTS works: 1. The devices can be either DDoS mitigation devices, or normal netwo= rk devices (router, switch). This will make the whole DOTS solution more ge= neral for different scenarios. For example, current two drafts within DOTS = can represent this difference. Maybe, we need an use case draft to elaborat= e their respective values; 2. I agree that upstream systems need to negotiate its requirements o= r capabilities to reporting devices. This feature can save the signaling tr= affics. It means an initialized negotiation mechanism may be needed; 3. A mutual authentication mechanism is needed to protect the communi= cations between the legal senders and receivers, to avoid the faked signali= ng, fault peers, or creating new DDoS attacks, etc; 4. To cope with the rapid evolution and change of the attack types, t= he DOTS solution should consider the capability of openness. Which means th= e specified information model should have the capability in semantic to def= ine and express the new attack information; 5. The whole architecture should not be constrained in our proposed s= cenarios, it can be more general, more comprehensive. For example, more dev= ices construct a mesh network to support the DOTS functions. My thoughts are: 1. I agree. We want to be inclusive on what kinds of devices may signal. = And use cases are a great way to encapsulate the problem space. Though I = would not try to extend the problem space beyond DDoS. 2. I agree. I think this is really bidirectional =96 I can imagine both e= nds of the connection advertising capabilities. I can see the edge systems= (downstream) also advertising what they are capable of signaling and this = would vary depending on the types of devices as you point out in point 1. 3. Authentication is critical to avoid the fake signaling problem you have= pointed out =96 I believe this received some discussion during the BOF in = Dallas.. Whatever we do with this project, It can not introduce a new DDoS = vector by failing to account for this. 4. I believe all participants in the BOF would support openness for attack= type definition. But I also heard strong support for constraining the pro= blem space initially to DDoS. In fact, my opinion, as stated at the BOF, i= s that the most important component of this project is the schema. A conci= se schema that can accommodate all currently known DDoS vectors and a schem= a that is also extensible should be a primary goal for us. 5. I=92m not sure I follow the suggestion of a mesh network here. Similar= to point 4, I believe it is important to get the downstream-to-upstream si= gnaling correct before complicating with mesh topology considerations. In = fact, to further enforce my point above, I think schema is more important t= han topology considerations at first. I think it is critical for us to off= er something that can be tested and proven in the simplest networks that ca= n show the benefit. But your point about openness can not be understated = =96 this must be open and extensible. I have copied a colleague of mine, Scott Barvick. Scott was unable to atte= nd the BOF but has been working on these concepts with me and will likely h= ave some opinions in these areas to share with the thread. Regards, Dave Larson --_000_D14A0118C9F9davelarsoncorerocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
HI Frank,

I think you raise a few vary important points below:

On Wednesday, A= pril 1, 2015 at 1:55 AM, "Xialiang (Frank)" <frank.xialiang@huawei.com> wrote:

Here are my though= ts about DOTS works:

1.       The de= vices can be either DDoS mitigation devices, or normal network devices (rou= ter, switch). This will make the whole DOTS solution more general for different scenarios. For example, current t= wo drafts within DOTS can represent this difference. Maybe, we need an use = case draft to elaborate their respective values;

2.       I agre= e that upstream systems need to negotiate its requirements or capabilities = to reporting devices. This feature can save the signaling traffics. It means an initialized negotiation mechanism= may be needed;

3.       A mutu= al authentication mechanism is needed to protect the communications between= the legal senders and receivers, to avoid the faked signaling, fault peers, or creating new DDoS attacks, etc;=

4.       To cop= e with the rapid evolution and change of the attack types, the DOTS solutio= n should consider the capability of openness. Which means the specified information model should have the capa= bility in semantic to define and express the new attack information;

5.       The wh= ole architecture should not be constrained in our proposed scenarios, it ca= n be more general, more comprehensive. For example, more devices construct a mesh network to support the DOTS fun= ctions.


My thoughts are:

1.  I agree.  We want to be inclusive on what kinds of devic= es may signal.  And use cases are a great way to encapsulate the probl= em space.  Though I would not try to extend the problem space beyond D= DoS.

2.  I agree.  I think this is really bidirectional =96 I can= imagine both ends of the connection advertising capabilities.  I can = see the edge systems (downstream) also advertising what they are capable of= signaling and this would vary depending on the types of devices as you point out in point 1.

3.  Authentication is critical to avoid the fake signaling proble= m you have pointed out =96 I believe this received some discussion during t= he BOF in Dallas.. Whatever we do with this project, It can not introduce a= new DDoS vector by failing to account for this.

4.  I believe all participants in the BOF would support openness = for attack type definition.  But I also heard strong support for const= raining the problem space initially to DDoS.  In fact, my opinion, as = stated at the BOF, is that the most important component of this project is the schema.  A concise schema that can accommodate= all currently known DDoS vectors and a schema that is also extensible shou= ld be a primary goal for us.

5.  I=92m not sure I follow the suggestion of a mesh network here= .  Similar to point 4, I believe it is important to get the downstream= -to-upstream signaling correct before complicating with mesh topology consi= derations.  In fact, to further enforce my point above, I think schema is more important than topology considerations at fi= rst.  I think it is critical for us to offer something that can be tes= ted and proven in the simplest networks that can show the benefit.  Bu= t your point about openness can not be understated =96 this must be open and extensible.

I have copied a colleague of mine, Scott Barvick.  Scott was unab= le to attend the BOF but has been working on these concepts with me and wil= l likely have some opinions in these areas to share with the thread.

Regards,

Dave Larson


--_000_D14A0118C9F9davelarsoncorerocom_-- From nobody Tue Apr 7 20:37:05 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAF01AD0C8 for ; Tue, 7 Apr 2015 20:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KcugnYrkemC for ; Tue, 7 Apr 2015 20:36:59 -0700 (PDT) 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 E17511AD0C7 for ; Tue, 7 Apr 2015 20:36:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUP14180; Wed, 08 Apr 2015 03:36:57 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Apr 2015 04:36:56 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.144]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Wed, 8 Apr 2015 11:36:51 +0800 From: "Xialiang (Frank)" To: Dave Larson , "Teague, Nik" , Scott Barvick Thread-Topic: [Dots] DOTS work scope discussion: //RE: scope Thread-Index: AQHQcaIhLzQhJpbEDkS5B/rKwQEkFp1CchIQ Date: Wed, 8 Apr 2015 03:36:51 +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.42.200] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12ADB0DB5SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] DOTS work scope discussion: //RE: scope X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 03:37:04 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB0DB5SZXEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, I totally agree with you the point that focus DOTS's scope on DDoS in the f= irst stage. It's a reasonable way we push the WG work. Please see my response inline: B.R. Frank From: Dave Larson [mailto:Dave.Larson@corero.com] Sent: Wednesday, April 08, 2015 10:17 AM To: Xialiang (Frank); Teague, Nik; Scott Barvick Cc: dots@ietf.org Subject: Re: [Dots] DOTS work scope discussion: //RE: scope HI Frank, I think you raise a few vary important points below: On Wednesday, April 1, 2015 at 1:55 AM, "Xialiang (Frank)" > wrote: Here are my thoughts about DOTS works: 1. The devices can be either DDoS mitigation devices, or normal netwo= rk devices (router, switch). This will make the whole DOTS solution more ge= neral for different scenarios. For example, current two drafts within DOTS = can represent this difference. Maybe, we need an use case draft to elaborat= e their respective values; 2. I agree that upstream systems need to negotiate its requirements o= r capabilities to reporting devices. This feature can save the signaling tr= affics. It means an initialized negotiation mechanism may be needed; 3. A mutual authentication mechanism is needed to protect the communi= cations between the legal senders and receivers, to avoid the faked signali= ng, fault peers, or creating new DDoS attacks, etc; 4. To cope with the rapid evolution and change of the attack types, t= he DOTS solution should consider the capability of openness. Which means th= e specified information model should have the capability in semantic to def= ine and express the new attack information; 5. The whole architecture should not be constrained in our proposed s= cenarios, it can be more general, more comprehensive. For example, more dev= ices construct a mesh network to support the DOTS functions. My thoughts are: 1. I agree. We want to be inclusive on what kinds of devices may signal. = And use cases are a great way to encapsulate the problem space. Though I = would not try to extend the problem space beyond DDoS. 2. I agree. I think this is really bidirectional - I can imagine both end= s of the connection advertising capabilities. I can see the edge systems (= downstream) also advertising what they are capable of signaling and this wo= uld vary depending on the types of devices as you point out in point 1. [Frank] : Agree with the bidirectional negotiation requirement! 3. Authentication is critical to avoid the fake signaling problem you have= pointed out - I believe this received some discussion during the BOF in Da= llas.. Whatever we do with this project, It can not introduce a new DDoS ve= ctor by failing to account for this. 4. I believe all participants in the BOF would support openness for attack= type definition. But I also heard strong support for constraining the pro= blem space initially to DDoS. In fact, my opinion, as stated at the BOF, i= s that the most important component of this project is the schema. A conci= se schema that can accommodate all currently known DDoS vectors and a schem= a that is also extensible should be a primary goal for us. [Frank] :yes, you raise the key point - a concise schema also with the exte= nsibility! And I hope these two goals can be achieved all, by pre-considera= tion and good design. 5. I'm not sure I follow the suggestion of a mesh network here. Similar t= o point 4, I believe it is important to get the downstream-to-upstream sign= aling correct before complicating with mesh topology considerations. In fa= ct, to further enforce my point above, I think schema is more important tha= n topology considerations at first. I think it is critical for us to offer= something that can be tested and proven in the simplest networks that can = show the benefit. But your point about openness can not be understated - t= his must be open and extensible. [Frank] : Like you state here, what I propose here is about the topology an= d architecture aspects. I agree that this point is a little far than the sc= heme work. We can consider it later. I have copied a colleague of mine, Scott Barvick. Scott was unable to atte= nd the BOF but has been working on these concepts with me and will likely h= ave some opinions in these areas to share with the thread. [Frank] : Welcome, Scott~~ Regards, Dave Larson --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB0DB5SZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dave,

I totally = agree with you the point that focus DOTS’s scope on DDoS in the first= stage. It’s a reasonable way we push the WG work.<= /p>

Please see= my response inline:

 = ;

B.R.<= /o:p>

Frank=

 = ;

From: Dave Larson [mailto:Dave.Larson@corero.com]
Sent: Wednesday, April 08, 2015 10:17 AM
To: Xialiang (Frank); Teague, Nik; Scott Barvick
Cc: dots@ietf.org
Subject: Re: [Dots] DOTS work scope discussion: //RE: scope

 

HI Frank,

 <= /o:p>

I think you = raise a few vary important points below:

 <= /o:p>

On Wednesday= , April 1, 2015 at 1:55 AM, "Xialiang (Frank)" <frank.xialiang@huawei.com> wrote:

 <= /o:p>

Here are my thoughts abo= ut DOTS works:=

1.     &nbs= p; The devices can be either = DDoS mitigation devices, or normal network devices (router, switch). This w= ill make the whole DOTS solution more general for different scenarios. For example, current two drafts within DOTS can represent this = difference. Maybe, we need an use case draft to elaborate their respective = values;

2.     &nbs= p; I agree that upstream syst= ems need to negotiate its requirements or capabilities to reporting devices= . This feature can save the signaling traffics. It means an initialized negotiation mechanism may be needed;

3.     &nbs= p; A mutual authentication me= chanism is needed to protect the communications between the legal senders a= nd receivers, to avoid the faked signaling, fault peers, or creating new DDoS attacks, etc;

4.     &nbs= p; To cope with the rapid evo= lution and change of the attack types, the DOTS solution should consider th= e capability of openness. Which means the specified information model should have the capability in semantic to define and express the new= attack information;

5.     &nbs= p; The whole architecture sho= uld not be constrained in our proposed scenarios, it can be more general, m= ore comprehensive. For example, more devices construct a mesh network to support the DOTS functions.

 

My thoughts are:

 <= /o:p>

1.  I a= gree.  We want to be inclusive on what kinds of devices may signal. &n= bsp;And use cases are a great way to encapsulate the problem space.  T= hough I would not try to extend the problem space beyond DDoS.=

 <= /o:p>

2.  I a= gree.  I think this is really bidirectional – I can imagine both= ends of the connection advertising capabilities.  I can see the edge = systems (downstream) also advertising what they are capable of signaling and this = would vary depending on the types of devices as you point out in point 1.

[Fra= nk] : Agree with the bidirectional negotiation requirement!

 = ;

3.  Aut= hentication is critical to avoid the fake signaling problem you have pointe= d out – I believe this received some discussion during the BOF in Dallas.. Whatever we do with this project, It can not introduce a new D= DoS vector by failing to account for this.

 <= /o:p>

4.  I b= elieve all participants in the BOF would support openness for attack type d= efinition.  But I also heard strong support for constraining the problem space initially to DDoS.  In fact, my opinion, as stated at t= he BOF, is that the most important component of this project is the schema.=  A concise schema that can accommodate all currently known DDoS vecto= rs and a schema that is also extensible should be a primary goal for us.

[Fra= nk] :yes, you raise the key point – a concise schema also with the ex= tensibility! And I hope these two goals can be achieved all, by pre-consideration and good design.

 <= /o:p>

5.  I&#= 8217;m not sure I follow the suggestion of a mesh network here.  Simil= ar to point 4, I believe it is important to get the downstream-to-upstream signaling correct before complicating with mesh topology considerations. &= nbsp;In fact, to further enforce my point above, I think schema is more imp= ortant than topology considerations at first.  I think it is critical = for us to offer something that can be tested and proven in the simplest networks that can show the benefit.  But y= our point about openness can not be understated – this must be open a= nd extensible.

[Fra= nk] : Like you state here, what I propose here is about the topology and ar= chitecture aspects. I agree that this point is a little far than the scheme work. We can consider it later.

 <= /o:p>

I have copie= d a colleague of mine, Scott Barvick.  Scott was unable to attend the = BOF but has been working on these concepts with me and will likely have some opinions in these areas to share with the thread.

[Fra= nk] : Welcome, Scott~~

 <= /o:p>

Regards,

 <= /o:p>

Dave Larson<= o:p>

 <= /o:p>

 <= /o:p>

--_000_C02846B1344F344EB4FAA6FA7AF481F12ADB0DB5SZXEMA502MBSchi_-- From nobody Wed Apr 8 07:37:18 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6DD1B30E6 for ; Wed, 8 Apr 2015 07:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4O10Ax6zuPgX for ; Wed, 8 Apr 2015 07:37:11 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.208]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248BD1B3133 for ; Wed, 8 Apr 2015 07:36:57 -0700 (PDT) Received: from [216.82.242.179] by server-16.bemta-8.messagelabs.com id BE/A8-13729-90D35255; Wed, 08 Apr 2015 14:36:57 +0000 X-Env-Sender: Scott.Barvick@corero.com X-Msg-Ref: server-4.tower-86.messagelabs.com!1428503804!50312879!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1596 invoked from network); 8 Apr 2015 14:36:45 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-4.tower-86.messagelabs.com with AES128-SHA encrypted SMTP; 8 Apr 2015 14:36:45 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0224.002; Wed, 8 Apr 2015 10:36:44 -0400 From: Scott Barvick To: "Xialiang (Frank)" , Dave Larson , "Teague, Nik" Thread-Topic: [Dots] DOTS work scope discussion: //RE: scope Thread-Index: AQHQcaIhLzQhJpbEDkS5B/rKwQEkFp1CchIQgAC3VGA= Date: Wed, 8 Apr 2015 14:36:43 +0000 Message-ID: <6073823821667642A5C884FF3A8807F81F3C7B14@MERCURY.corero.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.30.22] Content-Type: multipart/alternative; boundary="_000_6073823821667642A5C884FF3A8807F81F3C7B14MERCURYcoreroco_" MIME-Version: 1.0 Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] DOTS work scope discussion: //RE: scope X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 14:37:16 -0000 --_000_6073823821667642A5C884FF3A8807F81F3C7B14MERCURYcoreroco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the intro and welcome. From the reading of the minutes and t= he thread, it seems that we can and should be using the words 'DDoS' and 's= ignaling' along with not overlapping with other IETF work to help us check= our activities against a focus that will allow us to get chartered as a WG= and then make the required progress towards goals that we will have as one= . If it is not directly contributing to the signaling of DDoS threats/con= ditions/capabilities then we really should really not be spending any time = on it. As examples (for discussion, of course) - DDoS capabilities negotiation between the communicating parties = - in scope because it affects what can be signaled or needs to be done on = either side - Configuration or provisioning of the devices for DDoS - not in s= cope because while it is DDoS, it is beyond what is necessary to signal. A= nd we have other protocols to define the operations and even schemas for th= is - Communication of signaling thresholds or conditions - in scope - Authentication of signaling channel - in scope - Specific flow stats and flow awareness - not in scope because it= is not DDoS and there are other protocols that represent this kind of info - DDoS attack representation - in-scope because it is DDoS. Of co= urse, if a device can't classify the attack because it is either not that k= ind of device or it is a new attack, then we need a way for this to indicat= e 'unknown' Looking forward to good discussion and the development of a good RFC. Regards, Scott From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com] Sent: Tuesday, April 07, 2015 11:37 PM To: Dave Larson; Teague, Nik; Scott Barvick Cc: dots@ietf.org Subject: RE: [Dots] DOTS work scope discussion: //RE: scope Hi Dave, I totally agree with you the point that focus DOTS's scope on DDoS in the f= irst stage. It's a reasonable way we push the WG work. Please see my response inline: B.R. Frank From: Dave Larson [mailto:Dave.Larson@corero.com] Sent: Wednesday, April 08, 2015 10:17 AM To: Xialiang (Frank); Teague, Nik; Scott Barvick Cc: dots@ietf.org Subject: Re: [Dots] DOTS work scope discussion: //RE: scope HI Frank, I think you raise a few vary important points below: On Wednesday, April 1, 2015 at 1:55 AM, "Xialiang (Frank)" > wrote: Here are my thoughts about DOTS works: 1. The devices can be either DDoS mitigation devices, or normal netwo= rk devices (router, switch). This will make the whole DOTS solution more ge= neral for different scenarios. For example, current two drafts within DOTS = can represent this difference. Maybe, we need an use case draft to elaborat= e their respective values; 2. I agree that upstream systems need to negotiate its requirements o= r capabilities to reporting devices. This feature can save the signaling tr= affics. It means an initialized negotiation mechanism may be needed; 3. A mutual authentication mechanism is needed to protect the communi= cations between the legal senders and receivers, to avoid the faked signali= ng, fault peers, or creating new DDoS attacks, etc; 4. To cope with the rapid evolution and change of the attack types, t= he DOTS solution should consider the capability of openness. Which means th= e specified information model should have the capability in semantic to def= ine and express the new attack information; 5. The whole architecture should not be constrained in our proposed s= cenarios, it can be more general, more comprehensive. For example, more dev= ices construct a mesh network to support the DOTS functions. My thoughts are: 1. I agree. We want to be inclusive on what kinds of devices may signal. = And use cases are a great way to encapsulate the problem space. Though I = would not try to extend the problem space beyond DDoS. 2. I agree. I think this is really bidirectional - I can imagine both end= s of the connection advertising capabilities. I can see the edge systems (= downstream) also advertising what they are capable of signaling and this wo= uld vary depending on the types of devices as you point out in point 1. [Frank] : Agree with the bidirectional negotiation requirement! 3. Authentication is critical to avoid the fake signaling problem you have= pointed out - I believe this received some discussion during the BOF in Da= llas.. Whatever we do with this project, It can not introduce a new DDoS ve= ctor by failing to account for this. 4. I believe all participants in the BOF would support openness for attack= type definition. But I also heard strong support for constraining the pro= blem space initially to DDoS. In fact, my opinion, as stated at the BOF, i= s that the most important component of this project is the schema. A conci= se schema that can accommodate all currently known DDoS vectors and a schem= a that is also extensible should be a primary goal for us. [Frank] :yes, you raise the key point - a concise schema also with the exte= nsibility! And I hope these two goals can be achieved all, by pre-considera= tion and good design. 5. I'm not sure I follow the suggestion of a mesh network here. Similar t= o point 4, I believe it is important to get the downstream-to-upstream sign= aling correct before complicating with mesh topology considerations. In fa= ct, to further enforce my point above, I think schema is more important tha= n topology considerations at first. I think it is critical for us to offer= something that can be tested and proven in the simplest networks that can = show the benefit. But your point about openness can not be understated - t= his must be open and extensible. [Frank] : Like you state here, what I propose here is about the topology an= d architecture aspects. I agree that this point is a little far than the sc= heme work. We can consider it later. I have copied a colleague of mine, Scott Barvick. Scott was unable to atte= nd the BOF but has been working on these concepts with me and will likely h= ave some opinions in these areas to share with the thread. [Frank] : Welcome, Scott~~ Regards, Dave Larson --_000_6073823821667642A5C884FF3A8807F81F3C7B14MERCURYcoreroco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the intro and = welcome.     From the reading of the minutes and the th= read, it seems that we can and should be using the words ‘DDoS’= and ‘signaling’  along with not overlapping with other IETF work to help us check our= activities against a focus that will allow us to get chartered as a WG and= then make the required progress towards goals that we will have as one. &n= bsp; If it is not directly contributing to the signaling of DDoS threats/conditions/capabilities then we really shoul= d really not be spending any time on it.    As examples (for= discussion, of course)

 <= /p>

-  &n= bsp;       DDoS capabilities= negotiation between the communicating parties -  in scope because it = affects what can be signaled or needs to be done on either side

-  &n= bsp;       Configuration or = provisioning of the devices for DDoS – not in scope because while it = is DDoS, it is beyond what is necessary to signal.  And we have other protocols to define the operations and even schemas for this

-  &n= bsp;       Communication of = signaling thresholds or conditions – in scope

-  &n= bsp;       Authentication of= signaling channel – in scope

-  &n= bsp;       Specific flow sta= ts and flow awareness – not in scope because it is not DDoS and there= are other protocols that represent this kind of info

-  &n= bsp;       DDoS attack repre= sentation – in-scope because it is DDoS.  Of course, if a device= can’t classify the attack because it is either not that kind of device or it is a new attack, then we need a way for this to indicate R= 16;unknown’

 <= /p>

Looking forward to good d= iscussion and the development of a good RFC.

 <= /p>

Regards,

Scott

 <= /p>

From: Xialiang= (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Tuesday, April 07, 2015 11:37 PM
To: Dave Larson; Teague, Nik; Scott Barvick
Cc: dots@ietf.org
Subject: RE: [Dots] DOTS work scope discussion: //RE: scope

 

From: Dave Larson [mailto:Dave.Larson@corero.com]
Sent: Wednesday, April 08, 2015 10:17 AM
To: Xialiang (Frank); Teague, Nik; Scott Barvick
Cc: dots@ietf.org
Subject: Re: [Dots] DOTS work scope discussion: //RE: scope

&nbs= p;

= HI Frank,

=  

= I think you raise a few vary important points below:

=  

= On Wednesday, April 1, 2015 at 1:55 AM, "Xialiang (Frank)" &= lt;frank.xial= iang@huawei.com> wrote:

=  

Here are my = thoughts about DOTS works:

1.  =      The devices ca= n be either DDoS mitigation devices, or normal network devices (router, swi= tch). This will make the whole DOTS solution more general for different scenarios. For example, current two drafts within DOTS can r= epresent this difference. Maybe, we need an use case draft to elaborate the= ir respective values;

2.  =      I agree that u= pstream systems need to negotiate its requirements or capabilities to repor= ting devices. This feature can save the signaling traffics. It means an initialized negotiation mechanism may be needed;

3.  =      A mutual authe= ntication mechanism is needed to protect the communications between the leg= al senders and receivers, to avoid the faked signaling, fault peers, or creating new DDoS attacks, etc;

4.  =      To cope with t= he rapid evolution and change of the attack types, the DOTS solution should= consider the capability of openness. Which means the specified information model should have the capability in semantic to defi= ne and express the new attack information;

5.  =      The whole arch= itecture should not be constrained in our proposed scenarios, it can be mor= e general, more comprehensive. For example, more devices construct a mesh network to support the DOTS functions.

 =

My thoughts= are:

=  

= 1.  I agree.  We want to be inclusive on what kinds of devices ma= y signal.  And use cases are a great way to encapsulate the problem space.  Though I would not try to extend the problem space beyond DDo= S.

=  

= 2.  I agree.  I think this is really bidirectional – I can = imagine both ends of the connection advertising capabilities.  I can s= ee the edge systems (downstream) also advertising what they are capable of si= gnaling and this would vary depending on the types of devices as you point = out in point 1.

[Frank] : Agree with the bidirectional negotiation requirement!

= 3.  Authentication is critical to avoid the fake signaling problem you= have pointed out – I believe this received some discussion during the BOF in Dallas.. Whatever we do with this project, It can not introduce= a new DDoS vector by failing to account for this.

=  

= 4.  I believe all participants in the BOF would support openness for a= ttack type definition.  But I also heard strong support for constraini= ng the problem space initially to DDoS.  In fact, my opinion, as stated = at the BOF, is that the most important component of this project is the sch= ema.  A concise schema that can accommodate all currently known DDoS v= ectors and a schema that is also extensible should be a primary goal for us.

[Frank] :yes, you raise the key point – a concise schema also= with the extensibility! And I hope these two goals can be achieved all, by pre-consideration and good design.

=  

= 5.  I’m not sure I follow the suggestion of a mesh network here.=  Similar to point 4, I believe it is important to get the downstream-= to-upstream signaling correct before complicating with mesh topology considerations. &= nbsp;In fact, to further enforce my point above, I think schema is more imp= ortant than topology considerations at first.  I think it is critical = for us to offer something that can be tested and proven in the simplest networks that can show the benefit.  But y= our point about openness can not be understated – this must be open a= nd extensible.

[Frank] : Like you state here, what I propose here is about the top= ology and architecture aspects. I agree that this point is a little far than the scheme work. We can consider it later.=

=  

= I have copied a colleague of mine, Scott Barvick.  Scott was unable to= attend the BOF but has been working on these concepts with me and will likely have some opinions in these areas to share with the thread= .

[Frank] : Welcome, Scott~~

=  

= Regards,

=  

= Dave Larson

=  

=  

--_000_6073823821667642A5C884FF3A8807F81F3C7B14MERCURYcoreroco_-- From nobody Wed Apr 8 08:15:12 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F561B321B for ; Wed, 8 Apr 2015 08:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4mFpasEQV_t for ; Wed, 8 Apr 2015 08:15:09 -0700 (PDT) Received: from mail-qg0-f100.google.com (mail-qg0-f100.google.com [209.85.192.100]) (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 2A4D31B31F0 for ; Wed, 8 Apr 2015 08:15:09 -0700 (PDT) Received: by qgaj5 with SMTP id j5so4884819qga.1 for ; Wed, 08 Apr 2015 08:15:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:content-id :content-transfer-encoding:mime-version; bh=y4+9DJUjnqEXTluZqsRXCxwnESo1j7xFjS32k0s+yY0=; b=JvS9Visv3yU2BQ68X74N1zODK87B0qQ074C0HjEDQcgzhVdRvb/O/1VPKfVZ1rPn0e 91Sv1Rbyb5Fvh5XvZmZxbncJUaXsw+xAV0ModwlWz3ZcGm5wA7MMHBgGdi9O4qOYCXUo uA6qVCrLuG3qML5QWSMHg9YywsWESD0i3m2WOERPg6Owc8NBYg0j9nISOxSUk3MKSFp8 S4RYO/bnMmEQX3feEVcx79dEOiNR/MI4c2KbpXzDJqcGNPHOtmGoplFVF94wslMOv9/I 6swycHWuqg8D8adaiJ9KEkIGKQA8mhdG4CPNnT9r4sXQ/Kbw4PuzF0g0yetunZJqwmgb wb/Q== X-Gm-Message-State: ALoCoQl412zG4bxGbM3vQLjOQL2k/v1irMhkH6/H6dUSDsVYh7XgnwFmm+gfYo75BAwy166sthLmvdxqh3CjvuGLoaTDhRqXEQ== X-Received: by 10.55.52.77 with SMTP id b74mr50409692qka.78.1428506108408; Wed, 08 Apr 2015 08:15:08 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id 6sm2991645qcf.1.2015.04.08.08.15.07 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 08 Apr 2015 08:15:08 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t38FF6iN011603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Apr 2015 11:15:06 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 8 Apr 2015 11:15:06 -0400 From: "Teague, Nik" To: Scott Barvick , "Xialiang (Frank)" , Dave Larson Thread-Topic: [Dots] DOTS work scope discussion: //RE: scope Thread-Index: AQHQcaIhLzQhJpbEDkS5B/rKwQEkFp1CchIQgAC3VGCAAGS6gA== Date: Wed, 8 Apr 2015 15:15:05 +0000 Message-ID: References: <6073823821667642A5C884FF3A8807F81F3C7B14@MERCURY.corero.com> In-Reply-To: <6073823821667642A5C884FF3A8807F81F3C7B14@MERCURY.corero.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <175DAAACD6738441809455AC847E6CE3@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] DOTS work scope discussion: //RE: scope X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 15:15:11 -0000 Hi, On 08/04/2015 15:36, "Scott Barvick" wrote: >- Configuration or provisioning of the devices for DDoS =AD not i= n >scope because while it is DDoS, it is beyond what is necessary to signal. > And we have other protocols to define the operations and even schemas >for this I agree that configuration/provisioning of the device itself is out of scope - I would say that provisioning the service (auth, whitelist, blacklist, crypto negotiations, collector addr etc.) are in scope. These are all elements that relate to the ephemeral service state as it pertains to the relationship between the signaling element and the consuming element. Thanks, -Nik From nobody Wed Apr 8 08:20:39 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FEF1B3254 for ; Wed, 8 Apr 2015 08:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU00Te2WSVml for ; Wed, 8 Apr 2015 08:20:35 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (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 63F0A1B323C for ; Wed, 8 Apr 2015 08:20:34 -0700 (PDT) Received: by wgyo15 with SMTP id o15so81037946wgy.2 for ; Wed, 08 Apr 2015 08:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4+yEXanhxA0gfzOOb3Rc5E0wp+noDARmZuQHlINymzI=; b=fQC1kOYZUx1CZkdK/hjbEuoaBRtH5NqrY5PUo/OzIpl2nhHBz48gqVioKNOaB7+HB+ oCRSyINe+yZ6TPoQBJv+/yLccyhA8NjaUkJjwNP2hXl6RE1XXSRWZ4j9DlBTWnwqcoBq lRdMsdE0cTF/ALTkRLPrdhsBBfyDY06eGQplwimVrHufC0ECz9heQ0kZOxPlvbL9zlgf 09bUiHmllxr1R1ux18prR+9B0IdV8yQ0Sd2hGXT8YmNUkj9gi4HlWGRhNnNWb8jcLi0k l2aXPtmr2HPntF/DXsoRZpeq8/y1SG7nAZSPMlu66E9mwO4TdwMJ4Unbrj33gZFQvfgY kx8Q== MIME-Version: 1.0 X-Received: by 10.180.23.99 with SMTP id l3mr15293321wif.25.1428506433000; Wed, 08 Apr 2015 08:20:33 -0700 (PDT) Received: by 10.194.5.97 with HTTP; Wed, 8 Apr 2015 08:20:32 -0700 (PDT) In-Reply-To: <6073823821667642A5C884FF3A8807F81F3C7B14@MERCURY.corero.com> References: <6073823821667642A5C884FF3A8807F81F3C7B14@MERCURY.corero.com> Date: Wed, 8 Apr 2015 11:20:32 -0400 Message-ID: From: Daniel Migault To: Scott Barvick Content-Type: multipart/alternative; boundary=001a113429107f97a405133812bd Archived-At: Cc: "Teague, Nik" , "Xialiang \(Frank\)" , Dave Larson , "dots@ietf.org" Subject: Re: [Dots] DOTS work scope discussion: //RE: scope X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 15:20:38 -0000 --001a113429107f97a405133812bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Scott, It is not very clear to me what is in "Configuration or provisioning" and what is in "Communication of signaling thresholds or conditions". [BTW feel free to provide more appropriated terms] Suppose I have a "DDoS Mitigation Device". I would like to use DOTS to: 1) Be aware of the device capabilities, that is to say what services the device can provide. By capabilities I see the following categories of capabilities: + a) Monitoring Capabilities + b) Mitigating Capabilities Monitoring Capabilities consists in being able to look at specific traffic characteristics or patterns. Examples could be Monitoring FQDNs of DNS NXDOMAIN responses, IP source of DNS NXDOMAIN responses, IP destination of TCP SYN.... [MGLT It is still not clear what should be the level of granularity a capability should be associated to] For each of these Monitoring Capabilities some Monitoring actions could be associated. The two type of actions I see would be: trigger an alarm when a define threshold has been reached or export the traffic to some directory. [MGLT I seen these action associated to Monitoring Capabilities, but maybe it could be as well itself a capability] Mitigating Capabilities consists in blocking IP, applying white list black lists of IP addresses FQDNs, redirecting traffic...... Once I am aware of the capabilities of the "DDoS Mitigation Device" I would like to 2) be able to select these Monitoring Capabilities and set the appropriated Monitoring Action. This to some extend could be seen a configuration of the DDoS service, but I expect it to be part of DOTS. Once an alarm is raised or I am informed an DDoS attacks occurs I would like to 3) be able to take the appropriated Mitigation Action. BR, Daniel On Wed, Apr 8, 2015 at 10:36 AM, Scott Barvick wrote: > Thanks for the intro and welcome. From the reading of the minutes > and the thread, it seems that we can and should be using the words =E2=80= =98DDoS=E2=80=99 > and =E2=80=98signaling=E2=80=99 along with not overlapping with other IE= TF work to help us > check our activities against a focus that will allow us to get chartered = as > a WG and then make the required progress towards goals that we will have = as > one. If it is not directly contributing to the signaling of DDoS > threats/conditions/capabilities then we really should really not be > spending any time on it. As examples (for discussion, of course) > > > > - DDoS capabilities negotiation between the communicating > parties - in scope because it affects what can be signaled or needs to b= e > done on either side > > - Configuration or provisioning of the devices for DDoS =E2=80= =93 not in > scope because while it is DDoS, it is beyond what is necessary to signal. > And we have other protocols to define the operations and even schemas for > this > > - Communication of signaling thresholds or conditions =E2=80=93 = in scope > > - Authentication of signaling channel =E2=80=93 in scope > > - Specific flow stats and flow awareness =E2=80=93 not in scope = because > it is not DDoS and there are other protocols that represent this kind of > info > > - DDoS attack representation =E2=80=93 in-scope because it is DD= oS. Of > course, if a device can=E2=80=99t classify the attack because it is eithe= r not that > kind of device or it is a new attack, then we need a way for this to > indicate =E2=80=98unknown=E2=80=99 > > > > Looking forward to good discussion and the development of a good RFC. > > > > Regards, > > Scott > > > > *From:* Xialiang (Frank) [mailto:frank.xialiang@huawei.com] > *Sent:* Tuesday, April 07, 2015 11:37 PM > *To:* Dave Larson; Teague, Nik; Scott Barvick > *Cc:* dots@ietf.org > *Subject:* RE: [Dots] DOTS work scope discussion: //RE: scope > > > > Hi Dave, > > I totally agree with you the point that focus DOTS=E2=80=99s scope on DDo= S in the > first stage. It=E2=80=99s a reasonable way we push the WG work. > > Please see my response inline: > > > > B.R. > > Frank > > > > *From:* Dave Larson [mailto:Dave.Larson@corero.com > ] > *Sent:* Wednesday, April 08, 2015 10:17 AM > *To:* Xialiang (Frank); Teague, Nik; Scott Barvick > *Cc:* dots@ietf.org > *Subject:* Re: [Dots] DOTS work scope discussion: //RE: scope > > > > HI Frank, > > > > I think you raise a few vary important points below: > > > > On Wednesday, April 1, 2015 at 1:55 AM, "Xialiang (Frank)" < > frank.xialiang@huawei.com> wrote: > > > > Here are my thoughts about DOTS works: > > 1. The devices can be either DDoS mitigation devices, or normal > network devices (router, switch). This will make the whole DOTS solution > more general for different scenarios. For example, current two drafts > within DOTS can represent this difference. Maybe, we need an use case dra= ft > to elaborate their respective values; > > 2. I agree that upstream systems need to negotiate its requirements > or capabilities to reporting devices. This feature can save the signaling > traffics. It means an initialized negotiation mechanism may be needed; > > 3. A mutual authentication mechanism is needed to protect the > communications between the legal senders and receivers, to avoid the fake= d > signaling, fault peers, or creating new DDoS attacks, etc; > > 4. To cope with the rapid evolution and change of the attack types, > the DOTS solution should consider the capability of openness. Which means > the specified information model should have the capability in semantic to > define and express the new attack information; > > 5. The whole architecture should not be constrained in our proposed > scenarios, it can be more general, more comprehensive. For example, more > devices construct a mesh network to support the DOTS functions. > > > > My thoughts are: > > > > 1. I agree. We want to be inclusive on what kinds of devices may > signal. And use cases are a great way to encapsulate the problem space. > Though I would not try to extend the problem space beyond DDoS. > > > > 2. I agree. I think this is really bidirectional =E2=80=93 I can imagin= e both > ends of the connection advertising capabilities. I can see the edge > systems (downstream) also advertising what they are capable of signaling > and this would vary depending on the types of devices as you point out in > point 1. > > *[Frank] : Agree with the bidirectional negotiation requirement!* > > > > 3. Authentication is critical to avoid the fake signaling problem you > have pointed out =E2=80=93 I believe this received some discussion during= the BOF > in Dallas.. Whatever we do with this project, It can not introduce a new > DDoS vector by failing to account for this. > > > > 4. I believe all participants in the BOF would support openness for > attack type definition. But I also heard strong support for constraining > the problem space initially to DDoS. In fact, my opinion, as stated at t= he > BOF, is that the most important component of this project is the schema. = A > concise schema that can accommodate all currently known DDoS vectors and = a > schema that is also extensible should be a primary goal for us. > > *[Frank] :yes, you raise the key point =E2=80=93 a concise schema also wi= th the > extensibility! And I hope these two goals can be achieved all, by > pre-consideration and good design.* > > > > 5. I=E2=80=99m not sure I follow the suggestion of a mesh network here. = Similar > to point 4, I believe it is important to get the downstream-to-upstream > signaling correct before complicating with mesh topology considerations. > In fact, to further enforce my point above, I think schema is more > important than topology considerations at first. I think it is critical > for us to offer something that can be tested and proven in the simplest > networks that can show the benefit. But your point about openness can no= t > be understated =E2=80=93 this must be open and extensible. > > *[Frank] : Like you state here, what I propose here is about the topology > and architecture aspects. I agree that this point is a little far than th= e > scheme work. We can consider it later.* > > > > I have copied a colleague of mine, Scott Barvick. Scott was unable to > attend the BOF but has been working on these concepts with me and will > likely have some opinions in these areas to share with the thread. > > *[Frank] : Welcome, Scott~~* > > > > Regards, > > > > Dave Larson > > > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > --=20 Daniel Migault Ericsson --001a113429107f97a405133812bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Scott,

It is not very clear to m= e what is in "Configuration or provisioning" and what is in "= ;Communication of signaling thresholds or conditions".

[BTW feel free to provide more appropriated terms]


Suppose I have a "DDoS Mitigation Device".
I would like to u= se DOTS to:
=C2=A0 =C2=A0 1) Be aware of the device capabilit= ies, that is to say what services the device can provide. By capabilities I= see the following categories of capabilities:
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 + a) Monitoring Capabilities
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 + b) Mitigating Capabilities
=

Monitoring Capabilities consists in being able to look at sp= ecific traffic characteristics or patterns. Examples could be Monitoring FQ= DNs of DNS NXDOMAIN responses, IP source of DNS NXDOMAIN responses, IP dest= ination of TCP SYN....

[MGLT It is still not clear what should be t= he level of granularity a capability should be associated to]
For each of these Monitoring Capabilities some Monitoring actions could be= associated. The two type of actions I see would be: trigger an alarm when = a define threshold has been reached or export the traffic to some directory= .

[MGLT I seen these action associated to Monitoring Capa= bilities, but maybe it could be as well itself a capability]=C2=A0 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

Mitigating Cap= abilities consists in blocking IP, applying white list black lists of IP ad= dresses FQDNs, redirecting traffic......

=C2=A0
Once I am a= ware of the capabilities of the "DDoS Mitigation Device" I would = like to
=C2=A0=C2=A0=C2=A0 2)=C2=A0 be able to select these Monitor= ing Capabilities and set the appropriated Monitoring Action. This to some e= xtend could be seen a configuration of the DDoS service, but I expect it to= be part of DOTS.

Once an alarm is raised or I am informe= d an DDoS attacks occurs I would like to
=C2=A0=C2=A0 3) be = able to take the appropriated Mitigation Action.
=C2=A0
=
BR,
Daniel

=C2=A0



On Wed, Apr 8= , 2015 at 10:36 AM, Scott Barvick <Scott.Barvick@corero.com>= wrote:

Thanks for the intro and = welcome.=C2=A0=C2=A0 =C2=A0=C2=A0From the reading of the minutes and the th= read, it seems that we can and should be using the words =E2=80=98DDoS=E2= =80=99 and =E2=80=98signaling=E2=80=99 =C2=A0along with not overlapping with other IETF work to help us check our= activities against a focus that will allow us to get chartered as a WG and= then make the required progress towards goals that we will have as one. = =C2=A0=C2=A0If it is not directly contributing to the signaling of DDoS threats/conditions/capabilities then we really shoul= d really not be spending any time on it.=C2=A0=C2=A0=C2=A0 As examples (for= discussion, of course)

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DDoS capabilities ne= gotiation between the communicating parties - =C2=A0in scope because it aff= ects what can be signaled or needs to be done on either side

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Configuration or pro= visioning of the devices for DDoS =E2=80=93 not in scope because while it i= s DDoS, it is beyond what is necessary to signal.=C2=A0 And we have other protocols to define the operations and even schemas for this =

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Communication of sig= naling thresholds or conditions =E2=80=93 in scope

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authentication of si= gnaling channel =E2=80=93 in scope

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Specific flow stats = and flow awareness =E2=80=93 not in scope because it is not DDoS and there = are other protocols that represent this kind of info

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DDoS attack represen= tation =E2=80=93 in-scope because it is DDoS.=C2=A0 Of course, if a device = can=E2=80=99t classify the attack because it is either not that kind of device or it is a new attack, then we need a way for this to indicate =E2= =80=98unknown=E2=80=99

=C2=A0

Looking forward to good d= iscussion and the development of a good RFC.

=C2=A0

Regards,

Scott

=C2=A0

From: Xialiang= (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Tuesday, April 07, 2015 11:37 PM
To: Dave Larson; Teague, Nik; Scott Barvick
Cc: dots@ietf.org=
Subject: RE: [Dots] DOTS work scope discussion: //RE: scope

=C2=A0

Hi Dave,

I totally agree with you = the point that focus DOTS=E2=80=99s scope on DDoS in the first stage. It=E2= =80=99s a reasonable way we push the WG work.

Please see my response in= line:

=C2=A0

B.R.=

Frank

=C2=A0

From: Dave Lar= son [mailto:Dav= e.Larson@corero.com]
Sent: Wednesday, April 08, 2015 10:17 AM
To: Xialiang (Frank); Teague, Nik; Scott Barvick
Cc: dots@ietf.org=
Subject: Re: [Dots] DOTS work scope discussion: //RE: scope

=C2=A0

HI Frank,

=C2=A0=

I think you raise a few var= y important points below:

=C2=A0=

On Wednesday, April 1, 2015= at 1:55 AM,=C2=A0"Xialiang (Frank)" <frank.xialiang@huawei.com> wrote:

=C2=A0=

Here are my thoughts abou= t DOTS works:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The devices can be either DDoS mitigation= devices, or normal network devices (router, switch). This will make the wh= ole DOTS solution more general for different scenarios. For example, current two drafts within DOTS can r= epresent this difference. Maybe, we need an use case draft to elaborate the= ir respective values;<= /p>

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I agree that upstream systems need to neg= otiate its requirements or capabilities to reporting devices. This feature = can save the signaling traffics. It means an initialized negotiation mechanism may be needed;

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A mutual authentication mechanism is need= ed to protect the communications between the legal senders and receivers, t= o avoid the faked signaling, fault peers, or creating new DDoS attacks, etc;

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 To cope with the rapid evolution and chan= ge of the attack types, the DOTS solution should consider the capability of= openness. Which means the specified information model should have the capability in semantic to defi= ne and express the new attack information;<= u>

5.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The whole architecture should not be cons= trained in our proposed scenarios, it can be more general, more comprehensi= ve. For example, more devices construct a mesh network to support the DOTS functions.

=C2=A0

My thoughts are:<= u>

=C2=A0=

1.=C2=A0 I agree.=C2=A0 We = want to be inclusive on what kinds of devices may signal.=C2=A0 And use cas= es are a great way to encapsulate the problem space.=C2=A0 Though I would not try to extend the problem space beyond DDo= S.

=C2=A0=

2.=C2=A0 I agree.=C2=A0 I t= hink this is really bidirectional =E2=80=93 I can imagine both ends of the = connection advertising capabilities.=C2=A0 I can see the edge systems (downstream) also advertising what they are capable of si= gnaling and this would vary depending on the types of devices as you point = out in point 1.

[Frank] : Agree wit= h the bidirectional negotiation requirement!

=C2=A0

3.=C2=A0 Authentication is = critical to avoid the fake signaling problem you have pointed out =E2=80=93= I believe this received some discussion during the BOF in Dallas.. Whatever we do with this project, It can not introduce= a new DDoS vector by failing to account for this.

=C2=A0=

4.=C2=A0 I believe all part= icipants in the BOF would support openness for attack type definition.=C2= =A0 But I also heard strong support for constraining the problem space initially to DDoS.=C2=A0 In fact, my opinion, as stated = at the BOF, is that the most important component of this project is the sch= ema.=C2=A0 A concise schema that can accommodate all currently known DDoS v= ectors and a schema that is also extensible should be a primary goal for us.

[Frank] :yes, you r= aise the key point =E2=80=93 a concise schema also with the extensibility! = And I hope these two goals can be achieved all, by pre-consideration and good design.

=C2=A0=

5.=C2=A0 I=E2=80=99m not su= re I follow the suggestion of a mesh network here.=C2=A0 Similar to point 4= , I believe it is important to get the downstream-to-upstream signaling correct before complicating with mesh topology considerations.= =C2=A0 In fact, to further enforce my point above, I think schema is more i= mportant than topology considerations at first.=C2=A0 I think it is critica= l for us to offer something that can be tested and proven in the simplest networks that can show the benefit.=C2=A0 But y= our point about openness can not be understated =E2=80=93 this must be open= and extensible.

[Frank] : Like you = state here, what I propose here is about the topology and architecture aspe= cts. I agree that this point is a little far than the scheme work. We can consider it later.=

=C2=A0=

I have copied a colleague o= f mine, Scott Barvick.=C2=A0 Scott was unable to attend the BOF but has bee= n working on these concepts with me and will likely have some opinions in these areas to share with the thread= .

[Frank] : Welcome, = Scott~~

=C2=A0=

Regards,

=C2=A0=

Dave Larson

=C2=A0=

=C2=A0=


_______________________________________________
Dots mailing list
Dots@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dots




--
Daniel Migault
Ericsson
--001a113429107f97a405133812bd-- From nobody Wed Apr 8 08:32:19 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CF11B32A5 for ; Wed, 8 Apr 2015 08:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hvRY1zmAJpk for ; Wed, 8 Apr 2015 08:32:15 -0700 (PDT) Received: from mail-qg0-f100.google.com (mail-qg0-f100.google.com [209.85.192.100]) (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 256A81B3275 for ; Wed, 8 Apr 2015 08:32:15 -0700 (PDT) Received: by qgdz60 with SMTP id z60so4915675qgd.0 for ; Wed, 08 Apr 2015 08:32:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:content-id :content-transfer-encoding:mime-version; bh=sgjrFGXkNXrXRxfN8TJVIILct/T1Ny3IsrqD7VPKJpU=; b=OjqyBduGkQdxzqtnN1OWh1hG/sq8QWkaUEOi+Pf8ZW/RK0liWz5oHs+OfvZf+fOuj8 Aehdo2bLAiZpDs8lQ99acP3gR6+5OInhEJ/cwUPq9m3VuYBBZ7huPpSvkkKJsDNBnJq/ Bh5zi4k6cA5+citDb/IArQSA5UnjAjeMrK+EOEZQGXQdnz4r1ZLvOg45f2o+wtuSpSs8 m/70AR5dzzxnOkEaSO71OCOAXAhrCkg+CCvt94YWU8NSP3dqc2sOdnb2e/tJSMhE2xc7 /P5Uz2BQ03aksSDAlHrwMGIKCGrM5+qPUh8pBb1pvXy4mCyJ4Hs0Nexvo/oSdxlAN2ha FKzQ== X-Gm-Message-State: ALoCoQnUwNunJv36k33q++fCKN7HhghJXBM/DmQchDOfjT2cMnEoqN1XyP7YiZ9tELNw1Kfz7ynx4fK185L26XVD3sNpXtX9Gg== X-Received: by 10.140.47.1 with SMTP id l1mr29781517qga.44.1428507134317; Wed, 08 Apr 2015 08:32:14 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id y7sm1993386qci.3.2015.04.08.08.32.13 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 08 Apr 2015 08:32:14 -0700 (PDT) X-Relaying-Domain: verisign.com 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 t38FWDS5021224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Apr 2015 11:32:13 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 8 Apr 2015 11:32:13 -0400 From: "Teague, Nik" To: Linda Dunbar , "dots@ietf.org" Thread-Topic: scope Thread-Index: AQHQa8ImfNQMx27PokCfZQ+6rvOaCp04aHXggAs2MwA= Date: Wed, 8 Apr 2015 15:32:12 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657BFF946@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657BFF946@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <59ABE2FF5274E242B97313182603819B@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "i2nsf@ietf.org" Subject: Re: [Dots] scope X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 15:32:18 -0000 Hi, On 01/04/2015 13:31, "Linda Dunbar" wrote: >Nik, > >=20 >Can you elaborate a bit more on the =B3peacetime provisioning channel=B2? > >=20 >What kind of =B3configuration data=B2 is exchanged on over this channel? W= hat >protocol? Is it NETCONF? The term peacetime is somewhat fuzzy and I keep trying out variations that feel/describe better. The intent of the channel is the exchange of information that relates to the service setup/provisioning and not to the actual signaling - This could be authentication, key/token exchanges, whitelist, megaproxy lists etc. In addition this could be the describing of capabilities (some devices/applications may only monitor while others may have a mitigation capability). As far as the protocol - I had thought JSON RPC API over HTTPS - its reasonably light to implement (anything with access to cURL can take advantage of it. It also means little to no re-tooling across many DDoS mitigation platforms which may be *nix based at their core. > >=20 >In parallel to DOTS, there is the I2NSF initiative intended for >specifying the security policies to security functions (primarily the >flow based security functions). > >https://datatracker.ietf.org/doc/draft-lopez-i2nsf-packet/ has identified >three types interfaces to security functions: > >=80 =20 >Configuration >=AD =20 >Device configuration >=AD =20 >Network configuration >=80 =20 >Signaling >=AD =20 >Status >=AD =20 >Counters >=AD =20 >Queries >=AD =20 >Alerts >=80 =20 >Provisioning >=AD =20 >Capabilities >=AD =20 >Policy >=AD =20 >Object Configuration > >=20 >=20 >I2NSF will focus on the 3rd bullet, i.e. the Provisioning part. > >=20 >Just want to see if the provisioning you mentioned could provide the >synergy to I2NSF=B9s provisioning. >=20 >Thanks, > >Linda I would suggest that the device provisioning is already assumed to have happened and the provisioning we discuss here relates to the service. I think there is some potential overlap (filter lists of whatever type) and its worth investigating and identifying where this occurs and what to leverage in that event. Thanks, -Nik From nobody Wed Apr 8 08:42:26 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473F81B324C for ; Wed, 8 Apr 2015 08:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-bPYhcWoVku for ; Wed, 8 Apr 2015 08:42:20 -0700 (PDT) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (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 874371A87A9 for ; Wed, 8 Apr 2015 08:42:09 -0700 (PDT) Received: by ignm3 with SMTP id m3so31736571ign.0 for ; Wed, 08 Apr 2015 08:42:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=6+IYRmnRYmvvqSxgTrxtchlliWKWebnq5K6qI7gOZpA=; b=I2d4Cc1SNoLmx8F037HR4SRgLekcCo/PiUMUMZ55V2EovQEfhJ22uAi3iYPx4Lsd/O gtKrI+jv0UQJzSFbQ1dbwU1wAICiTbUQMCoqcW6lS+cBQ79BVrKQjGciKacWlq1KVEfS wmMH6EFZ2I7Zj9pUayJFmlnvB1a+1cBIqM1kz4UWbrbfbc5xjxKml4DGv8zqQGQ4A2Mw S/waJa/6kdI/A6AMqB5duzCxLbjEECioJ7DzaK57A8i/PhchJiba8L1lAcSrcQ26GEG7 U89m1OGNSTt5vntoS5ochqKrdxe6yHf7dauIPhelGFNSXMzWXSbLPhcsRx1LvVDOwEwZ HMhQ== X-Gm-Message-State: ALoCoQkbhsk2gBN1/vZFqf/WLgHW0mrRMIgccB7kEGz2haOUxiL0THjNhtwWzvYbdlP7w78olwHa X-Received: by 10.107.162.147 with SMTP id l141mr1321796ioe.77.1428507728589; Wed, 08 Apr 2015 08:42:08 -0700 (PDT) Received: from localhost.localdomain ([2001:428:1:1:2e0:81ff:fe5c:efd5]) by mx.google.com with ESMTPSA id pl4sm6993932igb.22.2015.04.08.08.42.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2015 08:42:06 -0700 (PDT) Message-ID: <55254C4D.1020608@flowtools.net> Date: Wed, 08 Apr 2015 09:42:05 -0600 From: John User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dots@ietf.org References: <6073823821667642A5C884FF3A8807F81F3C7B14@MERCURY.corero.com> In-Reply-To: <6073823821667642A5C884FF3A8807F81F3C7B14@MERCURY.corero.com> Content-Type: multipart/alternative; boundary="------------040703050908090507030604" Archived-At: Subject: Re: [Dots] DOTS work scope discussion: //RE: scope X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 15:42:25 -0000 This is a multi-part message in MIME format. --------------040703050908090507030604 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello, Sorry I'm late to this discussion but I've recently learned of this effort and I'm very interested in the topic. If my questions have already been addressed and I missed where this was previously discussed, I'm apologize for raising the issue again and I would appreciate being directed to where the question was answered or discussed. Please see inline. On 04/08/2015 08:36 AM, Scott Barvick wrote: > > Thanks for the intro and welcome. From the reading of the minutes > and the thread, it seems that we can and should be using the words > ‘DDoS’ and ‘signaling’ along with not overlapping with other IETF > work to help us check our activities against a focus that will allow > us to get chartered as a WG and then make the required progress > towards goals that we will have as one. If it is not directly > contributing to the signaling of DDoS threats/conditions/capabilities > then we really should really not be spending any time on it. As > examples (for discussion, of course) > > -DDoS capabilities negotiation between the communicating parties - in > scope because it affects what can be signaled or needs to be done on > either side > > -Configuration or provisioning of the devices for DDoS – not in scope > because while it is DDoS, it is beyond what is necessary to signal. > And we have other protocols to define the operations and even schemas > for this > > -Communication of signaling thresholds or conditions – in scope > > -Authentication of signaling channel – in scope > Authentication is in scope, I would suggest it's required to participate. > > -Specific flow stats and flow awareness – not in scope because it is > not DDoS and there are other protocols that represent this kind of info > I kind of see this item as going along with Communication of signaling thresholds mentioned above. How do you know you are not surpassing or taking full advantage of mitigation without knowing if you are at, near, or above the signaling thresholds? Could you share what current protocols you are referring to? > -DDoS attack representation – in-scope because it is DDoS. Of course, > if a device can’t classify the attack because it is either not that > kind of device or it is a new attack, then we need a way for this to > indicate ‘unknown’ > Verification. This ,so far, is a two part issue. * As part of authentication, we need some way to verify the authenticating parties and agree upon authentication methods. * How do I verify the DDoS parameters defined downstream are applicable and valid? What's in place to prevent a CPE from sending invalid DDoS representation? The CPE could have been compromised or the owner of the CPE may try to send data that falsely blames a competitor and thus ends up allowing for a DoS of said competitor. Thanks, --John Schiel > Looking forward to good discussion and the development of a good RFC. > > Regards, > > Scott > > *From:*Xialiang (Frank) [mailto:frank.xialiang@huawei.com] > *Sent:* Tuesday, April 07, 2015 11:37 PM > *To:* Dave Larson; Teague, Nik; Scott Barvick > *Cc:* dots@ietf.org > *Subject:* RE: [Dots] DOTS work scope discussion: //RE: scope > > Hi Dave, > > I totally agree with you the point that focus DOTS’s scope on DDoS in > the first stage. It’s a reasonable way we push the WG work. > > Please see my response inline: > > B.R. > > Frank > > *From:*Dave Larson [mailto:Dave.Larson@corero.com] > *Sent:* Wednesday, April 08, 2015 10:17 AM > *To:* Xialiang (Frank); Teague, Nik; Scott Barvick > *Cc:* dots@ietf.org > *Subject:* Re: [Dots] DOTS work scope discussion: //RE: scope > > HI Frank, > > I think you raise a few vary important points below: > > On Wednesday, April 1, 2015 at 1:55 AM, "Xialiang (Frank)" > > wrote: > > Here are my thoughts about DOTS works: > > 1.The devices can be either DDoS mitigation devices, or normal > network devices (router, switch). This will make the whole DOTS > solution more general for different scenarios. For example, > current two drafts within DOTS can represent this difference. > Maybe, we need an use case draft to elaborate their respective values; > > 2.I agree that upstream systems need to negotiate its requirements > or capabilities to reporting devices. This feature can save the > signaling traffics. It means an initialized negotiation mechanism > may be needed; > > 3.A mutual authentication mechanism is needed to protect the > communications between the legal senders and receivers, to avoid > the faked signaling, fault peers, or creating new DDoS attacks, etc; > > 4.To cope with the rapid evolution and change of the attack types, > the DOTS solution should consider the capability of openness. > Which means the specified information model should have the > capability in semantic to define and express the new attack > information; > > 5.The whole architecture should not be constrained in our proposed > scenarios, it can be more general, more comprehensive. For > example, more devices construct a mesh network to support the DOTS > functions. > > My thoughts are: > > 1. I agree. We want to be inclusive on what kinds of devices may > signal. And use cases are a great way to encapsulate the problem > space. Though I would not try to extend the problem space beyond DDoS. > > 2. I agree. I think this is really bidirectional – I can imagine > both ends of the connection advertising capabilities. I can see the > edge systems (downstream) also advertising what they are capable of > signaling and this would vary depending on the types of devices as you > point out in point 1. > > */[Frank] : Agree with the bidirectional negotiation requirement!/* > > 3. Authentication is critical to avoid the fake signaling problem you > have pointed out – I believe this received some discussion during the > BOF in Dallas.. Whatever we do with this project, It can not introduce > a new DDoS vector by failing to account for this. > > 4. I believe all participants in the BOF would support openness for > attack type definition. But I also heard strong support for > constraining the problem space initially to DDoS. In fact, my > opinion, as stated at the BOF, is that the most important component of > this project is the schema. A concise schema that can accommodate all > currently known DDoS vectors and a schema that is also extensible > should be a primary goal for us. > > */[Frank] :yes, you raise the key point – a concise schema also with > the extensibility! And I hope these two goals can be achieved all, by > pre-consideration and good design./* > > 5. I’m not sure I follow the suggestion of a mesh network here. > Similar to point 4, I believe it is important to get the > downstream-to-upstream signaling correct before complicating with mesh > topology considerations. In fact, to further enforce my point above, > I think schema is more important than topology considerations at > first. I think it is critical for us to offer something that can be > tested and proven in the simplest networks that can show the benefit. > But your point about openness can not be understated – this must be > open and extensible. > > */[Frank] : Like you state here, what I propose here is about the > topology and architecture aspects. I agree that this point is a little > far than the scheme work. We can consider it later./* > > I have copied a colleague of mine, Scott Barvick. Scott was unable to > attend the BOF but has been working on these concepts with me and will > likely have some opinions in these areas to share with the thread. > > */[Frank] : Welcome, Scott~~/* > > Regards, > > Dave Larson > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------040703050908090507030604 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hello,

    Sorry I'm late to this discussion but I've recently learned of this effort and I'm very interested in the topic. If my questions have already been addressed and I missed where this was previously discussed, I'm apologize for raising the issue again and I would appreciate being directed to where the question was answered or discussed.

Please see inline.

On 04/08/2015 08:36 AM, Scott Barvick wrote:

Thanks for the intro and welcome.     From the reading of the minutes and the thread, it seems that we can and should be using the words ‘DDoS’ and ‘signaling’  along with not overlapping with other IETF work to help us check our activities against a focus that will allow us to get chartered as a WG and then make the required progress towards goals that we will have as one.   If it is not directly contributing to the signaling of DDoS threats/conditions/capabilities then we really should really not be spending any time on it.    As examples (for discussion, of course)

 

-          DDoS capabilities negotiation between the communicating parties -  in scope because it affects what can be signaled or needs to be done on either side

-          Configuration or provisioning of the devices for DDoS – not in scope because while it is DDoS, it is beyond what is necessary to signal.  And we have other protocols to define the operations and even schemas for this

-          Communication of signaling thresholds or conditions – in scope

-          Authentication of signaling channel – in scope

    Authentication is in scope, I would suggest it's required to participate.

-          Specific flow stats and flow awareness – not in scope because it is not DDoS and there are other protocols that represent this kind of info

    I kind of see this item as going along with Communication of signaling thresholds mentioned above. How do you know you are not surpassing or taking full advantage of mitigation without knowing if you are at, near, or above the signaling thresholds?

    Could you share what current protocols you are referring to?

-          DDoS attack representation – in-scope because it is DDoS.  Of course, if a device can’t classify the attack because it is either not that kind of device or it is a new attack, then we need a way for this to indicate ‘unknown’

    Verification. This ,so far, is a two part issue.
            * As part of authentication, we need some way to verify the authenticating parties and agree upon authentication methods.
            * How do I verify the DDoS parameters defined downstream are applicable and valid? What's in place to prevent a CPE from sending invalid DDoS representation? The CPE could have been compromised or the owner of the CPE may try to send data that falsely blames a competitor and thus ends up allowing for a DoS of said competitor.

Thanks,

--John Schiel
 

 

Looking forward to good discussion and the development of a good RFC.

 

Regards,

Scott

 

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Tuesday, April 07, 2015 11:37 PM
To: Dave Larson; Teague, Nik; Scott Barvick
Cc: dots@ietf.org
Subject: RE: [Dots] DOTS work scope discussion: //RE: scope

 

Hi Dave,

I totally agree with you the point that focus DOTS’s scope on DDoS in the first stage. It’s a reasonable way we push the WG work.

Please see my response inline:

 

B.R.

Frank

 

From: Dave Larson [mailto:Dave.Larson@corero.com]
Sent: Wednesday, April 08, 2015 10:17 AM
To: Xialiang (Frank); Teague, Nik; Scott Barvick
Cc: dots@ietf.org
Subject: Re: [Dots] DOTS work scope discussion: //RE: scope

 

HI Frank,

 

I think you raise a few vary important points below:

 

On Wednesday, April 1, 2015 at 1:55 AM, "Xialiang (Frank)" <frank.xialiang@huawei.com> wrote:

 

Here are my thoughts about DOTS works:

1.       The devices can be either DDoS mitigation devices, or normal network devices (router, switch). This will make the whole DOTS solution more general for different scenarios. For example, current two drafts within DOTS can represent this difference. Maybe, we need an use case draft to elaborate their respective values;

2.       I agree that upstream systems need to negotiate its requirements or capabilities to reporting devices. This feature can save the signaling traffics. It means an initialized negotiation mechanism may be needed;

3.       A mutual authentication mechanism is needed to protect the communications between the legal senders and receivers, to avoid the faked signaling, fault peers, or creating new DDoS attacks, etc;

4.       To cope with the rapid evolution and change of the attack types, the DOTS solution should consider the capability of openness. Which means the specified information model should have the capability in semantic to define and express the new attack information;

5.       The whole architecture should not be constrained in our proposed scenarios, it can be more general, more comprehensive. For example, more devices construct a mesh network to support the DOTS functions.

 

My thoughts are:

 

1.  I agree.  We want to be inclusive on what kinds of devices may signal.  And use cases are a great way to encapsulate the problem space.  Though I would not try to extend the problem space beyond DDoS.

 

2.  I agree.  I think this is really bidirectional – I can imagine both ends of the connection advertising capabilities.  I can see the edge systems (downstream) also advertising what they are capable of signaling and this would vary depending on the types of devices as you point out in point 1.

[Frank] : Agree with the bidirectional negotiation requirement!

 

3.  Authentication is critical to avoid the fake signaling problem you have pointed out – I believe this received some discussion during the BOF in Dallas.. Whatever we do with this project, It can not introduce a new DDoS vector by failing to account for this.

 

4.  I believe all participants in the BOF would support openness for attack type definition.  But I also heard strong support for constraining the problem space initially to DDoS.  In fact, my opinion, as stated at the BOF, is that the most important component of this project is the schema.  A concise schema that can accommodate all currently known DDoS vectors and a schema that is also extensible should be a primary goal for us.

[Frank] :yes, you raise the key point – a concise schema also with the extensibility! And I hope these two goals can be achieved all, by pre-consideration and good design.

 

5.  I’m not sure I follow the suggestion of a mesh network here.  Similar to point 4, I believe it is important to get the downstream-to-upstream signaling correct before complicating with mesh topology considerations.  In fact, to further enforce my point above, I think schema is more important than topology considerations at first.  I think it is critical for us to offer something that can be tested and proven in the simplest networks that can show the benefit.  But your point about openness can not be understated – this must be open and extensible.

[Frank] : Like you state here, what I propose here is about the topology and architecture aspects. I agree that this point is a little far than the scheme work. We can consider it later.

 

I have copied a colleague of mine, Scott Barvick.  Scott was unable to attend the BOF but has been working on these concepts with me and will likely have some opinions in these areas to share with the thread.

[Frank] : Welcome, Scott~~

 

Regards,

 

Dave Larson

 

 



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

--------------040703050908090507030604-- From nobody Wed Apr 8 10:56:34 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FA91A8899 for ; Wed, 8 Apr 2015 10:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhGoA9uI3y5V for ; Wed, 8 Apr 2015 10:56:30 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16D91A8896 for ; Wed, 8 Apr 2015 10:56:30 -0700 (PDT) Received: by iejt8 with SMTP id t8so9056929iej.2 for ; Wed, 08 Apr 2015 10:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=38NlZahBsOfPvL0AGnUaiJ8CTXwp7YAEOJR+9K49KVQ=; b=Bm6sYqpbp8+KQfweLK4U4iOm9VRCOy4OGsBMSsR8xGGXp7kTtQxqnFWF40m4MV+PDu QxUjXOIq2A5e7cB1plwmy8DWjCYdLCSVwzPBS3BibKsGtnX+MAW3eQ2f0t93XOBHc09e /tmHen+kDYLGHjMKBe/7bZPwe5tmtRjLbmZjU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=38NlZahBsOfPvL0AGnUaiJ8CTXwp7YAEOJR+9K49KVQ=; b=bAnrEy/R+x04bQqZgYfmfc4DT72ffVufPzqlcbTygRXh1PpD0zwitwhEzF01r34vzM TXvjwlGg4MtM6GtYU+IEbTufSlWruBKfJ8WROF4Z+kjT5TcmToSZV9IRqpucHb6d6Rxf b7v3haGdiVbB7TvE8n0U4ht9/T/kOLvKzpz4O/JaqdAeP20G0WFjeY0zdrEfnpkJEDCd HTBO3mXic8tUFWUUUutrmKTha4eNkvWlBUAqdaGvSm8ZDEWj0lhWNnBOLlbxpSKYAV7d bM91790XxsoGZD2RWhWi1llKbKOZE4s86DEwEI7MYIxHkqzlcUzyIw4GhewSAE/ZiUhd Ho0Q== X-Gm-Message-State: ALoCoQmJL7A9N8fJhh7tAAGcTBkGxKe2QuAowiVSHdHDuRxkh6xb0fk5mD1Mky5OmfQ8SHQWLUXR X-Received: by 10.50.176.196 with SMTP id ck4mr14069022igc.40.1428515790028; Wed, 08 Apr 2015 10:56:30 -0700 (PDT) Received: from [192.168.4.244] (ip-64-134-100-92.public.wayport.net. [64.134.100.92]) by mx.google.com with ESMTPSA id qs3sm7211740igb.8.2015.04.08.10.56.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Apr 2015 10:56:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2FA46DAC-B4F4-4748-B07D-53994DED2023" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Andrew Mortensen In-Reply-To: <6073823821667642A5C884FF3A8807F81F3C7B14@MERCURY.corero.com> Date: Wed, 8 Apr 2015 13:56:27 -0400 Message-Id: <0F4D9F9B-FF90-431A-BC8D-5DF6D0A478C5@arbor.net> References: <6073823821667642A5C884FF3A8807F81F3C7B14@MERCURY.corero.com> To: Scott Barvick X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "Teague, Nik" , "Xialiang \(Frank\)" , Dave Larson , "dots@ietf.org" Subject: Re: [Dots] DOTS work scope discussion: //RE: scope X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 17:56:33 -0000 --Apple-Mail=_2FA46DAC-B4F4-4748-B07D-53994DED2023 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 8, 2015, at 10:36 AM, Scott Barvick = wrote: >=20 > =E2=80=A6 If it is not directly contributing to the signaling of DDoS = threats/conditions/capabilities then we really should really not be = spending any time on it. As examples (for discussion, of course) Thanks for drawing up this list of examples as discussion points. > - DDoS capabilities negotiation between the communicating = parties - in scope because it affects what can be signaled or needs to = be done on either side I=E2=80=99m less sure about this. Trying to encode DDoS mitigation = capabilities seems like an exercise in futility, as the state of the art = is already racing to keep up with attack innovation. Any upstream = services implementing DOTS are indicating mitigation capability. Not all = upstream services will be equal, of course, but upstream capabilities = seem out of scope: the goal of DOTS, as I understand it, is to provide a = standard way for downstream mitigation/detection devices to request = intervention upstream. What upstream does=E2=80=94or even can do=E2=80=94on receipt of a = distress call from downstream beyond DOTS. Upstream elements are of = course under no obligation to mitigate the attack when it=E2=80=99s = requested by the on-premise device, and the downstream on-premise = mitigation/detection device is under no obligation to request upstream = help when under attack. Given cost concerns=E2=80=94and upstream = intervention is likely to have associated cost=E2=80=94a downstream = network operator is going to want to have the option to control whether = mitigation upstream is enabled for their network. > - Configuration or provisioning of the devices for DDoS =E2=80=93= not in scope because while it is DDoS, it is beyond what is necessary = to signal. And we have other protocols to define the operations and = even schemas for this Agreed, this is far afield from DOTS. Far more in scope for NETCONF & = co. > - Communication of signaling thresholds or conditions =E2=80=93= in scope The minimum requirement seems to me just the ability to signal whether = the on-premise device wants help. This is currently encoded as the = =E2=80=9CSOS=E2=80=9D field in the signal to the upstream element. In my = view the need for downstream control over whether upstream mitigation is = enabled means signaling thresholds for automitigation upstream should be = optional. > - Authentication of signaling channel =E2=80=93 in scope Critical, and attack conditions=E2=80=94extremely congested link=E2=80=94a= re going help shape the form this takes. > - Specific flow stats and flow awareness =E2=80=93 not in = scope because it is not DDoS and there are other protocols that = represent this kind of info Maybe more importantly, they aren't going to get through a congested = channel to any upstream element reliably. > - DDoS attack representation =E2=80=93 in-scope because it is = DDoS. Of course, if a device can=E2=80=99t classify the attack because = it is either not that kind of device or it is a new attack, then we need = a way for this to indicate =E2=80=98unknown=E2=80=99 In scope, but not required. It is undoubtedly useful information for the = upstream service, but is not a requirement before upstream can begin = mitigating. At a minimum, a downstream on-premise device should at need = be able request mitigation and request mitigation deactivation. andrew= --Apple-Mail=_2FA46DAC-B4F4-4748-B07D-53994DED2023 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 8, 2015, at 10:36 AM, Scott Barvick <Scott.Barvick@corero.com> wrote:

=E2=80=A6 If it is not directly = contributing to the signaling of DDoS threats/conditions/capabilities = then we really should really not be spending any time on = it.    As examples (for discussion, of = course)

Thanks for drawing up this list of examples as = discussion points.

-          DDoS capabilities negotiation between the = communicating parties -  in scope because it affects what can be = signaled or needs to be done on either = side

I=E2=80=99m less sure about this. Trying to encode = DDoS mitigation capabilities seems like an exercise in futility, as the = state of the art is already racing to keep up with attack innovation. = Any upstream services implementing DOTS are indicating mitigation = capability. Not all upstream services will be equal, of course, but = upstream capabilities seem out of scope: the goal of DOTS, as I = understand it, is to provide a standard way for downstream = mitigation/detection devices to request intervention = upstream.

What upstream does=E2=80=94o= r even can do=E2=80=94on receipt of a distress call from downstream = beyond DOTS. Upstream elements are of course under no obligation to = mitigate the attack when it=E2=80=99s requested by the on-premise = device, and the downstream on-premise mitigation/detection device is = under no obligation to request upstream help when under attack. Given = cost concerns=E2=80=94and upstream intervention is likely to have = associated cost=E2=80=94a downstream network operator is going to want = to have the option to control whether mitigation upstream is enabled for = their network.

-          Configuration or provisioning of the = devices for DDoS =E2=80=93 not in scope because while it is DDoS, it is = beyond what is necessary to signal.  And we have other protocols to = define the operations and even schemas for = this

Agreed, this is far afield from DOTS. Far more in = scope for NETCONF & co.

-          Communication of signaling thresholds or = conditions =E2=80=93 in = scope

The minimum requirement seems to me just the = ability to signal whether the on-premise device wants help. This is = currently encoded as the =E2=80=9CSOS=E2=80=9D field in the signal to = the upstream element. In my view the need for downstream control over = whether upstream mitigation is enabled means signaling thresholds for = automitigation upstream should be optional.

-          Authentication of signaling channel =E2=80=93= in scope

Critical, and attack conditions=E2=80=94extremely = congested link=E2=80=94are going help shape the form this = takes.

-          Specific flow stats and flow awareness =E2=80= =93 not in scope because it is not DDoS and there are other protocols = that represent this kind of = info

Maybe more importantly, they aren't going to get = through a congested channel to any upstream element reliably.

-          DDoS attack representation =E2=80=93 = in-scope because it is DDoS.  Of course, if a device can=E2=80=99t = classify the attack because it is either not that kind of device or it = is a new attack, then we need a way for this to indicate = =E2=80=98unknown=E2=80=99

In scope, but not required. It is undoubtedly useful = information for the upstream service, but is not a requirement before = upstream can begin mitigating. At a minimum, a downstream on-premise = device should at need be able request mitigation and request mitigation = deactivation.

andrew
= --Apple-Mail=_2FA46DAC-B4F4-4748-B07D-53994DED2023-- From nobody Wed Apr 8 19:46:50 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385181B3736 for ; Wed, 8 Apr 2015 19:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XTvN962LxCA for ; Wed, 8 Apr 2015 19:46:45 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA551B3734 for ; Wed, 8 Apr 2015 19:46:44 -0700 (PDT) Received: from [216.82.242.179] by server-4.bemta-8.messagelabs.com id 4E/11-12219-318E5255; Thu, 09 Apr 2015 02:46:43 +0000 X-Env-Sender: Scott.Barvick@corero.com X-Msg-Ref: server-15.tower-86.messagelabs.com!1428547602!44823660!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11501 invoked from network); 9 Apr 2015 02:46:42 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-15.tower-86.messagelabs.com with AES128-SHA encrypted SMTP; 9 Apr 2015 02:46:42 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0224.002; Wed, 8 Apr 2015 22:46:39 -0400 From: Scott Barvick To: Andrew Mortensen Thread-Topic: [Dots] DOTS work scope discussion: //RE: scope Thread-Index: AQHQcaIhLzQhJpbEDkS5B/rKwQEkFp1CchIQgAC3VGCAAIEPgIAAlCEA Date: Thu, 9 Apr 2015 02:46:38 +0000 Message-ID: References: <6073823821667642A5C884FF3A8807F81F3C7B14@MERCURY.corero.com> <0F4D9F9B-FF90-431A-BC8D-5DF6D0A478C5@arbor.net> In-Reply-To: <0F4D9F9B-FF90-431A-BC8D-5DF6D0A478C5@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.34.110.88] Content-Type: multipart/alternative; boundary="_000_F93A844F32034203AF6505D06467A074corerocom_" MIME-Version: 1.0 Archived-At: Cc: Nik Teague , "Xialiang \(Frank\)" , Dave Larson , "dots@ietf.org" Subject: Re: [Dots] DOTS work scope discussion: //RE: scope X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 02:46:48 -0000 --_000_F93A844F32034203AF6505D06467A074corerocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Lots of good discussion that I=92m sure will continue. Of course we=92ll = need to break each topic into different threads and drill into each. Another topic that Andrew is surfacing is in the statement below The minimum requirement seems to me just the ability to signal whether the = on-premise device wants help. This is currently encoded as the =93SOS=94 fi= eld in the signal to the upstream element. I noticed a similar sentiment in the current draft: These elements may be required from time to time to signal to an upstream component or provider that the capabilities of the device are exceeded and that an offramping of attack traffic to a more capable element or infrastructure is desired or required. It might be assumed but I think it needs explicitly called out in the overv= iew and goals that the on-premise device may not need help mitigating per s= e, but signaling may be necessary to potentially off-ramp traffic because t= he upstream link is saturated. Even a box that can handle a full load of = DDoS traffic cannot do anything to help good traffic if the upstream pipe t= o it is full. In that case, signaling can cause rerouting of all or certa= in traffic to free the link to allow valid traffic to start to flow again. = This is, of course, another case where a channel and protocol that can ge= t information out under stressful circumstances will be necessary. Scott On Apr 8, 2015, at 1:56 PM, Andrew Mortensen > wrote: On Apr 8, 2015, at 10:36 AM, Scott Barvick > wrote: =85 If it is not directly contributing to the signaling of DDoS threats/con= ditions/capabilities then we really should really not be spending any time = on it. As examples (for discussion, of course) Thanks for drawing up this list of examples as discussion points. - DDoS capabilities negotiation between the communicating parties = - in scope because it affects what can be signaled or needs to be done on = either side I=92m less sure about this. Trying to encode DDoS mitigation capabilities s= eems like an exercise in futility, as the state of the art is already racin= g to keep up with attack innovation. Any upstream services implementing DOT= S are indicating mitigation capability. Not all upstream services will be e= qual, of course, but upstream capabilities seem out of scope: the goal of D= OTS, as I understand it, is to provide a standard way for downstream mitiga= tion/detection devices to request intervention upstream. What upstream does=97or even can do=97on receipt of a distress call from do= wnstream beyond DOTS. Upstream elements are of course under no obligation t= o mitigate the attack when it=92s requested by the on-premise device, and t= he downstream on-premise mitigation/detection device is under no obligation= to request upstream help when under attack. Given cost concerns=97and upst= ream intervention is likely to have associated cost=97a downstream network = operator is going to want to have the option to control whether mitigation = upstream is enabled for their network. - Configuration or provisioning of the devices for DDoS =96 not in= scope because while it is DDoS, it is beyond what is necessary to signal. = And we have other protocols to define the operations and even schemas for = this Agreed, this is far afield from DOTS. Far more in scope for NETCONF & co. - Communication of signaling thresholds or conditions =96 in scope The minimum requirement seems to me just the ability to signal whether the = on-premise device wants help. This is currently encoded as the =93SOS=94 fi= eld in the signal to the upstream element. In my view the need for downstre= am control over whether upstream mitigation is enabled means signaling thre= sholds for automitigation upstream should be optional. - Authentication of signaling channel =96 in scope Critical, and attack conditions=97extremely congested link=97are going help= shape the form this takes. - Specific flow stats and flow awareness =96 not in scope because = it is not DDoS and there are other protocols that represent this kind of in= fo Maybe more importantly, they aren't going to get through a congested channe= l to any upstream element reliably. - DDoS attack representation =96 in-scope because it is DDoS. Of = course, if a device can=92t classify the attack because it is either not th= at kind of device or it is a new attack, then we need a way for this to ind= icate =91unknown=92 In scope, but not required. It is undoubtedly useful information for the up= stream service, but is not a requirement before upstream can begin mitigati= ng. At a minimum, a downstream on-premise device should at need be able req= uest mitigation and request mitigation deactivation. andrew --_000_F93A844F32034203AF6505D06467A074corerocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <74334006620C8B458592FA7098BFEC79@corero.com> Content-Transfer-Encoding: quoted-printable
Lots of good discussion that I=92m sure will continue.   Of cours= e we=92ll need to break each topic into different threads and drill into ea= ch.   

Another topic that Andrew is surfacing is in the statement below
The minimum requirement seems to me just the ability to signal whether the = on-premise device wants help. This is currently encoded as the =93SOS=94 fi= eld in the signal to the upstream element. 

I noticed a similar sentiment in the current draft:

These elements may
be required from time to time to signal to an upstream component or
provider that the capabilities of the device are exceeded and that an
offramping of attack traffic to a more capable element or
infrastructure is desired or required.

It might be assumed but I think it needs explicitly called out in the = overview and goals that the on-premise device may not need help mitigating = per se, but signaling may be necessary to potentially off-ramp traffic beca= use the upstream link is saturated.   Even a box that can handle a full load of DDoS traffic cannot do an= ything to help good traffic if the upstream pipe to it is full.   In t= hat case, signaling can cause rerouting of all or certain traffic to free t= he link to allow valid traffic to start to flow again.   This is, of course, another case where a channel and pr= otocol that can get information out under stressful circumstances will be n= ecessary.

Scott

On Apr 8, 2015, at 1:56 PM, Andrew Mortensen <amortensen@arbor.net> wrote:


On Apr 8, 2015, at 10:36 AM, Scott Barvick <Scott.Barvick@corero.com>= wrote:

=85 If it is not directly contributing to the s= ignaling of DDoS threats/conditions/capabilities then we really should real= ly not be spending any time on it.    As examples (for discussion, of course)

Thanks for drawing up this list of examples as discussion points.

-   &n= bsp;     &nb= sp;DDoS capabilities negotiation between the communicating parties -  in scop= e because it affects what can be signaled or needs to be done on either sid= e

I=92m less sure about this. Trying to encode DDoS mitigation capabilit= ies seems like an exercise in futility, as the state of the art is already = racing to keep up with attack innovation. Any upstream services implementin= g DOTS are indicating mitigation capability. Not all upstream services will be equal, of course, but upstream capabilit= ies seem out of scope: the goal of DOTS, as I understand it, is to provide = a standard way for downstream mitigation/detection devices to request inter= vention upstream.

What upstream does=97or even can do=97on receipt of a distress call fr= om downstream beyond DOTS. Upstream elements are of course under no obligat= ion to mitigate the attack when it=92s requested by the on-premise device, = and the downstream on-premise mitigation/detection device is under no obligation to request upstream help when under attack. = Given cost concerns=97and upstream intervention is likely to have associate= d cost=97a downstream network operator is going to want to have the option = to control whether mitigation upstream is enabled for their network.

-   &n= bsp;     &nb= sp;Configuration or provisioning of the devices for DDoS =96 not in scope because while it = is DDoS, it is beyond what is necessary to signal.  And we have other = protocols to define the operations and even schemas for this

Agreed, this is far afield from DOTS. Far more in scope for NETCONF &a= mp; co.

-   &n= bsp;     &nb= sp;Communication of signaling thresholds or conditions =96 in scope

The minimum requirement seems to me just the ability to signal whether= the on-premise device wants help. This is currently encoded as the =93SOS= =94 field in the signal to the upstream element. In my view the need for do= wnstream control over whether upstream mitigation is enabled means signaling thresholds for automitigation upstre= am should be optional.

-   &n= bsp;     &nb= sp;Authentication of signaling channel =96 in scope

Critical, and attack conditions=97extremely congested link=97are going= help shape the form this takes.

-   &n= bsp;     &nb= sp;Specific flow stats and flow awareness =96 not in scope because it is not DDoS and = there are other protocols that represent this kind of info

Maybe more importantly, they aren't going to get through a congested c= hannel to any upstream element reliably.

-   &n= bsp;     &nb= sp;DDoS attack representation =96 in-scope because it is DDoS.  Of course, if= a device can=92t classify the attack because it is either not that kind of= device or it is a new attack, then we need a way for this to indicate =91u= nknown=92

In scope, but not required. It is undoubtedly useful information for the up= stream service, but is not a requirement before upstream can begin mitigati= ng. At a minimum, a downstream on-premise device should at need be able req= uest mitigation and request mitigation deactivation.

andrew

--_000_F93A844F32034203AF6505D06467A074corerocom_-- From nobody Wed Apr 8 19:51:13 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267421B3744 for ; Wed, 8 Apr 2015 19:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQO9K2VfqcvM for ; Wed, 8 Apr 2015 19:51:09 -0700 (PDT) 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 710AD1B3737 for ; Wed, 8 Apr 2015 19:51:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRE70549; Thu, 09 Apr 2015 02:51:06 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Apr 2015 03:51:04 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.144]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Thu, 9 Apr 2015 10:51:01 +0800 From: "Xialiang (Frank)" To: Andrew Mortensen , Scott Barvick Thread-Topic: [Dots] DOTS work scope discussion: //RE: scope Thread-Index: AQHQcaIhLzQhJpbEDkS5B/rKwQEkFp1CchIQgAC3VGD//7fkgIABDgog Date: Thu, 9 Apr 2015 02:51:00 +0000 Message-ID: References: <6073823821667642A5C884FF3A8807F81F3C7B14@MERCURY.corero.com> <0F4D9F9B-FF90-431A-BC8D-5DF6D0A478C5@arbor.net> In-Reply-To: <0F4D9F9B-FF90-431A-BC8D-5DF6D0A478C5@arbor.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.42.200] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12ADB0F39SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Teague, Nik" , Dave Larson , "dots@ietf.org" Subject: Re: [Dots] DOTS work scope discussion: //RE: scope X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 02:51:12 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB0F39SZXEMA502MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KTXkgY29tbWVudHMgYXJlIGlubGluZToNCg0KVGhhbmtzIQ0KDQpCLlIuDQpGcmFu aw0KDQpGcm9tOiBBbmRyZXcgTW9ydGVuc2VuIFttYWlsdG86YW1vcnRlbnNlbkBhcmJvci5uZXRd DQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDksIDIwMTUgMTo1NiBBTQ0KVG86IFNjb3R0IEJhcnZp Y2sNCkNjOiBYaWFsaWFuZyAoRnJhbmspOyBEYXZlIExhcnNvbjsgVGVhZ3VlLCBOaWs7IGRvdHNA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyB3b3JrIHNjb3BlIGRpc2N1c3Npb246 IC8vUkU6IHNjb3BlDQoNCg0KT24gQXByIDgsIDIwMTUsIGF0IDEwOjM2IEFNLCBTY290dCBCYXJ2 aWNrIDxTY290dC5CYXJ2aWNrQGNvcmVyby5jb208bWFpbHRvOlNjb3R0LkJhcnZpY2tAY29yZXJv LmNvbT4+IHdyb3RlOg0KDQrigKYgSWYgaXQgaXMgbm90IGRpcmVjdGx5IGNvbnRyaWJ1dGluZyB0 byB0aGUgc2lnbmFsaW5nIG9mIEREb1MgdGhyZWF0cy9jb25kaXRpb25zL2NhcGFiaWxpdGllcyB0 aGVuIHdlIHJlYWxseSBzaG91bGQgcmVhbGx5IG5vdCBiZSBzcGVuZGluZyBhbnkgdGltZSBvbiBp dC4gICAgQXMgZXhhbXBsZXMgKGZvciBkaXNjdXNzaW9uLCBvZiBjb3Vyc2UpDQoNClRoYW5rcyBm b3IgZHJhd2luZyB1cCB0aGlzIGxpc3Qgb2YgZXhhbXBsZXMgYXMgZGlzY3Vzc2lvbiBwb2ludHMu DQoNCi0gICAgICAgICAgRERvUyBjYXBhYmlsaXRpZXMgbmVnb3RpYXRpb24gYmV0d2VlbiB0aGUg Y29tbXVuaWNhdGluZyBwYXJ0aWVzIC0gIGluIHNjb3BlIGJlY2F1c2UgaXQgYWZmZWN0cyB3aGF0 IGNhbiBiZSBzaWduYWxlZCBvciBuZWVkcyB0byBiZSBkb25lIG9uIGVpdGhlciBzaWRlDQoNCkni gJltIGxlc3Mgc3VyZSBhYm91dCB0aGlzLiBUcnlpbmcgdG8gZW5jb2RlIEREb1MgbWl0aWdhdGlv biBjYXBhYmlsaXRpZXMgc2VlbXMgbGlrZSBhbiBleGVyY2lzZSBpbiBmdXRpbGl0eSwgYXMgdGhl IHN0YXRlIG9mIHRoZSBhcnQgaXMgYWxyZWFkeSByYWNpbmcgdG8ga2VlcCB1cCB3aXRoIGF0dGFj ayBpbm5vdmF0aW9uLiBBbnkgdXBzdHJlYW0gc2VydmljZXMgaW1wbGVtZW50aW5nIERPVFMgYXJl IGluZGljYXRpbmcgbWl0aWdhdGlvbiBjYXBhYmlsaXR5LiBOb3QgYWxsIHVwc3RyZWFtIHNlcnZp Y2VzIHdpbGwgYmUgZXF1YWwsIG9mIGNvdXJzZSwgYnV0IHVwc3RyZWFtIGNhcGFiaWxpdGllcyBz ZWVtIG91dCBvZiBzY29wZTogdGhlIGdvYWwgb2YgRE9UUywgYXMgSSB1bmRlcnN0YW5kIGl0LCBp cyB0byBwcm92aWRlIGEgc3RhbmRhcmQgd2F5IGZvciBkb3duc3RyZWFtIG1pdGlnYXRpb24vZGV0 ZWN0aW9uIGRldmljZXMgdG8gcmVxdWVzdCBpbnRlcnZlbnRpb24gdXBzdHJlYW0uDQpbRnJhbmtd IDogQXQgbGVhc3QsIGluIHRoZSBtdWx0aXBsZSB1cHN0cmVhbXMgY29uZGl0aW9uLCB0aGUgYXdh cmVuZXNzIG9mIGV2ZXJ5IHVwc3RyZWFt4oCZcyBjYXBhYmlsaXR5IGJ5IGRvd25zdHJlYW0gY2Fu IGhlbHAgaXQgbWFrZSB0aGUgcmlnaHQgY2hvaWNlLiBTbywgdGhlIGJpZGlyZWN0aW9uYWwgbmVn b3RpYXRpb24gbWVjaGFuaXNtIGlzIHVzZWZ1bCBmb3IgbWFraW5nIHRoZSB3aG9sZSBzb2x1dGlv biBtb3JlIHNtYXJ0IGFuZCBlZmZpY2llbnQuIEJ1dCBob3cgdG8gcmVwcmVzZW50IHRoZSBjYXBh YmlsaXR5IGFuZCBpbiB3aGljaCBncmFudWxhcml0eSBpcyBpbmRlZWQgYSBxdWVzdGlvbi4gSSB0 ZW5kIHRvIGNob29zZSBhIGNvYXJzZS1ncmFpbmVkIGNhdGVnb3J5IGZvciBhcHBsaWNhYmlsaXR5 Lg0KDQpXaGF0IHVwc3RyZWFtIGRvZXPigJRvciBldmVuIGNhbiBkb+KAlG9uIHJlY2VpcHQgb2Yg YSBkaXN0cmVzcyBjYWxsIGZyb20gZG93bnN0cmVhbSBiZXlvbmQgRE9UUy4gVXBzdHJlYW0gZWxl bWVudHMgYXJlIG9mIGNvdXJzZSB1bmRlciBubyBvYmxpZ2F0aW9uIHRvIG1pdGlnYXRlIHRoZSBh dHRhY2sgd2hlbiBpdOKAmXMgcmVxdWVzdGVkIGJ5IHRoZSBvbi1wcmVtaXNlIGRldmljZSwgYW5k IHRoZSBkb3duc3RyZWFtIG9uLXByZW1pc2UgbWl0aWdhdGlvbi9kZXRlY3Rpb24gZGV2aWNlIGlz IHVuZGVyIG5vIG9ibGlnYXRpb24gdG8gcmVxdWVzdCB1cHN0cmVhbSBoZWxwIHdoZW4gdW5kZXIg YXR0YWNrLiBHaXZlbiBjb3N0IGNvbmNlcm5z4oCUYW5kIHVwc3RyZWFtIGludGVydmVudGlvbiBp cyBsaWtlbHkgdG8gaGF2ZSBhc3NvY2lhdGVkIGNvc3TigJRhIGRvd25zdHJlYW0gbmV0d29yayBv cGVyYXRvciBpcyBnb2luZyB0byB3YW50IHRvIGhhdmUgdGhlIG9wdGlvbiB0byBjb250cm9sIHdo ZXRoZXIgbWl0aWdhdGlvbiB1cHN0cmVhbSBpcyBlbmFibGVkIGZvciB0aGVpciBuZXR3b3JrLg0K W0ZyYW5rXSA6IER1ZSB0byB0aGUgdXBzdHJlYW0gaW50ZXJ2ZW50aW9uIGlzIGFzc29jaWF0ZWQg Y29zdCwgdGhlIGRvd25zdHJlYW0gZGV2aWNlIGlzIG1vcmUgbGlrZWx5IHRvIGRlcGVuZCBvbiB0 aGUgbmVnb3RpYXRpb24gbWVjaGFuaXNtIHRvIGhlbHAgaXQgY2hvb3NlIHRoZSBzdWl0YWJsZSB1 cHN0cmVhbS4NCg0KLSAgICAgICAgICBDb25maWd1cmF0aW9uIG9yIHByb3Zpc2lvbmluZyBvZiB0 aGUgZGV2aWNlcyBmb3IgRERvUyDigJMgbm90IGluIHNjb3BlIGJlY2F1c2Ugd2hpbGUgaXQgaXMg RERvUywgaXQgaXMgYmV5b25kIHdoYXQgaXMgbmVjZXNzYXJ5IHRvIHNpZ25hbC4gIEFuZCB3ZSBo YXZlIG90aGVyIHByb3RvY29scyB0byBkZWZpbmUgdGhlIG9wZXJhdGlvbnMgYW5kIGV2ZW4gc2No ZW1hcyBmb3IgdGhpcw0KDQpBZ3JlZWQsIHRoaXMgaXMgZmFyIGFmaWVsZCBmcm9tIERPVFMuIEZh ciBtb3JlIGluIHNjb3BlIGZvciBORVRDT05GICYgY28uDQoNCg0KLSAgICAgICAgICBDb21tdW5p Y2F0aW9uIG9mIHNpZ25hbGluZyB0aHJlc2hvbGRzIG9yIGNvbmRpdGlvbnMg4oCTIGluIHNjb3Bl DQoNClRoZSBtaW5pbXVtIHJlcXVpcmVtZW50IHNlZW1zIHRvIG1lIGp1c3QgdGhlIGFiaWxpdHkg dG8gc2lnbmFsIHdoZXRoZXIgdGhlIG9uLXByZW1pc2UgZGV2aWNlIHdhbnRzIGhlbHAuIFRoaXMg aXMgY3VycmVudGx5IGVuY29kZWQgYXMgdGhlIOKAnFNPU+KAnSBmaWVsZCBpbiB0aGUgc2lnbmFs IHRvIHRoZSB1cHN0cmVhbSBlbGVtZW50LiBJbiBteSB2aWV3IHRoZSBuZWVkIGZvciBkb3duc3Ry ZWFtIGNvbnRyb2wgb3ZlciB3aGV0aGVyIHVwc3RyZWFtIG1pdGlnYXRpb24gaXMgZW5hYmxlZCBt ZWFucyBzaWduYWxpbmcgdGhyZXNob2xkcyBmb3IgYXV0b21pdGlnYXRpb24gdXBzdHJlYW0gc2hv dWxkIGJlIG9wdGlvbmFsLg0KDQoNCi0gICAgICAgICAgQXV0aGVudGljYXRpb24gb2Ygc2lnbmFs aW5nIGNoYW5uZWwg4oCTIGluIHNjb3BlDQoNCkNyaXRpY2FsLCBhbmQgYXR0YWNrIGNvbmRpdGlv bnPigJRleHRyZW1lbHkgY29uZ2VzdGVkIGxpbmvigJRhcmUgZ29pbmcgaGVscCBzaGFwZSB0aGUg Zm9ybSB0aGlzIHRha2VzLg0KDQoNCi0gICAgICAgICAgU3BlY2lmaWMgZmxvdyBzdGF0cyBhbmQg ZmxvdyBhd2FyZW5lc3Mg4oCTIG5vdCBpbiBzY29wZSBiZWNhdXNlIGl0IGlzIG5vdCBERG9TIGFu ZCB0aGVyZSBhcmUgb3RoZXIgcHJvdG9jb2xzIHRoYXQgcmVwcmVzZW50IHRoaXMga2luZCBvZiBp bmZvDQoNCk1heWJlIG1vcmUgaW1wb3J0YW50bHksIHRoZXkgYXJlbid0IGdvaW5nIHRvIGdldCB0 aHJvdWdoIGEgY29uZ2VzdGVkIGNoYW5uZWwgdG8gYW55IHVwc3RyZWFtIGVsZW1lbnQgcmVsaWFi bHkuDQpbRnJhbmtdIDogSSBjYW5ub3QgdG90YWxseSBhZ3JlZSB3aXRoIHRoaXMgcG9pbnQuIElu IGFkZGl0aW9uIHRvIHRoZSBwcmVjaXNlIGF0dGFjayBpbmZvIGluc3BlY3RlZCBieSB0aGUgRERv UyBtaXRpZ2F0aW9uIGRldmljZSwgdGhlIHNwZWNpZmljIGZsb3cgc3RhdHMgaW5mbyBpbnNwZWN0 ZWQgYnkgdGhlIG5vcm1hbCBuZXR3b3JrIGRldmljZXMgKGkuZS4sIHJvdXRlciwgc3dpdGNoKSBh cmUgYWxzbyB2ZXJ5IHZhbHVhYmxlIGZvciB0aGUgdXBzdHJlYW0gcGxhdGZvcm0gdG8gYmUgYXdh cmUgb2Ygd2hhdCBoYXBwZW4gaW4gbmV0d29yayBhbmQgd2hhdCB0byBkbyB0aGVuLiBXZSBzaG91 bGQgY29uc2lkZXIgYSBnZW5lcmFsIHVzZSBjYXNlLCBhbmQgbm90IGV4Y2x1ZGUgdGhlIG5ldHdv cmsgZGV2aWNlcyBvdXQgb2YgdGhlIHNjb3BlLg0KDQoNCi0gICAgICAgICAgRERvUyBhdHRhY2sg cmVwcmVzZW50YXRpb24g4oCTIGluLXNjb3BlIGJlY2F1c2UgaXQgaXMgRERvUy4gIE9mIGNvdXJz ZSwgaWYgYSBkZXZpY2UgY2Fu4oCZdCBjbGFzc2lmeSB0aGUgYXR0YWNrIGJlY2F1c2UgaXQgaXMg ZWl0aGVyIG5vdCB0aGF0IGtpbmQgb2YgZGV2aWNlIG9yIGl0IGlzIGEgbmV3IGF0dGFjaywgdGhl biB3ZSBuZWVkIGEgd2F5IGZvciB0aGlzIHRvIGluZGljYXRlIOKAmHVua25vd27igJkNCg0KSW4g c2NvcGUsIGJ1dCBub3QgcmVxdWlyZWQuIEl0IGlzIHVuZG91YnRlZGx5IHVzZWZ1bCBpbmZvcm1h dGlvbiBmb3IgdGhlIHVwc3RyZWFtIHNlcnZpY2UsIGJ1dCBpcyBub3QgYSByZXF1aXJlbWVudCBi ZWZvcmUgdXBzdHJlYW0gY2FuIGJlZ2luIG1pdGlnYXRpbmcuIEF0IGEgbWluaW11bSwgYSBkb3du c3RyZWFtIG9uLXByZW1pc2UgZGV2aWNlIHNob3VsZCBhdCBuZWVkIGJlIGFibGUgcmVxdWVzdCBt aXRpZ2F0aW9uIGFuZCByZXF1ZXN0IG1pdGlnYXRpb24gZGVhY3RpdmF0aW9uLg0KW0ZyYW5rXSA6 IEJ5IG15IHVuZGVyc3RhbmRpbmcsIGFuIGltcG9ydGFudCBnb2FsIG9mIERPVFMgd29yayBpcyB0 byBpbXByb3ZlIHRoZSBzZWN1cml0eSBpbnRlbGxpZ2VuY2Ugc2hhcmluZyBhbW9uZyB0aGUgd2hv bGUgbmV0d29yayBzZWN1cml0eSBlY29zeXN0ZW0uIFNvLCBob3cgdG8gcmVwcmVzZW50IHRoZSBE RG9TIGF0dGFja3MgYW5kIHNoYXJpbmcgdGhlbSBpcyBhIHZlcnkgdXNlZnVsIHdvcmsuIFNvLCBk ZWZpbml0ZWx5LCBpdCBzaG91bGQgYmUgaW4gc2NvcGUsIGFuZCB0aGUgRERvUyBhdHRhY2sgaW5m byBzaG91bGQgYmUgc2hhcmVkIGFtb25nIHRoZSBmZWRlcmFsIHBlZXJzIGluIHRpbWUuIEZvciB0 aGUgbmV3IGF0dGFjaywgdG8gaW5kaWNhdGUg4oCYdW5rbm93buKAmSBpcyB0aGUgZGVmYXVsdCBt ZXRob2QsIGJ1dCBpdCBpcyBhbHNvIHBvc3NpYmxlIHRvIGJldHRlciByZXByZXNlbnQgdGhlbSBi eSB1c2luZyBzb21lIGdvb2QgZGVzaWduIGFuZCBleHRlbnNpYmxlIGluZm9ybWF0aW9uIHNjaGVt ZS4NCg0KYW5kcmV3DQo= --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB0F39SZXEMA502MBSchi_ 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 CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252 ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJa SC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5NeSBjb21tZW50cyBhcmUgaW5saW5lOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkIuUi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkZyYW5rPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFuZHJldyBNb3J0ZW5zZW4gW21haWx0 bzphbW9ydGVuc2VuQGFyYm9yLm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXBy aWwgMDksIDIwMTUgMTo1NiBBTTxicj4NCjxiPlRvOjwvYj4gU2NvdHQgQmFydmljazxicj4NCjxi PkNjOjwvYj4gWGlhbGlhbmcgKEZyYW5rKTsgRGF2ZSBMYXJzb247IFRlYWd1ZSwgTmlrOyBkb3Rz QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRG90c10gRE9UUyB3b3JrIHNjb3Bl IGRpc2N1c3Npb246IC8vUkU6IHNjb3BlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBBcHIgOCwgMjAxNSwgYXQgMTA6MzYg QU0sIFNjb3R0IEJhcnZpY2sgJmx0OzxhIGhyZWY9Im1haWx0bzpTY290dC5CYXJ2aWNrQGNvcmVy by5jb20iPlNjb3R0LkJhcnZpY2tAY29yZXJvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj7igKYgSWYgaXQgaXMgbm90IGRpcmVjdGx5IGNvbnRyaWJ1dGluZyB0byB0aGUg c2lnbmFsaW5nIG9mIEREb1MgdGhyZWF0cy9jb25kaXRpb25zL2NhcGFiaWxpdGllcyB0aGVuIHdl IHJlYWxseSBzaG91bGQgcmVhbGx5IG5vdCBiZSBzcGVuZGluZyBhbnkNCiB0aW1lIG9uIGl0LiZu YnNwOyZuYnNwOyZuYnNwOyBBcyBleGFtcGxlcyAoZm9yIGRpc2N1c3Npb24sIG9mIGNvdXJzZSk8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3Mg Zm9yIGRyYXdpbmcgdXAgdGhpcyBsaXN0IG9mIGV4YW1wbGVzIGFzIGRpc2N1c3Npb24gcG9pbnRz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RERvUw0KIGNhcGFiaWxp dGllcyBuZWdvdGlhdGlvbiBiZXR3ZWVuIHRoZSBjb21tdW5pY2F0aW5nIHBhcnRpZXMgLSAmbmJz cDtpbiBzY29wZSBiZWNhdXNlIGl0IGFmZmVjdHMgd2hhdCBjYW4gYmUgc2lnbmFsZWQgb3IgbmVl ZHMgdG8gYmUgZG9uZSBvbiBlaXRoZXIgc2lkZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPknigJltIGxlc3Mgc3VyZSBhYm91dCB0aGlzLiBUcnlpbmcg dG8gZW5jb2RlIEREb1MgbWl0aWdhdGlvbiBjYXBhYmlsaXRpZXMgc2VlbXMgbGlrZSBhbiBleGVy Y2lzZSBpbiBmdXRpbGl0eSwgYXMgdGhlIHN0YXRlIG9mIHRoZSBhcnQgaXMgYWxyZWFkeSByYWNp bmcgdG8ga2VlcCB1cCB3aXRoIGF0dGFjayBpbm5vdmF0aW9uLiBBbnkgdXBzdHJlYW0gc2Vydmlj ZXMgaW1wbGVtZW50aW5nDQogRE9UUyBhcmUgaW5kaWNhdGluZyBtaXRpZ2F0aW9uIGNhcGFiaWxp dHkuIE5vdCBhbGwgdXBzdHJlYW0gc2VydmljZXMgd2lsbCBiZSBlcXVhbCwgb2YgY291cnNlLCBi dXQgdXBzdHJlYW0gY2FwYWJpbGl0aWVzIHNlZW0gb3V0IG9mIHNjb3BlOiB0aGUgZ29hbCBvZiBE T1RTLCBhcyBJIHVuZGVyc3RhbmQgaXQsIGlzIHRvIHByb3ZpZGUgYSBzdGFuZGFyZCB3YXkgZm9y IGRvd25zdHJlYW0gbWl0aWdhdGlvbi9kZXRlY3Rpb24gZGV2aWNlcyB0byByZXF1ZXN0DQogaW50 ZXJ2ZW50aW9uIHVwc3RyZWFtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+W0ZyYW5rXSA6IEF0IGxlYXN0LCBpbiB0aGUgbXVsdGlwbGUgdXBzdHJlYW1z IGNvbmRpdGlvbiwgdGhlIGF3YXJlbmVzcyBvZiBldmVyeSB1cHN0cmVhbeKAmXMgY2FwYWJpbGl0 eSBieSBkb3duc3RyZWFtIGNhbiBoZWxwIGl0IG1ha2UgdGhlDQogcmlnaHQgY2hvaWNlLiBTbywg dGhlIGJpZGlyZWN0aW9uYWwgbmVnb3RpYXRpb24gbWVjaGFuaXNtIGlzIHVzZWZ1bCBmb3IgbWFr aW5nIHRoZSB3aG9sZSBzb2x1dGlvbiBtb3JlIHNtYXJ0IGFuZCBlZmZpY2llbnQuIEJ1dCBob3cg dG8gcmVwcmVzZW50IHRoZSBjYXBhYmlsaXR5IGFuZCBpbiB3aGljaCBncmFudWxhcml0eSBpcyBp bmRlZWQgYSBxdWVzdGlvbi4gSSB0ZW5kIHRvIGNob29zZSBhIGNvYXJzZS1ncmFpbmVkIGNhdGVn b3J5IGZvciBhcHBsaWNhYmlsaXR5Ljwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XaGF0IHVwc3RyZWFtIGRvZXPigJRvciBldmVu IGNhbiBkb+KAlG9uIHJlY2VpcHQgb2YgYSBkaXN0cmVzcyBjYWxsIGZyb20gZG93bnN0cmVhbSBi ZXlvbmQgRE9UUy4gVXBzdHJlYW0gZWxlbWVudHMgYXJlIG9mIGNvdXJzZSB1bmRlciBubyBvYmxp Z2F0aW9uIHRvIG1pdGlnYXRlIHRoZSBhdHRhY2sgd2hlbiBpdOKAmXMgcmVxdWVzdGVkIGJ5IHRo ZSBvbi1wcmVtaXNlIGRldmljZSwgYW5kDQogdGhlIGRvd25zdHJlYW0gb24tcHJlbWlzZSBtaXRp Z2F0aW9uL2RldGVjdGlvbiBkZXZpY2UgaXMgdW5kZXIgbm8gb2JsaWdhdGlvbiB0byByZXF1ZXN0 IHVwc3RyZWFtIGhlbHAgd2hlbiB1bmRlciBhdHRhY2suIEdpdmVuIGNvc3QgY29uY2VybnPigJRh bmQgdXBzdHJlYW0gaW50ZXJ2ZW50aW9uIGlzIGxpa2VseSB0byBoYXZlIGFzc29jaWF0ZWQgY29z dOKAlGEgZG93bnN0cmVhbSBuZXR3b3JrIG9wZXJhdG9yIGlzIGdvaW5nIHRvIHdhbnQgdG8gaGF2 ZQ0KIHRoZSBvcHRpb24gdG8gY29udHJvbCB3aGV0aGVyIG1pdGlnYXRpb24gdXBzdHJlYW0gaXMg ZW5hYmxlZCBmb3IgdGhlaXIgbmV0d29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPltGcmFua10gOiBEdWUgdG8gdGhlIHVwc3RyZWFtIGludGVydmVu dGlvbiBpcyBhc3NvY2lhdGVkIGNvc3QsIHRoZSBkb3duc3RyZWFtIGRldmljZSBpcyBtb3JlIGxp a2VseSB0byBkZXBlbmQgb24gdGhlIG5lZ290aWF0aW9uIG1lY2hhbmlzbQ0KIHRvIGhlbHAgaXQg Y2hvb3NlIHRoZSBzdWl0YWJsZSB1cHN0cmVhbS48L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29uZmlndXJhdGlvbg0KIG9yIHByb3Zpc2lvbmlu ZyBvZiB0aGUgZGV2aWNlcyBmb3IgRERvUyDigJMgbm90IGluIHNjb3BlIGJlY2F1c2Ugd2hpbGUg aXQgaXMgRERvUywgaXQgaXMgYmV5b25kIHdoYXQgaXMgbmVjZXNzYXJ5IHRvIHNpZ25hbC4mbmJz cDsgQW5kIHdlIGhhdmUgb3RoZXIgcHJvdG9jb2xzIHRvIGRlZmluZSB0aGUgb3BlcmF0aW9ucyBh bmQgZXZlbiBzY2hlbWFzIGZvciB0aGlzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+QWdyZWVkLCB0aGlzIGlzIGZhciBhZmllbGQgZnJvbSBET1RTLiBG YXIgbW9yZSBpbiBzY29wZSBmb3IgTkVUQ09ORiAmYW1wOyBjby48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDot MTguMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPi08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5Db21tdW5pY2F0aW9uDQogb2Ygc2lnbmFsaW5nIHRocmVzaG9sZHMgb3IgY29u ZGl0aW9ucyDigJMgaW4gc2NvcGU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5U aGUgbWluaW11bSByZXF1aXJlbWVudCBzZWVtcyB0byBtZSBqdXN0IHRoZSBhYmlsaXR5IHRvIHNp Z25hbCB3aGV0aGVyIHRoZSBvbi1wcmVtaXNlIGRldmljZSB3YW50cyBoZWxwLiBUaGlzIGlzIGN1 cnJlbnRseSBlbmNvZGVkIGFzIHRoZSDigJxTT1PigJ0gZmllbGQgaW4gdGhlIHNpZ25hbCB0byB0 aGUgdXBzdHJlYW0gZWxlbWVudC4gSW4gbXkgdmlldyB0aGUgbmVlZCBmb3IgZG93bnN0cmVhbQ0K IGNvbnRyb2wgb3ZlciB3aGV0aGVyIHVwc3RyZWFtIG1pdGlnYXRpb24gaXMgZW5hYmxlZCBtZWFu cyBzaWduYWxpbmcgdGhyZXNob2xkcyBmb3IgYXV0b21pdGlnYXRpb24gdXBzdHJlYW0gc2hvdWxk IGJlIG9wdGlvbmFsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LTwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkF1dGhlbnRpY2F0aW9u DQogb2Ygc2lnbmFsaW5nIGNoYW5uZWwg4oCTIGluIHNjb3BlPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Q3JpdGljYWwsIGFuZCBhdHRhY2sgY29uZGl0aW9uc+KAlGV4dHJlbWVs eSBjb25nZXN0ZWQgbGlua+KAlGFyZSBnb2luZyBoZWxwIHNoYXBlIHRoZSBmb3JtIHRoaXMgdGFr ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U3BlY2lmaWMNCiBmbG93IHN0YXRzIGFu ZCBmbG93IGF3YXJlbmVzcyDigJMgbm90IGluIHNjb3BlIGJlY2F1c2UgaXQgaXMgbm90IEREb1Mg YW5kIHRoZXJlIGFyZSBvdGhlciBwcm90b2NvbHMgdGhhdCByZXByZXNlbnQgdGhpcyBraW5kIG9m IGluZm88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5NYXliZSBtb3JlIGltcG9y dGFudGx5LCB0aGV5IGFyZW4ndCBnb2luZyB0byBnZXQgdGhyb3VnaCBhIGNvbmdlc3RlZCBjaGFu bmVsIHRvIGFueSB1cHN0cmVhbSBlbGVtZW50IHJlbGlhYmx5LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0ZyYW5rXSA6IEkgY2Fubm90IHRvdGFsbHkg YWdyZWUgd2l0aCB0aGlzIHBvaW50LiBJbiBhZGRpdGlvbiB0byB0aGUgcHJlY2lzZSBhdHRhY2sg aW5mbyBpbnNwZWN0ZWQgYnkgdGhlIEREb1MgbWl0aWdhdGlvbiBkZXZpY2UsIHRoZSBzcGVjaWZp Yw0KIGZsb3cgc3RhdHMgaW5mbyBpbnNwZWN0ZWQgYnkgdGhlIG5vcm1hbCBuZXR3b3JrIGRldmlj ZXMgKGkuZS4sIHJvdXRlciwgc3dpdGNoKSBhcmUgYWxzbyB2ZXJ5IHZhbHVhYmxlIGZvciB0aGUg dXBzdHJlYW0gcGxhdGZvcm0gdG8gYmUgYXdhcmUgb2Ygd2hhdCBoYXBwZW4gaW4gbmV0d29yayBh bmQgd2hhdCB0byBkbyB0aGVuLiBXZSBzaG91bGQgY29uc2lkZXIgYSBnZW5lcmFsIHVzZSBjYXNl LCBhbmQgbm90IGV4Y2x1ZGUgdGhlIG5ldHdvcmsgZGV2aWNlcw0KIG91dCBvZiB0aGUgc2NvcGUu PC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi08L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ERG9TDQogYXR0YWNr IHJlcHJlc2VudGF0aW9uIOKAkyBpbi1zY29wZSBiZWNhdXNlIGl0IGlzIEREb1MuJm5ic3A7IE9m IGNvdXJzZSwgaWYgYSBkZXZpY2UgY2Fu4oCZdCBjbGFzc2lmeSB0aGUgYXR0YWNrIGJlY2F1c2Ug aXQgaXMgZWl0aGVyIG5vdCB0aGF0IGtpbmQgb2YgZGV2aWNlIG9yIGl0IGlzIGEgbmV3IGF0dGFj aywgdGhlbiB3ZSBuZWVkIGEgd2F5IGZvciB0aGlzIHRvIGluZGljYXRlIOKAmHVua25vd27igJk8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIHNjb3BlLCBidXQgbm90IHJlcXVpcmVkLiBJ dCBpcyB1bmRvdWJ0ZWRseSB1c2VmdWwgaW5mb3JtYXRpb24gZm9yIHRoZSB1cHN0cmVhbSBzZXJ2 aWNlLCBidXQgaXMgbm90IGEgcmVxdWlyZW1lbnQgYmVmb3JlIHVwc3RyZWFtIGNhbiBiZWdpbiBt aXRpZ2F0aW5nLiBBdCBhIG1pbmltdW0sIGEgZG93bnN0cmVhbSBvbi1wcmVtaXNlIGRldmljZSBz aG91bGQgYXQgbmVlZCBiZQ0KIGFibGUgcmVxdWVzdCBtaXRpZ2F0aW9uIGFuZCByZXF1ZXN0IG1p dGlnYXRpb24gZGVhY3RpdmF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+W0ZyYW5rXSA6IEJ5IG15IHVuZGVyc3RhbmRpbmcsIGFuIGltcG9ydGFu dCBnb2FsIG9mIERPVFMgd29yayBpcyB0byBpbXByb3ZlIHRoZSBzZWN1cml0eSBpbnRlbGxpZ2Vu Y2Ugc2hhcmluZyBhbW9uZyB0aGUgd2hvbGUgbmV0d29yayBzZWN1cml0eQ0KIGVjb3N5c3RlbS4g U28sIGhvdyB0byByZXByZXNlbnQgdGhlIEREb1MgYXR0YWNrcyBhbmQgc2hhcmluZyB0aGVtIGlz IGEgdmVyeSB1c2VmdWwgd29yay4gU28sIGRlZmluaXRlbHksIGl0IHNob3VsZCBiZSBpbiBzY29w ZSwgYW5kIHRoZSBERG9TIGF0dGFjayBpbmZvIHNob3VsZCBiZSBzaGFyZWQgYW1vbmcgdGhlIGZl ZGVyYWwgcGVlcnMgaW4gdGltZS4gRm9yIHRoZSBuZXcgYXR0YWNrLCB0byBpbmRpY2F0ZSDigJh1 bmtub3du4oCZIGlzIHRoZSBkZWZhdWx0DQogbWV0aG9kLCBidXQgaXQgaXMgYWxzbyBwb3NzaWJs ZSB0byBiZXR0ZXIgcmVwcmVzZW50IHRoZW0gYnkgdXNpbmcgc29tZSBnb29kIGRlc2lnbiBhbmQg ZXh0ZW5zaWJsZSBpbmZvcm1hdGlvbiBzY2hlbWUuPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmFuZHJldzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB0F39SZXEMA502MBSchi_-- From nobody Wed Apr 8 19:54:38 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2691B374D for ; Wed, 8 Apr 2015 19:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48fgYD5HEun8 for ; Wed, 8 Apr 2015 19:54:23 -0700 (PDT) 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 4B0471B3741 for ; Wed, 8 Apr 2015 19:54:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRE70706; Thu, 09 Apr 2015 02:54:21 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Apr 2015 03:54:19 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.144]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Thu, 9 Apr 2015 10:54:14 +0800 From: "Xialiang (Frank)" To: John Thread-Topic: [Dots] DOTS work scope discussion: //RE: scope Thread-Index: AQHQcaIhLzQhJpbEDkS5B/rKwQEkFp1CchIQgAC3VGD//5JagIABQUag Date: Thu, 9 Apr 2015 02:54:14 +0000 Message-ID: References: <6073823821667642A5C884FF3A8807F81F3C7B14@MERCURY.corero.com> <55254C4D.1020608@flowtools.net> In-Reply-To: <55254C4D.1020608@flowtools.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.42.200] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12ADB0F49SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] DOTS work scope discussion: //RE: scope X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 02:54:38 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB0F49SZXEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, Please see inline: Thanks! B.R. Frank From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of John Sent: Wednesday, April 08, 2015 11:42 PM To: dots@ietf.org Subject: Re: [Dots] DOTS work scope discussion: //RE: scope Hello, Sorry I'm late to this discussion but I've recently learned of this eff= ort and I'm very interested in the topic. If my questions have already been= addressed and I missed where this was previously discussed, I'm apologize = for raising the issue again and I would appreciate being directed to where = the question was answered or discussed. Please see inline. On 04/08/2015 08:36 AM, Scott Barvick wrote: Thanks for the intro and welcome. From the reading of the minutes and t= he thread, it seems that we can and should be using the words 'DDoS' and 's= ignaling' along with not overlapping with other IETF work to help us check= our activities against a focus that will allow us to get chartered as a WG= and then make the required progress towards goals that we will have as one= . If it is not directly contributing to the signaling of DDoS threats/con= ditions/capabilities then we really should really not be spending any time = on it. As examples (for discussion, of course) - DDoS capabilities negotiation between the communicating parties = - in scope because it affects what can be signaled or needs to be done on = either side - Configuration or provisioning of the devices for DDoS - not in s= cope because while it is DDoS, it is beyond what is necessary to signal. A= nd we have other protocols to define the operations and even schemas for th= is - Communication of signaling thresholds or conditions - in scope - Authentication of signaling channel - in scope Authentication is in scope, I would suggest it's required to participat= e. - Specific flow stats and flow awareness - not in scope because it= is not DDoS and there are other protocols that represent this kind of info I kind of see this item as going along with Communication of signaling = thresholds mentioned above. How do you know you are not surpassing or takin= g full advantage of mitigation without knowing if you are at, near, or abov= e the signaling thresholds? Could you share what current protocols you are referring to? - DDoS attack representation - in-scope because it is DDoS. Of co= urse, if a device can't classify the attack because it is either not that k= ind of device or it is a new attack, then we need a way for this to indicat= e 'unknown' Verification. This ,so far, is a two part issue. * As part of authentication, we need some way to verify the aut= henticating parties and agree upon authentication methods. * How do I verify the DDoS parameters defined downstream are ap= plicable and valid? What's in place to prevent a CPE from sending invalid D= DoS representation? The CPE could have been compromised or the owner of the= CPE may try to send data that falsely blames a competitor and thus ends up= allowing for a DoS of said competitor. [Frank] : I'd like to think the CPE is trusted if it's a authenticated peer= . It's the traditional authentication way, isn't it? Thanks, --John Schiel Looking forward to good discussion and the development of a good RFC. Regards, Scott From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com] Sent: Tuesday, April 07, 2015 11:37 PM To: Dave Larson; Teague, Nik; Scott Barvick Cc: dots@ietf.org Subject: RE: [Dots] DOTS work scope discussion: //RE: scope Hi Dave, I totally agree with you the point that focus DOTS's scope on DDoS in the f= irst stage. It's a reasonable way we push the WG work. Please see my response inline: B.R. Frank From: Dave Larson [mailto:Dave.Larson@corero.com] Sent: Wednesday, April 08, 2015 10:17 AM To: Xialiang (Frank); Teague, Nik; Scott Barvick Cc: dots@ietf.org Subject: Re: [Dots] DOTS work scope discussion: //RE: scope HI Frank, I think you raise a few vary important points below: On Wednesday, April 1, 2015 at 1:55 AM, "Xialiang (Frank)" > wrote: Here are my thoughts about DOTS works: 1. The devices can be either DDoS mitigation devices, or normal netwo= rk devices (router, switch). This will make the whole DOTS solution more ge= neral for different scenarios. For example, current two drafts within DOTS = can represent this difference. Maybe, we need an use case draft to elaborat= e their respective values; 2. I agree that upstream systems need to negotiate its requirements o= r capabilities to reporting devices. This feature can save the signaling tr= affics. It means an initialized negotiation mechanism may be needed; 3. A mutual authentication mechanism is needed to protect the communi= cations between the legal senders and receivers, to avoid the faked signali= ng, fault peers, or creating new DDoS attacks, etc; 4. To cope with the rapid evolution and change of the attack types, t= he DOTS solution should consider the capability of openness. Which means th= e specified information model should have the capability in semantic to def= ine and express the new attack information; 5. The whole architecture should not be constrained in our proposed s= cenarios, it can be more general, more comprehensive. For example, more dev= ices construct a mesh network to support the DOTS functions. My thoughts are: 1. I agree. We want to be inclusive on what kinds of devices may signal. = And use cases are a great way to encapsulate the problem space. Though I = would not try to extend the problem space beyond DDoS. 2. I agree. I think this is really bidirectional - I can imagine both end= s of the connection advertising capabilities. I can see the edge systems (= downstream) also advertising what they are capable of signaling and this wo= uld vary depending on the types of devices as you point out in point 1. [Frank] : Agree with the bidirectional negotiation requirement! 3. Authentication is critical to avoid the fake signaling problem you have= pointed out - I believe this received some discussion during the BOF in Da= llas.. Whatever we do with this project, It can not introduce a new DDoS ve= ctor by failing to account for this. 4. I believe all participants in the BOF would support openness for attack= type definition. But I also heard strong support for constraining the pro= blem space initially to DDoS. In fact, my opinion, as stated at the BOF, i= s that the most important component of this project is the schema. A conci= se schema that can accommodate all currently known DDoS vectors and a schem= a that is also extensible should be a primary goal for us. [Frank] :yes, you raise the key point - a concise schema also with the exte= nsibility! And I hope these two goals can be achieved all, by pre-considera= tion and good design. 5. I'm not sure I follow the suggestion of a mesh network here. Similar t= o point 4, I believe it is important to get the downstream-to-upstream sign= aling correct before complicating with mesh topology considerations. In fa= ct, to further enforce my point above, I think schema is more important tha= n topology considerations at first. I think it is critical for us to offer= something that can be tested and proven in the simplest networks that can = show the benefit. But your point about openness can not be understated - t= his must be open and extensible. [Frank] : Like you state here, what I propose here is about the topology an= d architecture aspects. I agree that this point is a little far than the sc= heme work. We can consider it later. I have copied a colleague of mine, Scott Barvick. Scott was unable to atte= nd the BOF but has been working on these concepts with me and will likely h= ave some opinions in these areas to share with the thread. [Frank] : Welcome, Scott~~ Regards, Dave Larson _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB0F49SZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi John,

Please see= inline:

Thanks!

 = ;

B.R.<= /o:p>

Frank=

 = ;

From:= Dots [mailto:dots-b= ounces@ietf.org] On Behalf Of John
Sent: Wednesday, April 08, 2015 11:42 PM
To: dots@ietf.org
Subject: Re: [Dots] DOTS work scope discussion: //RE: scope

 

= Hello,

    Sorry I'm late to this discussion but I've recently lear= ned of this effort and I'm very interested in the topic. If my questions ha= ve already been addressed and I missed where this was previously discussed,= I'm apologize for raising the issue again and I would appreciate being directed to where the question was answered or di= scussed.

Please see inline.

On 04/08/2015 08:36 AM, Scott B= arvick wrote:

Thanks for= the intro and welcome.     From the reading of the min= utes and the thread, it seems that we can and should be using the words = 216;DDoS’ and ‘signaling’  along with not overlapping with other IE= TF work to help us check our activities against a focus that will allow us = to get chartered as a WG and then make the required progress towards goals = that we will have as one.   If it is not directly contributing to the signaling of DDoS threats/conditions/capabilities then= we really should really not be spending any time on it.    = As examples (for discussion, of course)

 

-     =      DD= oS capabilities negotiation between the communicating parties -  in sc= ope because it affects what can be signaled or needs to be done on either side

-     =      Co= nfiguration or provisioning of the devices for DDoS – not in scope be= cause while it is DDoS, it is beyond what is necessary to signal.  And we have other protocols to define the operations and even schemas for = this

-     =      Co= mmunication of signaling thresholds or conditions – in scope

-     =      Au= thentication of signaling channel – in scope

    Authenticati= on is in scope, I would suggest it's required to participate.

-     =      Sp= ecific flow stats and flow awareness – not in scope because it is not= DDoS and there are other protocols that represent this kind of info

    I kind of se= e this item as going along with Communication of signaling thresholds menti= oned above. How do you know you are not surpassing or taking full advantage= of mitigation without knowing if you are at, near, or above the signaling thresholds?

    Could you share what current protocols you are referring= to?


-     =      DD= oS attack representation – in-scope because it is DDoS.  Of cour= se, if a device can’t classify the attack because it is either not that kind of device or it is a new attack, then we need a way for this to = indicate ‘unknown’

Ve= rification. This ,so far, is a two part issue.
            * As part of authe= ntication, we need some way to verify the authenticating parties and agree = upon authentication methods.
            * How do I verify = the DDoS parameters defined downstream are applicable and valid? What's in = place to prevent a CPE from sending invalid DDoS representation? The CPE co= uld have been compromised or the owner of the CPE may try to send data that= falsely blames a competitor and thus ends up allowing for a DoS of said competitor= .

[Fra= nk] : I’d like to think the CPE is trusted if it’s a authentica= ted peer. It’s the traditional authentication way, isn’t it?


Thanks,

--John Schiel
 

 

Looking fo= rward to good discussion and the development of a good RFC.

 

Regards,

Scott

 

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Tuesday, April 07, 2015 11:37 PM
To: Dave Larson; Teague, Nik; Scott Barvick
Cc: dots@ietf.org
Subject: RE: [Dots] DOTS work scope discussion: //RE: scope

 

Hi Dave,

I totally = agree with you the point that focus DOTS’s scope on DDoS in the first= stage. It’s a reasonable way we push the WG work.

Please see= my response inline:

 

B.R.

Frank

 

From: Dave Larson [mailto:Dave.Larson@corero.com]
Sent: Wednesday, April 08, 2015 10:17 AM
To: Xialiang (Frank); Teague, Nik; Scott Barvick
Cc: dots@ietf.org
Subject: Re: [Dots] DOTS work scope discussion: //RE: scope

 

HI Frank,

 

I think you raise a few = vary important points below:<= /p>

 

On Wednesday, April 1, 2= 015 at 1:55 AM, "Xialiang (Frank)" <frank.xialiang@huawei.com> wrote:

 

Here are my thoughts abo= ut DOTS works:

1.     &nbs= p; The devices can be either = DDoS mitigation devices, or normal network devices (router, switch). This w= ill make the whole DOTS solution more general for different scenarios. For example, current two drafts within DOTS can represent this = difference. Maybe, we need an use case draft to elaborate their respective = values;

2.     &nbs= p; I agree that upstream syst= ems need to negotiate its requirements or capabilities to reporting devices= . This feature can save the signaling traffics. It means an initialized negotiation mechanism may be needed;

3.     &nbs= p; A mutual authentication me= chanism is needed to protect the communications between the legal senders a= nd receivers, to avoid the faked signaling, fault peers, or creating new DDoS attacks, etc;<= /span>

4.     &nbs= p; To cope with the rapid evo= lution and change of the attack types, the DOTS solution should consider th= e capability of openness. Which means the specified information model should have the capability in semantic to define and express the new= attack information;

5.     &nbs= p; The whole architecture sho= uld not be constrained in our proposed scenarios, it can be more general, m= ore comprehensive. For example, more devices construct a mesh network to support the DOTS functions.

 

My thoughts are:

 

1.  I agree.  = We want to be inclusive on what kinds of devices may signal.  And use = cases are a great way to encapsulate the problem space.  Though I woul= d not try to extend the problem space beyond DDoS.

 

2.  I agree.  = I think this is really bidirectional – I can imagine both ends of the= connection advertising capabilities.  I can see the edge systems (dow= nstream) also advertising what they are capable of signaling and this would vary de= pending on the types of devices as you point out in point 1.

[Fra= nk] : Agree with the bidirectional negotiation requirement!<= span lang=3D"EN-US">

 

3.  Authentication = is critical to avoid the fake signaling problem you have pointed out –= ; I believe this received some discussion during the BOF in Dallas.. Whatever we do with this project, It can not introduce a new DDoS vector b= y failing to account for this.

 

4.  I believe all p= articipants in the BOF would support openness for attack type definition. &= nbsp;But I also heard strong support for constraining the problem space initially to DDoS.  In fact, my opinion, as stated at the BOF, is tha= t the most important component of this project is the schema.  A conci= se schema that can accommodate all currently known DDoS vectors and a schem= a that is also extensible should be a primary goal for us.

[Fra= nk] :yes, you raise the key point – a concise schema also with the ex= tensibility! And I hope these two goals can be achieved all, by pre-consideration and good design.

 

5.  I’m not s= ure I follow the suggestion of a mesh network here.  Similar to point = 4, I believe it is important to get the downstream-to-upstream signaling co= rrect before complicating with mesh topology considerations.  In fact, to f= urther enforce my point above, I think schema is more important than topolo= gy considerations at first.  I think it is critical for us to offer so= mething that can be tested and proven in the simplest networks that can show the benefit.  But your point about op= enness can not be understated – this must be open and extensible.

[Fra= nk] : Like you state here, what I propose here is about the topology and ar= chitecture aspects. I agree that this point is a little far than the scheme work. We can consider it later.

 

I have copied a colleagu= e of mine, Scott Barvick.  Scott was unable to attend the BOF but has = been working on these concepts with me and will likely have some opinions in these areas to share with the thread.

[Fra= nk] : Welcome, Scott~~

 

Regards,

 

Dave Larson

 

 




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

 
--_000_C02846B1344F344EB4FAA6FA7AF481F12ADB0F49SZXEMA502MBSchi_-- From nobody Wed Apr 8 20:07:35 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2D31B2B80 for ; Wed, 8 Apr 2015 20:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lv9pEFqKvxS3 for ; Wed, 8 Apr 2015 20:07:29 -0700 (PDT) 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 35B2D1B2B72 for ; Wed, 8 Apr 2015 20:07:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUQ29682; Thu, 09 Apr 2015 03:07:26 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Apr 2015 04:07:25 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.144]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Thu, 9 Apr 2015 11:07:18 +0800 From: "Xialiang (Frank)" To: Scott Barvick , Andrew Mortensen Thread-Topic: [Dots] DOTS work scope discussion: //RE: scope Thread-Index: AQHQcaIhLzQhJpbEDkS5B/rKwQEkFp1CchIQgAC3VGD//7fkgIAAlCIAgACKwEA= Date: Thu, 9 Apr 2015 03:07:18 +0000 Message-ID: References: <6073823821667642A5C884FF3A8807F81F3C7B14@MERCURY.corero.com> <0F4D9F9B-FF90-431A-BC8D-5DF6D0A478C5@arbor.net> 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.42.200] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12ADB0F66SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Nik Teague , Dave Larson , "dots@ietf.org" Subject: Re: [Dots] DOTS work scope discussion: //RE: scope X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 03:07:34 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB0F66SZXEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott, You are pointing out another condition that need to signal. In this condition, the signaling is more about the flow info than the DDoS = attack info. B.R. Frank From: Scott Barvick [mailto:Scott.Barvick@corero.com] Sent: Thursday, April 09, 2015 10:47 AM To: Andrew Mortensen Cc: Xialiang (Frank); Dave Larson; Nik Teague; dots@ietf.org Subject: Re: [Dots] DOTS work scope discussion: //RE: scope Lots of good discussion that I'm sure will continue. Of course we'll need= to break each topic into different threads and drill into each. Another topic that Andrew is surfacing is in the statement below The minimum requirement seems to me just the ability to signal whether the = on-premise device wants help. This is currently encoded as the "SOS" field = in the signal to the upstream element. I noticed a similar sentiment in the current draft: These elements may be required from time to time to signal to an upstream component or provider that the capabilities of the device are exceeded and that an offramping of attack traffic to a more capable element or infrastructure is desired or required. It might be assumed but I think it needs explicitly called out in the overv= iew and goals that the on-premise device may not need help mitigating per s= e, but signaling may be necessary to potentially off-ramp traffic because t= he upstream link is saturated. Even a box that can handle a full load of = DDoS traffic cannot do anything to help good traffic if the upstream pipe t= o it is full. In that case, signaling can cause rerouting of all or certa= in traffic to free the link to allow valid traffic to start to flow again. = This is, of course, another case where a channel and protocol that can ge= t information out under stressful circumstances will be necessary. Scott On Apr 8, 2015, at 1:56 PM, Andrew Mortensen > wrote: On Apr 8, 2015, at 10:36 AM, Scott Barvick > wrote: ... If it is not directly contributing to the signaling of DDoS threats/con= ditions/capabilities then we really should really not be spending any time = on it. As examples (for discussion, of course) Thanks for drawing up this list of examples as discussion points. - DDoS capabilities negotiation between the communicating parties = - in scope because it affects what can be signaled or needs to be done on = either side I'm less sure about this. Trying to encode DDoS mitigation capabilities see= ms like an exercise in futility, as the state of the art is already racing = to keep up with attack innovation. Any upstream services implementing DOTS = are indicating mitigation capability. Not all upstream services will be equ= al, of course, but upstream capabilities seem out of scope: the goal of DOT= S, as I understand it, is to provide a standard way for downstream mitigati= on/detection devices to request intervention upstream. What upstream does-or even can do-on receipt of a distress call from downst= ream beyond DOTS. Upstream elements are of course under no obligation to mi= tigate the attack when it's requested by the on-premise device, and the dow= nstream on-premise mitigation/detection device is under no obligation to re= quest upstream help when under attack. Given cost concerns-and upstream int= ervention is likely to have associated cost-a downstream network operator i= s going to want to have the option to control whether mitigation upstream i= s enabled for their network. - Configuration or provisioning of the devices for DDoS - not in s= cope because while it is DDoS, it is beyond what is necessary to signal. A= nd we have other protocols to define the operations and even schemas for th= is Agreed, this is far afield from DOTS. Far more in scope for NETCONF & co. - Communication of signaling thresholds or conditions - in scope The minimum requirement seems to me just the ability to signal whether the = on-premise device wants help. This is currently encoded as the "SOS" field = in the signal to the upstream element. In my view the need for downstream c= ontrol over whether upstream mitigation is enabled means signaling threshol= ds for automitigation upstream should be optional. - Authentication of signaling channel - in scope Critical, and attack conditions-extremely congested link-are going help sha= pe the form this takes. - Specific flow stats and flow awareness - not in scope because it= is not DDoS and there are other protocols that represent this kind of info Maybe more importantly, they aren't going to get through a congested channe= l to any upstream element reliably. - DDoS attack representation - in-scope because it is DDoS. Of co= urse, if a device can't classify the attack because it is either not that k= ind of device or it is a new attack, then we need a way for this to indicat= e 'unknown' In scope, but not required. It is undoubtedly useful information for the up= stream service, but is not a requirement before upstream can begin mitigati= ng. At a minimum, a downstream on-premise device should at need be able req= uest mitigation and request mitigation deactivation. andrew --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB0F66SZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Scott,<= o:p>

You are po= inting out another condition that need to signal.

In this co= ndition, the signaling is more about the flow info than the DDoS attack inf= o.

 = ;

B.R.<= /o:p>

Frank=

 = ;

From: Scott Barvick [mailto:Scott.Barvick@corero.com]
Sent: Thursday, April 09, 2015 10:47 AM
To: Andrew Mortensen
Cc: Xialiang (Frank); Dave Larson; Nik Teague; dots@ietf.org
Subject: Re: [Dots] DOTS work scope discussion: //RE: scope

 

Lots of good discussion that I&= #8217;m sure will continue.   Of course we’ll need to break each= topic into different threads and drill into each.   <= /span>

 

Another topic that Andrew is su= rfacing is in the statement below

The minimum requirement seems t= o me just the ability to signal whether the on-premise device wants help. T= his is currently encoded as the “SOS” field in the signal to th= e upstream element. 

 

I noticed a similar sentiment i= n the current draft:

 

These elements may
be required from time to time to signal to an upstream compone=
nt or
provider that the capabilities of the device are exceeded and =
that an
offramping of attack traffic to a more capable element or=

infrastructure is desired or required.

 

It might be assumed but I think= it needs explicitly called out in the overview and goals that the on-premi= se device may not need help mitigating per se, but signaling may be necessa= ry to potentially off-ramp traffic because the upstream link is saturated.   Even a box that can handle a full l= oad of DDoS traffic cannot do anything to help good traffic if the upstream= pipe to it is full.   In that case, signaling can cause rerouting of = all or certain traffic to free the link to allow valid traffic to start to flow again.   This is, of course, ano= ther case where a channel and protocol that can get information out under s= tressful circumstances will be necessary.

 

Scott

 

On Apr 8, 2015, at 1:56 PM, And= rew Mortensen <amortensen@arbor.= net> wrote:



 

On Apr 8, 2015, at 10:36 AM, Sc= ott Barvick <Scott.Barvick@c= orero.com> wrote:

 

… If= it is not directly contributing to the signaling of DDoS threats/condition= s/capabilities then we really should really not be spending any time on it.    As examples (for discussion, of course)

 

Thanks for drawing up this list= of examples as discussion points.

 

-          DDoS capabilities negotiation between the communicating parties -  in scop= e because it affects what can be signaled or needs to be done on either sid= e

 

I’m less sure about this.= Trying to encode DDoS mitigation capabilities seems like an exercise in fu= tility, as the state of the art is already racing to keep up with attack in= novation. Any upstream services implementing DOTS are indicating mitigation capability. Not all upstream services will = be equal, of course, but upstream capabilities seem out of scope: the goal = of DOTS, as I understand it, is to provide a standard way for downstream mi= tigation/detection devices to request intervention upstream.

 

What upstream does—or eve= n can do—on receipt of a distress call from downstream beyond DOTS. U= pstream elements are of course under no obligation to mitigate the attack w= hen it’s requested by the on-premise device, and the downstream on-premise mitigation/detection device is under no obligati= on to request upstream help when under attack. Given cost concerns—an= d upstream intervention is likely to have associated cost—a downstrea= m network operator is going to want to have the option to control whether mitigation upstream is enabled for their net= work.

 

-          Configuration or provisioning of the devices for DDoS – not in scope because while= it is DDoS, it is beyond what is necessary to signal.  And we have ot= her protocols to define the operations and even schemas for this

 

Agreed, this is far afield from= DOTS. Far more in scope for NETCONF & co.



-          Communication of signaling thresholds or conditions – in scope

 

The minimum requirement seems t= o me just the ability to signal whether the on-premise device wants help. T= his is currently encoded as the “SOS” field in the signal to th= e upstream element. In my view the need for downstream control over whether upstream mitigation is enabled means signaling thresh= olds for automitigation upstream should be optional.



-          Authentication of signaling channel – in scope

 

Critical, and attack conditions= —extremely congested link—are going help shape the form this ta= kes.



-          Specific flow stats and flow awareness – not in scope because it is not DDoS = and there are other protocols that represent this kind of info

 

Maybe more importantly, they ar= en't going to get through a congested channel to any upstream element relia= bly.



-          DDoS attack representation – in-scope because it is DDoS.  Of course= , if a device can’t classify the attack because it is either not that= kind of device or it is a new attack, then we need a way for this to indic= ate ‘unknown’

 

In scope, but not required. It = is undoubtedly useful information for the upstream service, but is not a re= quirement before upstream can begin mitigating. At a minimum, a downstream = on-premise device should at need be able request mitigation and request mitigation deactivation.

 

andrew

 

--_000_C02846B1344F344EB4FAA6FA7AF481F12ADB0F66SZXEMA502MBSchi_-- From nobody Wed Apr 8 22:00:00 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3651ACE5D for ; Wed, 8 Apr 2015 21:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjLtvR4iyKVt for ; Wed, 8 Apr 2015 21:59:55 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F431AD0F0 for ; Wed, 8 Apr 2015 21:59:22 -0700 (PDT) Received: by iejt8 with SMTP id t8so20097861iej.2 for ; Wed, 08 Apr 2015 21:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=IxpUILjITNziGg9W9TAK6jq8q8cUkfPKLtqOk4dt0HA=; b=cR+ZZXyCsBx8+evTGfIOWNTwVUPcY6Dxr5KZGEHIFEMStOR2pYfDa5f0JiiYuua0rS DqCJS65GVCkpFa6YQL1chgAVJ5ybldhzAHIHmc/R2y1vQ37Fram75Hrp3lkrSHhZ7qx/ XR1ggCHvPnMptTUK73PyGiOu/E+Lta1Vkgk7s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=IxpUILjITNziGg9W9TAK6jq8q8cUkfPKLtqOk4dt0HA=; b=EmCQsUTX/9clo+TpOj3wHfWF+vtdmGcL2ly7rVpj5Vk7fMMa8Ya86StXo7JN/kginM cHCOqyeNs7R8iXTFWVsOqjy4oM9NROXUOqsVpFmHwPt4F22QXZoioUKjS197epBr6ThY Z5z6MkTPaEVzwjdkxwNXLk4OdQR/+spnxpSwroNuI0Td+HTh2MfCeVUEWnsTDbYu1NBj xR+2R6/pQGsgI+C/zUpFqK/RhdmELGn7iW/ir3IBP7FwunUDTA7pLGtUVsAeWM4AKRW4 axHSCkyhr4Kl0TltiySIojLAsOez3bRQ6SW0URoP+KpztHagEGY4o4QQsku0GORp+FXl EcNA== X-Gm-Message-State: ALoCoQmLyiSiuyUe8U5fvwwzYisYcKI86Er7NI7LAr7WBrkSMvx/hxI+/tbVY5lIEQ/DHJEDKdQN X-Received: by 10.42.88.206 with SMTP id d14mr37310243icm.40.1428555561746; Wed, 08 Apr 2015 21:59:21 -0700 (PDT) Received: from [192.168.4.244] (ip-64-134-100-92.public.wayport.net. [64.134.100.92]) by mx.google.com with ESMTPSA id w3sm8268131igz.1.2015.04.08.21.59.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Apr 2015 21:59:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_22473C30-99EB-40E9-BAF4-EE839A3505BE" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Andrew Mortensen In-Reply-To: Date: Thu, 9 Apr 2015 00:59:20 -0400 Message-Id: <1C31808C-177B-40B6-B83A-7A066203B857@arbor.net> References: <6073823821667642A5C884FF3A8807F81F3C7B14@MERCURY.corero.com> <0F4D9F9B-FF90-431A-BC8D-5DF6D0A478C5@arbor.net> To: "Xialiang (Frank)" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "Teague, Nik" , Scott Barvick , Dave Larson , "dots@ietf.org" Subject: Re: [Dots] DOTS work scope discussion: //RE: scope X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 04:59:58 -0000 --Apple-Mail=_22473C30-99EB-40E9-BAF4-EE839A3505BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the comments, Frank. See my notes inline. > From: Andrew Mortensen [mailto:amortensen@arbor.net = ]=20 > > - DDoS capabilities negotiation between the communicating = parties - in scope because it affects what can be signaled or needs to = be done on either side > =20 > I=E2=80=99m less sure about this. Trying to encode DDoS mitigation = capabilities seems like an exercise in futility, as the state of the art = is already racing to keep up with attack innovation. Any upstream = services implementing DOTS are indicating mitigation capability. Not all = upstream services will be equal, of course, but upstream capabilities = seem out of scope: the goal of DOTS, as I understand it, is to provide a = standard way for downstream mitigation/detection devices to request = intervention upstream. > [Frank] : At least, in the multiple upstreams condition, the awareness = of every upstream=E2=80=99s capability by downstream can help it make = the right choice. So, the bidirectional negotiation mechanism is useful = for making the whole solution more smart and efficient. But how to = represent the capability and in which granularity is indeed a question. = I tend to choose a coarse-grained category for applicability. Even leaving aside the Sisyphean task of trying to negotiate with = upstream elements when the target network=E2=80=99s links are congested, = it seems misguided to base the decision of where to send a signal for = help on uncertified and necessarily abstract capabilities advertised = from upstream. When to mitigate, and whom to ask for help mitigating, should be left up = to network operators. (This can of course include automitigation, as the = operator will just have made the decisions beforehand.) > What upstream does=E2=80=94or even can do=E2=80=94on receipt of a = distress call from downstream beyond DOTS. Upstream elements are of = course under no obligation to mitigate the attack when it=E2=80=99s = requested by the on-premise device, and the downstream on-premise = mitigation/detection device is under no obligation to request upstream = help when under attack. Given cost concerns=E2=80=94and upstream = intervention is likely to have associated cost=E2=80=94a downstream = network operator is going to want to have the option to control whether = mitigation upstream is enabled for their network. > [Frank] : Due to the upstream intervention is associated cost, the = downstream device is more likely to depend on the negotiation mechanism = to help it choose the suitable upstream. I=E2=80=99d very much like to avoid trying to standardize what amount to = business negotiations on behalf of network owners. When the target network is under attack, the measurable result of a = request for help will be reduced load. The ultimate judge of the need = for mitigation, its effectiveness, its duration, and its value will be = the network owners who requested intervention in the first place. > >=20 > - Specific flow stats and flow awareness =E2=80=93 not in = scope because it is not DDoS and there are other protocols that = represent this kind of info > =20 > Maybe more importantly, they aren't going to get through a congested = channel to any upstream element reliably. > [Frank] : I cannot totally agree with this point. In addition to the = precise attack info inspected by the DDoS mitigation device, the = specific flow stats info inspected by the normal network devices (i.e., = router, switch) are also very valuable for the upstream platform to be = aware of what happen in network and what to do then. We should consider = a general use case, and not exclude the network devices out of the = scope. There are plenty of devices out there designed to perform flow analysis = and derive intelligence from it, including attack detection. Such = devices would be natural DOTS clients, well-positioned to signal for = upstream intervention when attacks are detected. But it sounds like instead of using on-premise collectors, you=E2=80=99re = suggesting sampled flow should be exported upstream during attack. Is = that accurate? > - DDoS attack representation =E2=80=93 in-scope because it is = DDoS. Of course, if a device can=E2=80=99t classify the attack because = it is either not that kind of device or it is a new attack, then we need = a way for this to indicate =E2=80=98unknown=E2=80=99 > =20 > In scope, but not required. It is undoubtedly useful information for = the upstream service, but is not a requirement before upstream can begin = mitigating. At a minimum, a downstream on-premise device should at need = be able to request mitigation and request mitigation deactivation. > [Frank] : By my understanding, an important goal of DOTS work is to = improve the security intelligence sharing among the whole network = security ecosystem. So, how to represent the DDoS attacks and sharing = them is a very useful work. So, definitely, it should be in scope, and = the DDoS attack info should be shared among the federal peers in time. = For the new attack, to indicate =E2=80=98unknown=E2=80=99 is the default = method, but it is also possible to better represent them by using some = good design and extensible information scheme This sounds a lot like MILE, no? https://datatracker.ietf.org/wg/mile/charter/ You=E2=80=99ll get no argument from me that representing and sharing = DDoS attack profiles is useful work. The scope of that work is enormous, = though, and DOTS is focused on the signaling aspect: providing (in my = view) minimally necessary information to an upstream element to signal = the need for aid fighting off an attack. What =E2=80=9Cminimally = necessary=E2=80=9D means remains a matter for debate, of course, but in = my mind that excludes a great deal of the sort of rich information that = would be fully in-scope for something like MILE. andrew= --Apple-Mail=_22473C30-99EB-40E9-BAF4-EE839A3505BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the comments, Frank. See my notes inline.

 From: Andrew Mortensen [mailto:amortensen@arbor.net] 
<snip>
-          DDoS capabilities negotiation between the = communicating parties -  in scope because it affects what can be = signaled or needs to be done on either side
 
I=E2=80=99m less sure about = this. Trying to encode DDoS mitigation capabilities seems like an = exercise in futility, as the state of the art is already racing to keep = up with attack innovation. Any upstream services implementing DOTS are = indicating mitigation capability. Not all upstream services will be = equal, of course, but upstream capabilities seem out of scope: the goal = of DOTS, as I understand it, is to provide a standard way for downstream = mitigation/detection devices to request intervention upstream.
[Frank] : At least, in the multiple upstreams condition, the = awareness of every upstream=E2=80=99s capability by downstream can help = it make the right choice. So, the bidirectional negotiation mechanism is = useful for making the whole solution more smart and efficient. But how = to represent the capability and in which granularity is indeed a = question. I tend to choose a coarse-grained category for = applicability.

Even leaving aside the Sisyphean task = of trying to negotiate with upstream elements when the target = network=E2=80=99s links are congested, it seems misguided to base the = decision of where to send a signal for help on uncertified and = necessarily abstract capabilities advertised from = upstream.

When to mitigate, and whom = to ask for help mitigating, should be left up to network operators. = (This can of course include automitigation, as the operator will just = have made the decisions beforehand.)


 What = upstream does=E2=80=94or even can do=E2=80=94on receipt of a distress = call from downstream beyond DOTS. Upstream elements are of course under = no obligation to mitigate the attack when it=E2=80=99s requested by the = on-premise device, and the downstream on-premise mitigation/detection = device is under no obligation to request upstream help when under = attack. Given cost concerns=E2=80=94and upstream intervention is likely = to have associated cost=E2=80=94a downstream network operator is going = to want to have the option to control whether mitigation upstream is = enabled for their network.
[Frank] : Due to the = upstream intervention is associated cost, the downstream device is more = likely to depend on the negotiation mechanism to help it choose the = suitable = upstream.
I=E2=80=99d very much like to avoid trying to = standardize what amount to business negotiations on behalf of network = owners.

When the target network is = under attack, the measurable result of a request for help will be = reduced load. The ultimate judge of the need for mitigation, its = effectiveness, its duration, and its value will be the network owners = who requested intervention in the first place.


<snip>

-          Specific flow stats and flow awareness =E2=80= =93 not in scope because it is not DDoS and there are other protocols = that represent this kind of info
 
Maybe more importantly, they = aren't going to get through a congested channel to any upstream element = reliably.
[Frank] : I cannot totally agree with this = point. In addition to the precise attack info inspected by the DDoS = mitigation device, the specific flow stats info inspected by the normal = network devices (i.e., router, switch) are also very valuable for the = upstream platform to be aware of what happen in network and what to do = then. We should consider a general use case, and not exclude the network = devices out of the = scope.

There are plenty of devices out there = designed to perform flow analysis and derive intelligence from it, = including attack detection. Such devices would be natural DOTS clients, = well-positioned to signal for upstream intervention when attacks are = detected.

But it sounds like instead = of using on-premise collectors, you=E2=80=99re suggesting sampled flow = should be exported upstream during attack. Is that = accurate?


-          DDoS attack representation =E2=80=93 = in-scope because it is DDoS.  Of course, if a device can=E2=80=99t = classify the attack because it is either not that kind of device or it = is a new attack, then we need a way for this to indicate = =E2=80=98unknown=E2=80=99
 
In scope, but not required. = It is undoubtedly useful information for the upstream service, but is = not a requirement before upstream can begin mitigating. At a minimum, a = downstream on-premise device should at need be able to request = mitigation and request mitigation deactivation.
[Frank] : By my understanding, an important goal of DOTS work = is to improve the security intelligence sharing among the whole network = security ecosystem. So, how to represent the DDoS attacks and sharing = them is a very useful work. So, definitely, it should be in scope, and = the DDoS attack info should be shared among the federal peers in time. = For the new attack, to indicate =E2=80=98unknown=E2=80=99 is the default = method, but it is also possible to better represent them by using some = good design and extensible information = scheme

This sounds a lot like = MILE, no?

https://datatracker.ietf.org/wg/mile/charter/

You=E2=80=99ll get no = argument from me that representing and sharing DDoS attack profiles is = useful work. The scope of that work is enormous, though, and DOTS is = focused on the signaling aspect: providing (in my view) minimally = necessary information to an upstream element to signal the need for aid = fighting off an attack. What =E2=80=9Cminimally necessary=E2=80=9D means = remains a matter for debate, of course, but in my mind that excludes a = great deal of the sort of rich information that would be fully in-scope = for something like MILE.

andrew
= --Apple-Mail=_22473C30-99EB-40E9-BAF4-EE839A3505BE-- From nobody Wed Apr 8 22:12:28 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB98C1B2ADB for ; Wed, 8 Apr 2015 22:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVZoFXTMztZF for ; Wed, 8 Apr 2015 22:12:26 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C301B2B0D for ; Wed, 8 Apr 2015 22:11:54 -0700 (PDT) Received: by igblo3 with SMTP id lo3so56339163igb.0 for ; Wed, 08 Apr 2015 22:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=7jz3IkcUxFU9qpoyT5W/cn/KMnBQo4b8DFphq67JNM8=; b=bcJpN+XrkDcXJvUQqrnhnMfUvBXDR0X2kioTnhjRnEKcF+jr0Q0yHBT8XyloVx9dto Pktv5PvVHUDanH4hG9cWCad9sDlE4ZCCSqjk315PwUFwOMknvZiPh8EUiBty/X+wwD/r wFPPVnNDgObIvnBeg7JEbffLeKFGsHZgxFr/U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=7jz3IkcUxFU9qpoyT5W/cn/KMnBQo4b8DFphq67JNM8=; b=LiHwvDSYm6F9AvebWElfxPrvEym8dj8VqrKlP6ncJBYo7sCeqNGX7KOtD486jl/LRZ 2mm3WASoGGBgsV2iwHGivpkD1fBdFkkMZpw4pngb+lg12C964kDiYuQj3crJUQ+w+Ctn TYJwlKqvy/Y4xkRZkNVnbaTtUl8Ej5ipBvuskOqXD+Inm0TpFopOqe+kIsi91R3zyvbw cmPoDuXtQaP3rvDpK1DsomX074lrqTMZcOid/Lbhs24K/ni23BRifLMt8GXZP+1dd1D8 +DrZZdLsrNLxTQemio8/wIMZX93V2+4NoeA0PFZVbiT6XNumwiXxQFg/tzywlxAHo/Gw cs1A== X-Gm-Message-State: ALoCoQlvauvwBJoY81Eo+mDhd4MB7J51z7D2iYm0OcFFicJU/qvRRatOzxChVRkG0VcicFgrFjpL X-Received: by 10.107.128.3 with SMTP id b3mr43840214iod.24.1428556313748; Wed, 08 Apr 2015 22:11:53 -0700 (PDT) Received: from [192.168.4.244] (ip-64-134-100-92.public.wayport.net. [64.134.100.92]) by mx.google.com with ESMTPSA id e4sm8224928igx.7.2015.04.08.22.11.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Apr 2015 22:11:52 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3F370B61-D835-4124-91A3-0FE0BD702D65" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Andrew Mortensen In-Reply-To: Date: Thu, 9 Apr 2015 01:11:52 -0400 Message-Id: References: <6073823821667642A5C884FF3A8807F81F3C7B14@MERCURY.corero.com> <0F4D9F9B-FF90-431A-BC8D-5DF6D0A478C5@arbor.net> To: Scott Barvick X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Nik Teague , "Xialiang \(Frank\)" , Dave Larson , "dots@ietf.org" Subject: Re: [Dots] DOTS work scope discussion: //RE: scope X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 05:12:27 -0000 --Apple-Mail=_3F370B61-D835-4124-91A3-0FE0BD702D65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Apr 8, 2015, at 10:46 PM, Scott Barvick = wrote: >=20 > Lots of good discussion that I=92m sure will continue. Of course = we=92ll need to break each topic into different threads and drill into = each. =20 >=20 > Another topic that Andrew is surfacing is in the statement below >> The minimum requirement seems to me just the ability to signal = whether the on-premise device wants help. This is currently encoded as = the =93SOS=94 field in the signal to the upstream element.=20 >=20 >=20 > I noticed a similar sentiment in the current draft: >=20 > These elements may > be required from time to time to signal to an upstream component or > provider that the capabilities of the device are exceeded and that an > offramping of attack traffic to a more capable element or > infrastructure is desired or required. >=20 > It might be assumed but I think it needs explicitly called out in the = overview and goals that the on-premise device may not need help = mitigating per se, but signaling may be necessary to potentially = off-ramp traffic because the upstream link is saturated. Even a box = that can handle a full load of DDoS traffic cannot do anything to help = good traffic if the upstream pipe to it is full. In that case, = signaling can cause rerouting of all or certain traffic to free the link = to allow valid traffic to start to flow again. This is, of course, = another case where a channel and protocol that can get information out = under stressful circumstances will be necessary. Agreed, there are lots of reasons why a network operator may want to = request upstream intervention regardless of the current traffic = conditions. We won=92t be able to spell them all out, but that won=92t = matter as long as we leave control over when to mitigate in the hands of = the downstream network owners. andrew= --Apple-Mail=_3F370B61-D835-4124-91A3-0FE0BD702D65 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Apr 8, 2015, at 10:46 PM, Scott Barvick <Scott.Barvick@corero.com> wrote:

Lots of good discussion that I=92m sure will continue. =   Of course we=92ll need to break each topic into different threads = and drill into each.   

Another topic that Andrew is surfacing is in the = statement below
The minimum requirement seems to me just the ability to signal whether = the on-premise device wants help. This is currently encoded as the =93SOS=94= field in the signal to the upstream element. 

I noticed a similar sentiment in the current = draft:

These elements may
be required from time to time to signal to an upstream component or
provider that the capabilities of the device are exceeded and that an
offramping of attack traffic to a more capable element or
infrastructure is desired or required.

It might be assumed but I think it needs explicitly = called out in the overview and goals that the on-premise device may not = need help mitigating per se, but signaling may be necessary to = potentially off-ramp traffic because the upstream link is saturated.   Even a box that can handle a full load of DDoS traffic cannot do = anything to help good traffic if the upstream pipe to it is full.   = In that case, signaling can cause rerouting of all or certain traffic to = free the link to allow valid traffic to start to flow again.   This is, of course, another case where a channel and = protocol that can get information out under stressful circumstances will = be necessary.

Agreed, there are lots of reasons why a network = operator may want to request upstream intervention regardless of the = current traffic conditions. We won=92t be able to spell them all out, = but that won=92t matter as long as we leave control over when to = mitigate in the hands of the downstream network owners.

andrew
= --Apple-Mail=_3F370B61-D835-4124-91A3-0FE0BD702D65-- From nobody Thu Apr 9 07:34:34 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3397F1A710D for ; Thu, 9 Apr 2015 07:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBTJbjrqBykB for ; Thu, 9 Apr 2015 07:34:32 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 BAF341A86E6 for ; Thu, 9 Apr 2015 07:34:31 -0700 (PDT) Received: by wizk4 with SMTP id k4so94782629wiz.1 for ; Thu, 09 Apr 2015 07:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=XX9wbNOrSXBoSEjiNdTJCjwAJXf/qCUgXVjnVU8Px94=; b=lawmOD7RtGo7VI2wY7lpQUSpC7eKIVqeCgiF5ea3rxplW2coi/vJXPa11eHAAGbalF YfEL82m2b6n+mS1H2M3fs+nMLEjj9o5lJ8el1JqvHqy8sGtSqOZmPROR21kvppIVNmoc iqJCgE6plpieOvTvm7PUBPjH3DLLYSZ7HTVuAA3ryjHvTSjctni7cFtmlDNctr1MIZDR C4IbeHildMoBCfKco5kLUVbhKx3nFPVQ/JbLGaKtds5FnNmzG9M5/qKNHQoglCbX1yI8 aY/F60/eJi1IHuj48SUrLTCwxMrAXF7VotGpVwt9En8NMugdleljjD4rZvZVFfujFqvh w1Og== MIME-Version: 1.0 X-Received: by 10.194.47.165 with SMTP id e5mr12115251wjn.128.1428590070534; Thu, 09 Apr 2015 07:34:30 -0700 (PDT) Received: by 10.194.5.97 with HTTP; Thu, 9 Apr 2015 07:34:30 -0700 (PDT) Date: Thu, 9 Apr 2015 10:34:30 -0400 Message-ID: From: Daniel Migault To: dots@ietf.org Content-Type: multipart/alternative; boundary=047d7b66f8e5af170c05134b8b7a Archived-At: Subject: [Dots] Gap analysis - List of WG X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:34:33 -0000 --047d7b66f8e5af170c05134b8b7a Content-Type: text/plain; charset=UTF-8 Hi, I am trying to figure out a gp analysis with other WG. The list of WG I believe we should consider are: - MILE - I2NSF - SACM - NETCONF - I2RS - SNMP If you think other WG should be listed, I suggest you add it on this threat, I will initiate one thread for each of the WG, so the discussions can be held in different threads. -- Daniel Migault Ericsson --047d7b66f8e5af170c05134b8b7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

= I am trying to figure out a gp analysis with other WG. The list of WG I bel= ieve we should consider are:

=C2=A0=C2=A0=C2=A0 - MILE
=C2=A0=C2=A0=C2=A0 - I2NSF
=C2=A0=C2=A0=C2=A0 - SACM
= =C2=A0=C2=A0=C2=A0 - NETCONF
=C2=A0=C2=A0=C2=A0 - I2RS
= =C2=A0=C2=A0=C2=A0 - SNMP

If you think other WG should be list= ed, I suggest you add it on this threat, I will initiate one thread for eac= h of the WG, so the discussions can be held in different threads.
=C2=A0=

--
=
Daniel Migault
Ericsson
--047d7b66f8e5af170c05134b8b7a-- From nobody Thu Apr 9 07:48:56 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2DB1A8A3D for ; Thu, 9 Apr 2015 07:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7XaeQieuKnD for ; Thu, 9 Apr 2015 07:48:53 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::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 D19E51A89ED for ; Thu, 9 Apr 2015 07:48:52 -0700 (PDT) Received: by wiun10 with SMTP id n10so101129697wiu.1 for ; Thu, 09 Apr 2015 07:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dwjjfqIkXAjBBvVrp2y6NBM8GJh3dpUu1boIWHsOoYs=; b=JpsQKLG0nzDtYLJSNdxWfciCFMoB5K5NC5AeIi7SsmPoRl6PsFrwUkz1QqvxgLywI0 MlvblTLfIIfwfuEPbhd/lIyxT/w/F8hzlclYEa7U73xdmv6epSh0GyTaZjCjV56zTHdB vJs9tHa6oXWsLrlORbVUdziq9oZsMQvNpNiAyshw0ZZO+kcKBJhf9hC40kTBoLF54pgm FKOPUSb891/VlSTd98oLtp/9/OSdUCamdLOxCeh6f+mAzIZp7mb3N9GS3EbOYLeakxqb dQw3kAeD719ZNHdmbNd3hmlbixU3Y1D7ZtscLBNqASz5WO4RTwEspGIEL209wpmig+17 tmNA== MIME-Version: 1.0 X-Received: by 10.194.61.244 with SMTP id t20mr58106506wjr.83.1428590931475; Thu, 09 Apr 2015 07:48:51 -0700 (PDT) Received: by 10.194.5.97 with HTTP; Thu, 9 Apr 2015 07:48:51 -0700 (PDT) Date: Thu, 9 Apr 2015 10:48:51 -0400 Message-ID: From: Daniel Migault To: dots@ietf.org Content-Type: multipart/alternative; boundary=047d7b86e4060002f305134bbffe Archived-At: Subject: [Dots] Gap analysis - I2RS X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:48:54 -0000 --047d7b86e4060002f305134bbffe Content-Type: text/plain; charset=UTF-8 Hi, This thread intends to position DOTS with I2RS. When a DDoS attack is detected by the on premise device the on premise device may trigger a traffic redirection to isolate the inbound flows or redirect the traffic to a DDoS mitigation service hosted in a third party cloud provider (Hybrid Cloud scenario). I see interaction between DOTS and I2RS amd DOTS should rely on I2RS as far as traffic redirection needs to be performed. In other words, DOTS should not deal with routing policies. Is there any opinion on how DOTS should deal with an interface with I2RS, by eventually defining an abstract api? -- Daniel Migault Ericsson --047d7b86e4060002f305134bbffe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

This thread int= ends to position DOTS with I2RS. When a DDoS attack is detected by the on p= remise device the on premise device may trigger a traffic redirection to is= olate the inbound flows or redirect the traffic to a DDoS mitigation servic= e hosted in a third party cloud provider (Hybrid Cloud scenario).

I see interaction between DOTS and I2RS amd DOTS should rely on I2= RS as far as traffic redirection needs to be performed. In other words, DOT= S should not deal with routing policies.

Is there any opinion on ho= w DOTS should deal with an interface with I2RS, by eventually defining an a= bstract api?

--
Daniel Migault
Ericsson<= /div>
--047d7b86e4060002f305134bbffe-- From nobody Thu Apr 9 07:58:52 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13AE1AC3E5 for ; Thu, 9 Apr 2015 07:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeWKp3OoV7Ny for ; Thu, 9 Apr 2015 07:58:48 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5641AC442 for ; Thu, 9 Apr 2015 07:58:41 -0700 (PDT) Received: by wgso17 with SMTP id o17so11217632wgs.1 for ; Thu, 09 Apr 2015 07:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BYfbp3f/wfn0wf34iRjFYXFUHWUKqBG71E9f9CzD/N8=; b=esGO7fu6K8/27sR+sCmDeBRZ3dmGBsz5KCYNBentDYBerIqrYQA6Lk1mdXD5RgkQ/J iakGlVRUdK1qd+x0sDU18sZJZ2fbCAsQsRoF3aU/ZdtHgVDk4h95TufCi1aGc9o6btpH 3W+Fv6I2OFf640a4i7qO9VGXedAHzNrLr4kf4U2E+wYY2YOf7FMPuVOmVPyUfO4pywgf tQscOygU8voXlujWcuUCI+mZYPYJX1WGpvNBFko8MPMrIyJfdmWuhs37Bm9tTJygnmkR Q7IBkptTvJ9aR+MqNopBGX3tJgyDX7wUbfiBUJTQeLxkJz3h0IZZNzLJ8+5KSGgecB8x HAeg== MIME-Version: 1.0 X-Received: by 10.194.192.167 with SMTP id hh7mr61765319wjc.151.1428591519808; Thu, 09 Apr 2015 07:58:39 -0700 (PDT) Received: by 10.194.5.97 with HTTP; Thu, 9 Apr 2015 07:58:39 -0700 (PDT) Date: Thu, 9 Apr 2015 10:58:39 -0400 Message-ID: From: Daniel Migault To: dots@ietf.org Content-Type: multipart/alternative; boundary=047d7b8743f8113fc905134be257 Archived-At: Subject: [Dots] Gap analysis - SNMP X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:58:49 -0000 --047d7b8743f8113fc905134be257 Content-Type: text/plain; charset=UTF-8 Hi, I would like to discuss how to position DOTS with SNMP. DOTS defines that alert should be sent when some flow/cpu loads reach certain level. This looks very similar to an SNMP alert. How do you think DOTS shoud lposition toward SNMP? BR, Daniel -- Daniel Migault Ericsson --047d7b8743f8113fc905134be257 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I would like to disc= uss how to position DOTS with SNMP.

DOTS defines that alert sh= ould be sent when some flow/cpu loads reach certain level. This looks very = similar to an SNMP alert. How do you think DOTS shoud lposition toward SNMP= ?

BR,
Daniel
<= div>
--
Daniel = Migault
Ericsson
--047d7b8743f8113fc905134be257-- From nobody Thu Apr 9 08:19:51 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA7C1A8787 for ; Thu, 9 Apr 2015 08:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBn6I_Gf6Xvc for ; Thu, 9 Apr 2015 08:19:45 -0700 (PDT) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (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 3ED0D1A8739 for ; Thu, 9 Apr 2015 08:19:45 -0700 (PDT) Received: by ignm3 with SMTP id m3so50857006ign.0 for ; Thu, 09 Apr 2015 08:19:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=A68dyQf75S1OnvaDvVTHT389mBXPdjugNXFzE8qqopQ=; b=RLR2Fw81AIUeEaJ8jisGQlthy34Vx5Dvo+1XA3yv3w1Q8/lKG16q44FGHbiTO5TsP7 aLlkjkQiUkfklJL0mT0cbFlZL92S+mSxHpVWToXX5Q4q20ak7dlpkYfqfcx/krgHG3fK VL8gxZQSwWvGGDhFbLWHMYWxd7zWZAJFCRdyogVXzDxDFL5cNVCrNNn6SN+P7v9sQJt9 GhEIaN4u8+n0RrWmPfL3FMVS8d/+Qc7IjeseX7o69TmcKMXJQGS6HAllwoADHK9cmh5f TOLmiF98Blmu1HRZQFmvMv5tpmDlMjuQ0C/ev4MxZFiN1JjszFSgZrfmLWwEfIFQyBst pmRw== X-Gm-Message-State: ALoCoQkVIQjQ9427KNt90TWoasnBop60/Kj+5vUEO4ZyltIw7phdQKbfqrPGH9f4h6TujA3F97Eo X-Received: by 10.50.87.42 with SMTP id u10mr21160451igz.31.1428592784717; Thu, 09 Apr 2015 08:19:44 -0700 (PDT) Received: from localhost.localdomain ([2001:428:1:1:2e0:81ff:fe5c:efd5]) by mx.google.com with ESMTPSA id j2sm8862099ioi.8.2015.04.09.08.19.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 08:19:43 -0700 (PDT) Message-ID: <55269889.1090800@flowtools.net> Date: Thu, 09 Apr 2015 09:19:37 -0600 From: John Schiel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Xialiang (Frank)" References: <6073823821667642A5C884FF3A8807F81F3C7B14@MERCURY.corero.com> <55254C4D.1020608@flowtools.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000005080007000806020100" Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] DOTS work scope discussion: //RE: scope X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 15:19:49 -0000 This is a multi-part message in MIME format. --------------000005080007000806020100 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit inline. On 04/08/2015 08:54 PM, Xialiang (Frank) wrote: > > Hi John, > > Please see inline: > > Thanks! > > B.R. > > Frank > > *From:*Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *John > *Sent:* Wednesday, April 08, 2015 11:42 PM > *To:* dots@ietf.org > *Subject:* Re: [Dots] DOTS work scope discussion: //RE: scope > > Hello, > > Sorry I'm late to this discussion but I've recently learned of > this effort and I'm very interested in the topic. If my questions have > already been addressed and I missed where this was previously > discussed, I'm apologize for raising the issue again and I would > appreciate being directed to where the question was answered or discussed. > > Please see inline. > > On 04/08/2015 08:36 AM, Scott Barvick wrote: > > Thanks for the intro and welcome. From the reading of the > minutes and the thread, it seems that we can and should be using > the words ‘DDoS’ and ‘signaling’ along with not overlapping with > other IETF work to help us check our activities against a focus > that will allow us to get chartered as a WG and then make the > required progress towards goals that we will have as one. If it > is not directly contributing to the signaling of DDoS > threats/conditions/capabilities then we really should really not > be spending any time on it. As examples (for discussion, of course) > > -DDoS capabilities negotiation between the communicating parties - > in scope because it affects what can be signaled or needs to be > done on either side > > -Configuration or provisioning of the devices for DDoS – not in > scope because while it is DDoS, it is beyond what is necessary to > signal. And we have other protocols to define the operations and > even schemas for this > > -Communication of signaling thresholds or conditions – in scope > > -Authentication of signaling channel – in scope > > Authentication is in scope, I would suggest it's required to > participate. > > -Specific flow stats and flow awareness – not in scope because it is > not DDoS and there are other protocols that represent this kind of info > > I kind of see this item as going along with Communication of > signaling thresholds mentioned above. How do you know you are not > surpassing or taking full advantage of mitigation without knowing if > you are at, near, or above the signaling thresholds? > > Could you share what current protocols you are referring to? > > > -DDoS attack representation – in-scope because it is DDoS. Of course, > if a device can’t classify the attack because it is either not that > kind of device or it is a new attack, then we need a way for this to > indicate ‘unknown’ > > Verification. This ,so far, is a two part issue. > * As part of authentication, we need some way to verify > the authenticating parties and agree upon authentication methods. > * How do I verify the DDoS parameters defined downstream > are applicable and valid? What's in place to prevent a CPE from > sending invalid DDoS representation? The CPE could have been > compromised or the owner of the CPE may try to send data that falsely > blames a competitor and thus ends up allowing for a DoS of said > competitor. > > */[Frank] : I’d like to think the CPE is trusted if it’s a > authenticated peer. It’s the traditional authentication way, isn’t it?/* > Frank, This still does not address the issue of a compromised CPE or a malicious CPE owner. The authentication could/would most likely be set up in a normal provisioning. The CPE owner is not at fault initially when setting up the authentication but when the device is compromised, it could be possible for the device to send notification when it should not by the adversary. As for the malicious CPE owner comment, I've found the minutes from ietf 92 and currently working my way through the data. If I have more questions or concerns about whether a customer could falsely initiate any malicious events to a competitor, I'll address those in another thread. Thanks, --John > *//* > > > > Thanks, > > --John Schiel > > > Looking forward to good discussion and the development of a good RFC. > > Regards, > > Scott > > *From:*Xialiang (Frank) [mailto:frank.xialiang@huawei.com] > *Sent:* Tuesday, April 07, 2015 11:37 PM > *To:* Dave Larson; Teague, Nik; Scott Barvick > *Cc:* dots@ietf.org > *Subject:* RE: [Dots] DOTS work scope discussion: //RE: scope > > Hi Dave, > > I totally agree with you the point that focus DOTS’s scope on DDoS in > the first stage. It’s a reasonable way we push the WG work. > > Please see my response inline: > > B.R. > > Frank > > *From:*Dave Larson [mailto:Dave.Larson@corero.com] > *Sent:* Wednesday, April 08, 2015 10:17 AM > *To:* Xialiang (Frank); Teague, Nik; Scott Barvick > *Cc:* dots@ietf.org > *Subject:* Re: [Dots] DOTS work scope discussion: //RE: scope > > HI Frank, > > I think you raise a few vary important points below: > > On Wednesday, April 1, 2015 at 1:55 AM, "Xialiang (Frank)" > > wrote: > > Here are my thoughts about DOTS works: > > 1.The devices can be either DDoS mitigation devices, or normal > network devices (router, switch). This will make the whole DOTS > solution more general for different scenarios. For example, > current two drafts within DOTS can represent this difference. > Maybe, we need an use case draft to elaborate their respective values; > > 2.I agree that upstream systems need to negotiate its requirements > or capabilities to reporting devices. This feature can save the > signaling traffics. It means an initialized negotiation mechanism > may be needed; > > 3.A mutual authentication mechanism is needed to protect the > communications between the legal senders and receivers, to avoid > the faked signaling, fault peers, or creating new DDoS attacks, etc; > > 4.To cope with the rapid evolution and change of the attack types, > the DOTS solution should consider the capability of openness. > Which means the specified information model should have the > capability in semantic to define and express the new attack > information; > > 5.The whole architecture should not be constrained in our proposed > scenarios, it can be more general, more comprehensive. For > example, more devices construct a mesh network to support the DOTS > functions. > > My thoughts are: > > 1. I agree. We want to be inclusive on what kinds of devices may > signal. And use cases are a great way to encapsulate the problem > space. Though I would not try to extend the problem space beyond DDoS. > > 2. I agree. I think this is really bidirectional – I can imagine > both ends of the connection advertising capabilities. I can see the > edge systems (downstream) also advertising what they are capable of > signaling and this would vary depending on the types of devices as you > point out in point 1. > > */[Frank] : Agree with the bidirectional negotiation requirement!/* > > 3. Authentication is critical to avoid the fake signaling problem you > have pointed out – I believe this received some discussion during the > BOF in Dallas.. Whatever we do with this project, It can not introduce > a new DDoS vector by failing to account for this. > > 4. I believe all participants in the BOF would support openness for > attack type definition. But I also heard strong support for > constraining the problem space initially to DDoS. In fact, my > opinion, as stated at the BOF, is that the most important component of > this project is the schema. A concise schema that can accommodate all > currently known DDoS vectors and a schema that is also extensible > should be a primary goal for us. > > */[Frank] :yes, you raise the key point – a concise schema also with > the extensibility! And I hope these two goals can be achieved all, by > pre-consideration and good design./* > > 5. I’m not sure I follow the suggestion of a mesh network here. > Similar to point 4, I believe it is important to get the > downstream-to-upstream signaling correct before complicating with mesh > topology considerations. In fact, to further enforce my point above, > I think schema is more important than topology considerations at > first. I think it is critical for us to offer something that can be > tested and proven in the simplest networks that can show the benefit. > But your point about openness can not be understated – this must be > open and extensible. > > */[Frank] : Like you state here, what I propose here is about the > topology and architecture aspects. I agree that this point is a little > far than the scheme work. We can consider it later./* > > I have copied a colleague of mine, Scott Barvick. Scott was unable to > attend the BOF but has been working on these concepts with me and will > likely have some opinions in these areas to share with the thread. > > */[Frank] : Welcome, Scott~~/* > > Regards, > > Dave Larson > > > > > _______________________________________________ > 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 --------------000005080007000806020100 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit inline.

On 04/08/2015 08:54 PM, Xialiang (Frank) wrote:

Hi John,

Please see inline:

Thanks!

 

B.R.

Frank

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of John
Sent: Wednesday, April 08, 2015 11:42 PM
To: dots@ietf.org
Subject: Re: [Dots] DOTS work scope discussion: //RE: scope

 

Hello,

    Sorry I'm late to this discussion but I've recently learned of this effort and I'm very interested in the topic. If my questions have already been addressed and I missed where this was previously discussed, I'm apologize for raising the issue again and I would appreciate being directed to where the question was answered or discussed.

Please see inline.

On 04/08/2015 08:36 AM, Scott Barvick wrote:

Thanks for the intro and welcome.     From the reading of the minutes and the thread, it seems that we can and should be using the words ‘DDoS’ and ‘signaling’  along with not overlapping with other IETF work to help us check our activities against a focus that will allow us to get chartered as a WG and then make the required progress towards goals that we will have as one.   If it is not directly contributing to the signaling of DDoS threats/conditions/capabilities then we really should really not be spending any time on it.    As examples (for discussion, of course)

 

-          DDoS capabilities negotiation between the communicating parties -  in scope because it affects what can be signaled or needs to be done on either side

-          Configuration or provisioning of the devices for DDoS – not in scope because while it is DDoS, it is beyond what is necessary to signal.  And we have other protocols to define the operations and even schemas for this

-          Communication of signaling thresholds or conditions – in scope

-          Authentication of signaling channel – in scope

    Authentication is in scope, I would suggest it's required to participate.

-          Specific flow stats and flow awareness – not in scope because it is not DDoS and there are other protocols that represent this kind of info

    I kind of see this item as going along with Communication of signaling thresholds mentioned above. How do you know you are not surpassing or taking full advantage of mitigation without knowing if you are at, near, or above the signaling thresholds?

    Could you share what current protocols you are referring to?


-          DDoS attack representation – in-scope because it is DDoS.  Of course, if a device can’t classify the attack because it is either not that kind of device or it is a new attack, then we need a way for this to indicate ‘unknown’

Verification. This ,so far, is a two part issue.
            * As part of authentication, we need some way to verify the authenticating parties and agree upon authentication methods.
            * How do I verify the DDoS parameters defined downstream are applicable and valid? What's in place to prevent a CPE from sending invalid DDoS representation? The CPE could have been compromised or the owner of the CPE may try to send data that falsely blames a competitor and thus ends up allowing for a DoS of said competitor.

[Frank] : I’d like to think the CPE is trusted if it’s a authenticated peer. It’s the traditional authentication way, isn’t it?

Frank,
This still does not address the issue of a compromised CPE or a malicious CPE owner. The authentication could/would most likely be set up in a normal provisioning. The CPE owner is not at fault initially when setting up the authentication but when the device is compromised, it could be possible for the device to send notification when it should not by the adversary.

As for the malicious CPE owner comment, I've found the minutes from ietf 92 and currently working my way through the data. If I have more questions or concerns about whether a customer could falsely initiate any malicious events to a competitor, I'll address those in another thread.

Thanks,

--John



Thanks,

--John Schiel
 

 

Looking forward to good discussion and the development of a good RFC.

 

Regards,

Scott

 

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Tuesday, April 07, 2015 11:37 PM
To: Dave Larson; Teague, Nik; Scott Barvick
Cc: dots@ietf.org
Subject: RE: [Dots] DOTS work scope discussion: //RE: scope

 

Hi Dave,

I totally agree with you the point that focus DOTS’s scope on DDoS in the first stage. It’s a reasonable way we push the WG work.

Please see my response inline:

 

B.R.

Frank

 

From: Dave Larson [mailto:Dave.Larson@corero.com]
Sent: Wednesday, April 08, 2015 10:17 AM
To: Xialiang (Frank); Teague, Nik; Scott Barvick
Cc: dots@ietf.org
Subject: Re: [Dots] DOTS work scope discussion: //RE: scope

 

HI Frank,

 

I think you raise a few vary important points below:

 

On Wednesday, April 1, 2015 at 1:55 AM, "Xialiang (Frank)" <frank.xialiang@huawei.com> wrote:

 

Here are my thoughts about DOTS works:

1.       The devices can be either DDoS mitigation devices, or normal network devices (router, switch). This will make the whole DOTS solution more general for different scenarios. For example, current two drafts within DOTS can represent this difference. Maybe, we need an use case draft to elaborate their respective values;

2.       I agree that upstream systems need to negotiate its requirements or capabilities to reporting devices. This feature can save the signaling traffics. It means an initialized negotiation mechanism may be needed;

3.       A mutual authentication mechanism is needed to protect the communications between the legal senders and receivers, to avoid the faked signaling, fault peers, or creating new DDoS attacks, etc;

4.       To cope with the rapid evolution and change of the attack types, the DOTS solution should consider the capability of openness. Which means the specified information model should have the capability in semantic to define and express the new attack information;

5.       The whole architecture should not be constrained in our proposed scenarios, it can be more general, more comprehensive. For example, more devices construct a mesh network to support the DOTS functions.

 

My thoughts are:

 

1.  I agree.  We want to be inclusive on what kinds of devices may signal.  And use cases are a great way to encapsulate the problem space.  Though I would not try to extend the problem space beyond DDoS.

 

2.  I agree.  I think this is really bidirectional – I can imagine both ends of the connection advertising capabilities.  I can see the edge systems (downstream) also advertising what they are capable of signaling and this would vary depending on the types of devices as you point out in point 1.

[Frank] : Agree with the bidirectional negotiation requirement!

 

3.  Authentication is critical to avoid the fake signaling problem you have pointed out – I believe this received some discussion during the BOF in Dallas.. Whatever we do with this project, It can not introduce a new DDoS vector by failing to account for this.

 

4.  I believe all participants in the BOF would support openness for attack type definition.  But I also heard strong support for constraining the problem space initially to DDoS.  In fact, my opinion, as stated at the BOF, is that the most important component of this project is the schema.  A concise schema that can accommodate all currently known DDoS vectors and a schema that is also extensible should be a primary goal for us.

[Frank] :yes, you raise the key point – a concise schema also with the extensibility! And I hope these two goals can be achieved all, by pre-consideration and good design.

 

5.  I’m not sure I follow the suggestion of a mesh network here.  Similar to point 4, I believe it is important to get the downstream-to-upstream signaling correct before complicating with mesh topology considerations.  In fact, to further enforce my point above, I think schema is more important than topology considerations at first.  I think it is critical for us to offer something that can be tested and proven in the simplest networks that can show the benefit.  But your point about openness can not be understated – this must be open and extensible.

[Frank] : Like you state here, what I propose here is about the topology and architecture aspects. I agree that this point is a little far than the scheme work. We can consider it later.

 

I have copied a colleague of mine, Scott Barvick.  Scott was unable to attend the BOF but has been working on these concepts with me and will likely have some opinions in these areas to share with the thread.

[Frank] : Welcome, Scott~~

 

Regards,

 

Dave Larson

 

 




_______________________________________________
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

--------------000005080007000806020100-- From nobody Thu Apr 9 13:57:02 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5A51B32AB for ; Thu, 9 Apr 2015 13:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYDgOpXJKaz3 for ; Thu, 9 Apr 2015 13:56:58 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 636F01B32A5 for ; Thu, 9 Apr 2015 13:56:58 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 339619A4040; Thu, 9 Apr 2015 16:56:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id Gd9SzF-se3+7; Thu, 9 Apr 2015 16:56:27 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-133-185.washdc.fios.verizon.net [96.255.133.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 40D2A9A4044; Thu, 9 Apr 2015 16:56:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Thu, 9 Apr 2015 16:56:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <02C6C25F-E500-4D10-8F32-155B4145C1C7@vigilsec.com> References: To: Daniel Migault X-Mailer: Apple Mail (2.1085) Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] Gap analysis - SNMP X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 20:57:00 -0000 I see interest in SNMP for managers to pull status information, but = little else. YANG is the big focus in the OPS Area. Russ On Apr 9, 2015, at 10:58 AM, Daniel Migault wrote: > Hi,=20 >=20 > I would like to discuss how to position DOTS with SNMP. >=20 > DOTS defines that alert should be sent when some flow/cpu loads reach = certain level. This looks very similar to an SNMP alert. How do you = think DOTS shoud lposition toward SNMP? >=20 > BR,=20 > Daniel=20 >=20 > --=20 > Daniel Migault > Ericsson > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 9 14:32:24 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4961B2AA8 for ; Thu, 9 Apr 2015 14:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFrsugVBXPOO for ; Thu, 9 Apr 2015 14:32:21 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.106]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F382A1A212A for ; Thu, 9 Apr 2015 14:32:20 -0700 (PDT) Received: from [216.82.253.243] by server-10.bemta-7.messagelabs.com id 14/DF-29949-3EFE6255; Thu, 09 Apr 2015 21:32:19 +0000 X-Env-Sender: Scott.Barvick@corero.com X-Msg-Ref: server-5.tower-171.messagelabs.com!1428615138!12567327!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24006 invoked from network); 9 Apr 2015 21:32:19 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-5.tower-171.messagelabs.com with AES128-SHA encrypted SMTP; 9 Apr 2015 21:32:19 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0224.002; Thu, 9 Apr 2015 17:32:17 -0400 From: Scott Barvick To: Russ Housley , Daniel Migault Thread-Topic: [Dots] Gap analysis - SNMP Thread-Index: AQHQctWz0RUwTTh6Vku+q9NcjTx9751FbJ+A///HAIA= Date: Thu, 9 Apr 2015 21:32:17 +0000 Message-ID: References: <02C6C25F-E500-4D10-8F32-155B4145C1C7@vigilsec.com> In-Reply-To: <02C6C25F-E500-4D10-8F32-155B4145C1C7@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [192.168.60.119] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <223DD96B2603E2448925DF8D8FE09CE1@corero.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Gap analysis - SNMP X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:32:23 -0000 There is no overlap here. SNMP (and NETCONF(YANG)) are operational protocols and would at most be used by the higher level semantics that are trying to communicate (IMO they are not the right ones, but we have to have the discussion). Of course, we will clearly need to utilize mechanisms for transporting, authenticating, describing that exist so that we don=B9t try to invent something out of scope and already existing. Scott On 4/9/15, 4:56 PM, "Russ Housley" wrote: >I see interest in SNMP for managers to pull status information, but >little else. YANG is the big focus in the OPS Area. > >Russ > > >On Apr 9, 2015, at 10:58 AM, Daniel Migault wrote: > >> Hi,=20 >>=20 >> I would like to discuss how to position DOTS with SNMP. >>=20 >> DOTS defines that alert should be sent when some flow/cpu loads reach >>certain level. This looks very similar to an SNMP alert. How do you >>think DOTS shoud lposition toward SNMP? >>=20 >> BR,=20 >> Daniel=20 >>=20 >> --=20 >> Daniel Migault >> Ericsson >> _______________________________________________ >> 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 Thu Apr 9 15:21:51 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB9A1B3470 for ; Thu, 9 Apr 2015 15:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Z7XojvJtzhe for ; Thu, 9 Apr 2015 15:21:46 -0700 (PDT) Received: from mail-vn0-x22c.google.com (mail-vn0-x22c.google.com [IPv6:2607:f8b0:400c:c0f::22c]) (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 4B9781B3477 for ; Thu, 9 Apr 2015 15:21:45 -0700 (PDT) Received: by vnbg62 with SMTP id g62so283337vnb.6 for ; Thu, 09 Apr 2015 15:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qVbjUM8B/GeRwdzP0ri5pxyY+b2u4q987QP+sfWqrUU=; b=oSb144kT1vrOq/9NIc2o+jBg/GYxy6EXhhf4bPPLGgdRcuY3wgKgoh/2L7b9qY9TOw x+B05Wd7jSx9dZdCY7JcIF0t7KWmfiU9X6ILjnpCzjdZQq8hHJNlYu/vVNMB3g08Y+7F M5Ge35JEahH+TVz0/ZAFQLrzEKbIfKUTXkc+E9DPyZRMjg8kr22CCQqBQ6ryYMpUzAFS FJHVzpktJ95PGgedA9iXriky9gQ7z+mYfQIpfUk6qJxUa+qXoQ/2czWQ2gYVUw4C+4X1 Q8Frq9iEDU2ofF/YBWftlWQIu6D0YGVfm06OlvmRRC1xYDW0WIf7rKCIo3cigVm34V7P TlCw== X-Received: by 10.140.84.116 with SMTP id k107mr38163187qgd.45.1428618104535; Thu, 09 Apr 2015 15:21:44 -0700 (PDT) Received: from [192.168.1.10] (pool-71-174-178-27.bstnma.east.verizon.net. [71.174.178.27]) by mx.google.com with ESMTPSA id r17sm92188qkh.12.2015.04.09.15.21.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Apr 2015 15:21:43 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Thu, 9 Apr 2015 18:21:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <02C6C25F-E500-4D10-8F32-155B4145C1C7@vigilsec.com> To: Scott Barvick Archived-At: Cc: Russ Housley , "dots@ietf.org" , Daniel Migault Subject: Re: [Dots] Gap analysis - SNMP X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 22:21:48 -0000 I agree that there is no overlap and have gone down that path already (RID w= as pretty similar when it came into the IETF and I was asked to change it to= SNMP, it came out something completely different through additional IETF tr= ansforms, not solving the same problem). I don't want to see this work morp= h to fit exiting standards that are not a good fit for what is being done. =20= Sent from my iPhone > On Apr 9, 2015, at 5:32 PM, Scott Barvick wrote= : >=20 > There is no overlap here. SNMP (and NETCONF(YANG)) are operational > protocols and would at most be used by the higher level semantics that are= > trying to communicate (IMO they are not the right ones, but we have to > have the discussion). Of course, we will clearly need to utilize > mechanisms for transporting, authenticating, describing that exist so that= > we don=C2=B9t try to invent something out of scope and already existing. Other options are better suited to the requirements of exchanging telemetry d= ata and doing so in conditions that exist while undergoing a DoS attack. Th= ere's a reason both proposals used IPFIX. I agree with the points Russ made as well. Thanks, Kathleen (Individual) >=20 >=20 > Scott >=20 >> On 4/9/15, 4:56 PM, "Russ Housley" wrote: >>=20 >> I see interest in SNMP for managers to pull status information, but >> little else. YANG is the big focus in the OPS Area. >>=20 >> Russ >>=20 >>=20 >>> On Apr 9, 2015, at 10:58 AM, Daniel Migault wrote: >>>=20 >>> Hi,=20 >>>=20 >>> I would like to discuss how to position DOTS with SNMP. >>>=20 >>> DOTS defines that alert should be sent when some flow/cpu loads reach >>> certain level. This looks very similar to an SNMP alert. How do you >>> think DOTS shoud lposition toward SNMP? >>>=20 >>> BR,=20 >>> Daniel=20 >>>=20 >>> --=20 >>> Daniel Migault >>> Ericsson >>> _______________________________________________ >>> 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 Fri Apr 10 02:11:59 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C7A1ACECB for ; Fri, 10 Apr 2015 02:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBJxpBqpzoLn for ; Fri, 10 Apr 2015 02:11:53 -0700 (PDT) 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 0BAE81ACEDE for ; Fri, 10 Apr 2015 02:11:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRG07901; Fri, 10 Apr 2015 09:11:48 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Apr 2015 10:11:47 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.144]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Fri, 10 Apr 2015 17:11:44 +0800 From: "Xialiang (Frank)" To: Andrew Mortensen Thread-Topic: [Dots] DOTS work scope discussion: //RE: scope Thread-Index: AQHQcaIhLzQhJpbEDkS5B/rKwQEkFp1CchIQgAC3VGD//7fkgIABDgog//+rKwCAAllEMA== Date: Fri, 10 Apr 2015 09:11:43 +0000 Message-ID: References: <6073823821667642A5C884FF3A8807F81F3C7B14@MERCURY.corero.com> <0F4D9F9B-FF90-431A-BC8D-5DF6D0A478C5@arbor.net> <1C31808C-177B-40B6-B83A-7A066203B857@arbor.net> In-Reply-To: <1C31808C-177B-40B6-B83A-7A066203B857@arbor.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.42.200] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12ADB131CSZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Teague, Nik" , Scott Barvick , Dave Larson , "dots@ietf.org" Subject: Re: [Dots] DOTS work scope discussion: //RE: scope X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 09:11:57 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB131CSZXEMA502MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEFuZHJldzoNClBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lLg0KDQpGcm9tOiBBbmRy ZXcgTW9ydGVuc2VuIFttYWlsdG86YW1vcnRlbnNlbkBhcmJvci5uZXRdDQpTZW50OiBUaHVyc2Rh eSwgQXByaWwgMDksIDIwMTUgMTI6NTkgUE0NClRvOiBYaWFsaWFuZyAoRnJhbmspDQpDYzogU2Nv dHQgQmFydmljazsgRGF2ZSBMYXJzb247IFRlYWd1ZSwgTmlrOyBkb3RzQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW0RvdHNdIERPVFMgd29yayBzY29wZSBkaXNjdXNzaW9uOiAvL1JFOiBzY29wZQ0K DQpUaGFua3MgZm9yIHRoZSBjb21tZW50cywgRnJhbmsuIFNlZSBteSBub3RlcyBpbmxpbmUuDQoN Cg0KIEZyb206IEFuZHJldyBNb3J0ZW5zZW4gW21haWx0bzphbW9ydGVuc2VuQGFyYm9yLm5ldF0N CjxzbmlwPg0KLSAgICAgICAgICBERG9TIGNhcGFiaWxpdGllcyBuZWdvdGlhdGlvbiBiZXR3ZWVu IHRoZSBjb21tdW5pY2F0aW5nIHBhcnRpZXMgLSAgaW4gc2NvcGUgYmVjYXVzZSBpdCBhZmZlY3Rz IHdoYXQgY2FuIGJlIHNpZ25hbGVkIG9yIG5lZWRzIHRvIGJlIGRvbmUgb24gZWl0aGVyIHNpZGUN Cg0KSeKAmW0gbGVzcyBzdXJlIGFib3V0IHRoaXMuIFRyeWluZyB0byBlbmNvZGUgRERvUyBtaXRp Z2F0aW9uIGNhcGFiaWxpdGllcyBzZWVtcyBsaWtlIGFuIGV4ZXJjaXNlIGluIGZ1dGlsaXR5LCBh cyB0aGUgc3RhdGUgb2YgdGhlIGFydCBpcyBhbHJlYWR5IHJhY2luZyB0byBrZWVwIHVwIHdpdGgg YXR0YWNrIGlubm92YXRpb24uIEFueSB1cHN0cmVhbSBzZXJ2aWNlcyBpbXBsZW1lbnRpbmcgRE9U UyBhcmUgaW5kaWNhdGluZyBtaXRpZ2F0aW9uIGNhcGFiaWxpdHkuIE5vdCBhbGwgdXBzdHJlYW0g c2VydmljZXMgd2lsbCBiZSBlcXVhbCwgb2YgY291cnNlLCBidXQgdXBzdHJlYW0gY2FwYWJpbGl0 aWVzIHNlZW0gb3V0IG9mIHNjb3BlOiB0aGUgZ29hbCBvZiBET1RTLCBhcyBJIHVuZGVyc3RhbmQg aXQsIGlzIHRvIHByb3ZpZGUgYSBzdGFuZGFyZCB3YXkgZm9yIGRvd25zdHJlYW0gbWl0aWdhdGlv bi9kZXRlY3Rpb24gZGV2aWNlcyB0byByZXF1ZXN0IGludGVydmVudGlvbiB1cHN0cmVhbS4NCltG cmFua10gOiBBdCBsZWFzdCwgaW4gdGhlIG11bHRpcGxlIHVwc3RyZWFtcyBjb25kaXRpb24sIHRo ZSBhd2FyZW5lc3Mgb2YgZXZlcnkgdXBzdHJlYW3igJlzIGNhcGFiaWxpdHkgYnkgZG93bnN0cmVh bSBjYW4gaGVscCBpdCBtYWtlIHRoZSByaWdodCBjaG9pY2UuIFNvLCB0aGUgYmlkaXJlY3Rpb25h bCBuZWdvdGlhdGlvbiBtZWNoYW5pc20gaXMgdXNlZnVsIGZvciBtYWtpbmcgdGhlIHdob2xlIHNv bHV0aW9uIG1vcmUgc21hcnQgYW5kIGVmZmljaWVudC4gQnV0IGhvdyB0byByZXByZXNlbnQgdGhl IGNhcGFiaWxpdHkgYW5kIGluIHdoaWNoIGdyYW51bGFyaXR5IGlzIGluZGVlZCBhIHF1ZXN0aW9u LiBJIHRlbmQgdG8gY2hvb3NlIGEgY29hcnNlLWdyYWluZWQgY2F0ZWdvcnkgZm9yIGFwcGxpY2Fi aWxpdHkuDQoNCkV2ZW4gbGVhdmluZyBhc2lkZSB0aGUgU2lzeXBoZWFuIHRhc2sgb2YgdHJ5aW5n IHRvIG5lZ290aWF0ZSB3aXRoIHVwc3RyZWFtIGVsZW1lbnRzIHdoZW4gdGhlIHRhcmdldCBuZXR3 b3Jr4oCZcyBsaW5rcyBhcmUgY29uZ2VzdGVkLCBpdCBzZWVtcyBtaXNndWlkZWQgdG8gYmFzZSB0 aGUgZGVjaXNpb24gb2Ygd2hlcmUgdG8gc2VuZCBhIHNpZ25hbCBmb3IgaGVscCBvbiB1bmNlcnRp ZmllZCBhbmQgbmVjZXNzYXJpbHkgYWJzdHJhY3QgY2FwYWJpbGl0aWVzIGFkdmVydGlzZWQgZnJv bSB1cHN0cmVhbS4NCg0KV2hlbiB0byBtaXRpZ2F0ZSwgYW5kIHdob20gdG8gYXNrIGZvciBoZWxw IG1pdGlnYXRpbmcsIHNob3VsZCBiZSBsZWZ0IHVwIHRvIG5ldHdvcmsgb3BlcmF0b3JzLiAoVGhp cyBjYW4gb2YgY291cnNlIGluY2x1ZGUgYXV0b21pdGlnYXRpb24sIGFzIHRoZSBvcGVyYXRvciB3 aWxsIGp1c3QgaGF2ZSBtYWRlIHRoZSBkZWNpc2lvbnMgYmVmb3JlaGFuZC4pDQpbRnJhbmtdIDog SSByZWFsbHkgdGhpbmsgc29tZSBnb29kIGV4YW1wbGVzIGFuZCByZWFsIHVzZSBjYXNlcyBjYW4g aGVscCB1cyB0byBzZWUgaWYgdGhlIGNhcGFiaWxpdHkgbmVnb3RpYXRpb24gaXMgbmVlZGVkLiBC dXQgaW4gYWRkaXRpb24gdG8gY2FwYWJpbGl0eSBpbmZvLCB0aGVyZSBhcmUgcG9zc2libHkgb3Ro ZXIgcGFyYW1ldGVycyBuZWVkIHRvIGJlIG5lZ290aWF0ZS4NCg0KDQoNCiBXaGF0IHVwc3RyZWFt IGRvZXPigJRvciBldmVuIGNhbiBkb+KAlG9uIHJlY2VpcHQgb2YgYSBkaXN0cmVzcyBjYWxsIGZy b20gZG93bnN0cmVhbSBiZXlvbmQgRE9UUy4gVXBzdHJlYW0gZWxlbWVudHMgYXJlIG9mIGNvdXJz ZSB1bmRlciBubyBvYmxpZ2F0aW9uIHRvIG1pdGlnYXRlIHRoZSBhdHRhY2sgd2hlbiBpdOKAmXMg cmVxdWVzdGVkIGJ5IHRoZSBvbi1wcmVtaXNlIGRldmljZSwgYW5kIHRoZSBkb3duc3RyZWFtIG9u LXByZW1pc2UgbWl0aWdhdGlvbi9kZXRlY3Rpb24gZGV2aWNlIGlzIHVuZGVyIG5vIG9ibGlnYXRp b24gdG8gcmVxdWVzdCB1cHN0cmVhbSBoZWxwIHdoZW4gdW5kZXIgYXR0YWNrLiBHaXZlbiBjb3N0 IGNvbmNlcm5z4oCUYW5kIHVwc3RyZWFtIGludGVydmVudGlvbiBpcyBsaWtlbHkgdG8gaGF2ZSBh c3NvY2lhdGVkIGNvc3TigJRhIGRvd25zdHJlYW0gbmV0d29yayBvcGVyYXRvciBpcyBnb2luZyB0 byB3YW50IHRvIGhhdmUgdGhlIG9wdGlvbiB0byBjb250cm9sIHdoZXRoZXIgbWl0aWdhdGlvbiB1 cHN0cmVhbSBpcyBlbmFibGVkIGZvciB0aGVpciBuZXR3b3JrLg0KW0ZyYW5rXSA6IER1ZSB0byB0 aGUgdXBzdHJlYW0gaW50ZXJ2ZW50aW9uIGlzIGFzc29jaWF0ZWQgY29zdCwgdGhlIGRvd25zdHJl YW0gZGV2aWNlIGlzIG1vcmUgbGlrZWx5IHRvIGRlcGVuZCBvbiB0aGUgbmVnb3RpYXRpb24gbWVj aGFuaXNtIHRvIGhlbHAgaXQgY2hvb3NlIHRoZSBzdWl0YWJsZSB1cHN0cmVhbS4NCg0KSeKAmWQg dmVyeSBtdWNoIGxpa2UgdG8gYXZvaWQgdHJ5aW5nIHRvIHN0YW5kYXJkaXplIHdoYXQgYW1vdW50 IHRvIGJ1c2luZXNzIG5lZ290aWF0aW9ucyBvbiBiZWhhbGYgb2YgbmV0d29yayBvd25lcnMuDQoN CldoZW4gdGhlIHRhcmdldCBuZXR3b3JrIGlzIHVuZGVyIGF0dGFjaywgdGhlIG1lYXN1cmFibGUg cmVzdWx0IG9mIGEgcmVxdWVzdCBmb3IgaGVscCB3aWxsIGJlIHJlZHVjZWQgbG9hZC4gVGhlIHVs dGltYXRlIGp1ZGdlIG9mIHRoZSBuZWVkIGZvciBtaXRpZ2F0aW9uLCBpdHMgZWZmZWN0aXZlbmVz cywgaXRzIGR1cmF0aW9uLCBhbmQgaXRzIHZhbHVlIHdpbGwgYmUgdGhlIG5ldHdvcmsgb3duZXJz IHdobyByZXF1ZXN0ZWQgaW50ZXJ2ZW50aW9uIGluIHRoZSBmaXJzdCBwbGFjZS4NCg0KDQoNCjxz bmlwPg0KDQoNCi0gICAgICAgICAgU3BlY2lmaWMgZmxvdyBzdGF0cyBhbmQgZmxvdyBhd2FyZW5l c3Mg4oCTIG5vdCBpbiBzY29wZSBiZWNhdXNlIGl0IGlzIG5vdCBERG9TIGFuZCB0aGVyZSBhcmUg b3RoZXIgcHJvdG9jb2xzIHRoYXQgcmVwcmVzZW50IHRoaXMga2luZCBvZiBpbmZvDQoNCk1heWJl IG1vcmUgaW1wb3J0YW50bHksIHRoZXkgYXJlbid0IGdvaW5nIHRvIGdldCB0aHJvdWdoIGEgY29u Z2VzdGVkIGNoYW5uZWwgdG8gYW55IHVwc3RyZWFtIGVsZW1lbnQgcmVsaWFibHkuDQpbRnJhbmtd IDogSSBjYW5ub3QgdG90YWxseSBhZ3JlZSB3aXRoIHRoaXMgcG9pbnQuIEluIGFkZGl0aW9uIHRv IHRoZSBwcmVjaXNlIGF0dGFjayBpbmZvIGluc3BlY3RlZCBieSB0aGUgRERvUyBtaXRpZ2F0aW9u IGRldmljZSwgdGhlIHNwZWNpZmljIGZsb3cgc3RhdHMgaW5mbyBpbnNwZWN0ZWQgYnkgdGhlIG5v cm1hbCBuZXR3b3JrIGRldmljZXMgKGkuZS4sIHJvdXRlciwgc3dpdGNoKSBhcmUgYWxzbyB2ZXJ5 IHZhbHVhYmxlIGZvciB0aGUgdXBzdHJlYW0gcGxhdGZvcm0gdG8gYmUgYXdhcmUgb2Ygd2hhdCBo YXBwZW4gaW4gbmV0d29yayBhbmQgd2hhdCB0byBkbyB0aGVuLiBXZSBzaG91bGQgY29uc2lkZXIg YSBnZW5lcmFsIHVzZSBjYXNlLCBhbmQgbm90IGV4Y2x1ZGUgdGhlIG5ldHdvcmsgZGV2aWNlcyBv dXQgb2YgdGhlIHNjb3BlLg0KDQpUaGVyZSBhcmUgcGxlbnR5IG9mIGRldmljZXMgb3V0IHRoZXJl IGRlc2lnbmVkIHRvIHBlcmZvcm0gZmxvdyBhbmFseXNpcyBhbmQgZGVyaXZlIGludGVsbGlnZW5j ZSBmcm9tIGl0LCBpbmNsdWRpbmcgYXR0YWNrIGRldGVjdGlvbi4gU3VjaCBkZXZpY2VzIHdvdWxk IGJlIG5hdHVyYWwgRE9UUyBjbGllbnRzLCB3ZWxsLXBvc2l0aW9uZWQgdG8gc2lnbmFsIGZvciB1 cHN0cmVhbSBpbnRlcnZlbnRpb24gd2hlbiBhdHRhY2tzIGFyZSBkZXRlY3RlZC4NCg0KQnV0IGl0 IHNvdW5kcyBsaWtlIGluc3RlYWQgb2YgdXNpbmcgb24tcHJlbWlzZSBjb2xsZWN0b3JzLCB5b3Xi gJlyZSBzdWdnZXN0aW5nIHNhbXBsZWQgZmxvdyBzaG91bGQgYmUgZXhwb3J0ZWQgdXBzdHJlYW0g ZHVyaW5nIGF0dGFjay4gSXMgdGhhdCBhY2N1cmF0ZT8NCltGcmFua10gOiBOby4gd2hhdCBJIHN1 Z2dlc3QgaXMgdGhlIGZsb3cgc2FtcGxpbmcgaW5mb3JtYXRpb24gY2FuIGJlIGV4cG9ydGVkIGZy b20gdGhlIHJvdXRlciwgc3dpdGNoIHRvIHRoZSB1cHN0cmVhbSBhbnRpLWRkb3MgcGxhdGZvcm0u IE9mIGNvdXJzZSwgdGhlIG9uLXByZW1pc2UgY29sbGVjdG9ycyB5b3UgbWVudGlvbiBoZXJlIGNh biBkbyB0aGUgc2FtZSBqb2IuDQoNCg0KLSAgICAgICAgICBERG9TIGF0dGFjayByZXByZXNlbnRh dGlvbiDigJMgaW4tc2NvcGUgYmVjYXVzZSBpdCBpcyBERG9TLiAgT2YgY291cnNlLCBpZiBhIGRl dmljZSBjYW7igJl0IGNsYXNzaWZ5IHRoZSBhdHRhY2sgYmVjYXVzZSBpdCBpcyBlaXRoZXIgbm90 IHRoYXQga2luZCBvZiBkZXZpY2Ugb3IgaXQgaXMgYSBuZXcgYXR0YWNrLCB0aGVuIHdlIG5lZWQg YSB3YXkgZm9yIHRoaXMgdG8gaW5kaWNhdGUg4oCYdW5rbm93buKAmQ0KDQpJbiBzY29wZSwgYnV0 IG5vdCByZXF1aXJlZC4gSXQgaXMgdW5kb3VidGVkbHkgdXNlZnVsIGluZm9ybWF0aW9uIGZvciB0 aGUgdXBzdHJlYW0gc2VydmljZSwgYnV0IGlzIG5vdCBhIHJlcXVpcmVtZW50IGJlZm9yZSB1cHN0 cmVhbSBjYW4gYmVnaW4gbWl0aWdhdGluZy4gQXQgYSBtaW5pbXVtLCBhIGRvd25zdHJlYW0gb24t cHJlbWlzZSBkZXZpY2Ugc2hvdWxkIGF0IG5lZWQgYmUgYWJsZSB0byByZXF1ZXN0IG1pdGlnYXRp b24gYW5kIHJlcXVlc3QgbWl0aWdhdGlvbiBkZWFjdGl2YXRpb24uDQpbRnJhbmtdIDogQnkgbXkg dW5kZXJzdGFuZGluZywgYW4gaW1wb3J0YW50IGdvYWwgb2YgRE9UUyB3b3JrIGlzIHRvIGltcHJv dmUgdGhlIHNlY3VyaXR5IGludGVsbGlnZW5jZSBzaGFyaW5nIGFtb25nIHRoZSB3aG9sZSBuZXR3 b3JrIHNlY3VyaXR5IGVjb3N5c3RlbS4gU28sIGhvdyB0byByZXByZXNlbnQgdGhlIEREb1MgYXR0 YWNrcyBhbmQgc2hhcmluZyB0aGVtIGlzIGEgdmVyeSB1c2VmdWwgd29yay4gU28sIGRlZmluaXRl bHksIGl0IHNob3VsZCBiZSBpbiBzY29wZSwgYW5kIHRoZSBERG9TIGF0dGFjayBpbmZvIHNob3Vs ZCBiZSBzaGFyZWQgYW1vbmcgdGhlIGZlZGVyYWwgcGVlcnMgaW4gdGltZS4gRm9yIHRoZSBuZXcg YXR0YWNrLCB0byBpbmRpY2F0ZSDigJh1bmtub3du4oCZIGlzIHRoZSBkZWZhdWx0IG1ldGhvZCwg YnV0IGl0IGlzIGFsc28gcG9zc2libGUgdG8gYmV0dGVyIHJlcHJlc2VudCB0aGVtIGJ5IHVzaW5n IHNvbWUgZ29vZCBkZXNpZ24gYW5kIGV4dGVuc2libGUgaW5mb3JtYXRpb24gc2NoZW1lDQoNClRo aXMgc291bmRzIGEgbG90IGxpa2UgTUlMRSwgbm8/DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvd2cvbWlsZS9jaGFydGVyLw0KDQpZb3XigJlsbCBnZXQgbm8gYXJndW1lbnQgZnJvbSBt ZSB0aGF0IHJlcHJlc2VudGluZyBhbmQgc2hhcmluZyBERG9TIGF0dGFjayBwcm9maWxlcyBpcyB1 c2VmdWwgd29yay4gVGhlIHNjb3BlIG9mIHRoYXQgd29yayBpcyBlbm9ybW91cywgdGhvdWdoLCBh bmQgRE9UUyBpcyBmb2N1c2VkIG9uIHRoZSBzaWduYWxpbmcgYXNwZWN0OiBwcm92aWRpbmcgKGlu IG15IHZpZXcpIG1pbmltYWxseSBuZWNlc3NhcnkgaW5mb3JtYXRpb24gdG8gYW4gdXBzdHJlYW0g ZWxlbWVudCB0byBzaWduYWwgdGhlIG5lZWQgZm9yIGFpZCBmaWdodGluZyBvZmYgYW4gYXR0YWNr LiBXaGF0IOKAnG1pbmltYWxseSBuZWNlc3NhcnnigJ0gbWVhbnMgcmVtYWlucyBhIG1hdHRlciBm b3IgZGViYXRlLCBvZiBjb3Vyc2UsIGJ1dCBpbiBteSBtaW5kIHRoYXQgZXhjbHVkZXMgYSBncmVh dCBkZWFsIG9mIHRoZSBzb3J0IG9mIHJpY2ggaW5mb3JtYXRpb24gdGhhdCB3b3VsZCBiZSBmdWxs eSBpbi1zY29wZSBmb3Igc29tZXRoaW5nIGxpa2UgTUlMRS4NCltGcmFua10gOiBhIGNsZWFyIGdh cCBhbmFseXNpcyBiZXR3ZWVuIERPVFMgYW5kIE1JTEUgaXMgdmVyeSB1c2VmdWwgZm9yIHRoaXMg cG9pbnR+fg0KDQphbmRyZXcNCg== --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB131CSZXEMA502MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0 YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG 5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0 ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4u Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1m YW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i WkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksIEFuZHJldzo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbmRyZXcgTW9ydGVuc2VuIFttYWlsdG86YW1vcnRl bnNlbkBhcmJvci5uZXRdDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDA5LCAy MDE1IDEyOjU5IFBNPGJyPg0KPGI+VG86PC9iPiBYaWFsaWFuZyAoRnJhbmspPGJyPg0KPGI+Q2M6 PC9iPiBTY290dCBCYXJ2aWNrOyBEYXZlIExhcnNvbjsgVGVhZ3VlLCBOaWs7IGRvdHNAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RTIHdvcmsgc2NvcGUgZGlzY3Vz c2lvbjogLy9SRTogc2NvcGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFu a3MgZm9yIHRoZSBjb21tZW50cywgRnJhbmsuIFNlZSBteSBub3RlcyBpbmxpbmUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTombmJzcDtBbmRyZXcgTW9ydGVuc2VuIFs8YSBocmVmPSJtYWls dG86YW1vcnRlbnNlbkBhcmJvci5uZXQiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0 bzphbW9ydGVuc2VuQGFyYm9yLm5ldDwvc3Bhbj48L2E+XSZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZsdDtzbmlwJmd0Ozwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ERG9TDQogY2FwYWJpbGl0aWVzIG5lZ290aWF0 aW9uIGJldHdlZW4gdGhlIGNvbW11bmljYXRpbmcgcGFydGllcyAtICZuYnNwO2luIHNjb3BlIGJl Y2F1c2UgaXQgYWZmZWN0cyB3aGF0IGNhbiBiZSBzaWduYWxlZCBvciBuZWVkcyB0byBiZSBkb25l IG9uIGVpdGhlciBzaWRlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+STwvc3Bhbj7igJk8c3BhbiBsYW5nPSJFTi1V UyI+bSBsZXNzIHN1cmUgYWJvdXQgdGhpcy4gVHJ5aW5nIHRvIGVuY29kZSBERG9TIG1pdGlnYXRp b24gY2FwYWJpbGl0aWVzIHNlZW1zIGxpa2UgYW4gZXhlcmNpc2UgaW4gZnV0aWxpdHksIGFzIHRo ZSBzdGF0ZSBvZiB0aGUgYXJ0IGlzIGFscmVhZHkgcmFjaW5nIHRvIGtlZXAgdXAgd2l0aCBhdHRh Y2sgaW5ub3ZhdGlvbi4gQW55IHVwc3RyZWFtDQogc2VydmljZXMgaW1wbGVtZW50aW5nIERPVFMg YXJlIGluZGljYXRpbmcgbWl0aWdhdGlvbiBjYXBhYmlsaXR5LiBOb3QgYWxsIHVwc3RyZWFtIHNl cnZpY2VzIHdpbGwgYmUgZXF1YWwsIG9mIGNvdXJzZSwgYnV0IHVwc3RyZWFtIGNhcGFiaWxpdGll cyBzZWVtIG91dCBvZiBzY29wZTogdGhlIGdvYWwgb2YgRE9UUywgYXMgSSB1bmRlcnN0YW5kIGl0 LCBpcyB0byBwcm92aWRlIGEgc3RhbmRhcmQgd2F5IGZvciBkb3duc3RyZWFtIG1pdGlnYXRpb24v ZGV0ZWN0aW9uDQogZGV2aWNlcyB0byByZXF1ZXN0IGludGVydmVudGlvbiB1cHN0cmVhbS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPltGcmFua10gOiBBdCBsZWFzdCwgaW4gdGhlIG11bHRpcGxlIHVwc3RyZWFtcyBjb25kaXRp b24sIHRoZSBhd2FyZW5lc3Mgb2YgZXZlcnkgdXBzdHJlYW3igJlzIGNhcGFiaWxpdHkgYnkgZG93 bnN0cmVhbSBjYW4gaGVscCBpdCBtYWtlIHRoZQ0KIHJpZ2h0IGNob2ljZS4gU28sIHRoZSBiaWRp cmVjdGlvbmFsIG5lZ290aWF0aW9uIG1lY2hhbmlzbSBpcyB1c2VmdWwgZm9yIG1ha2luZyB0aGUg d2hvbGUgc29sdXRpb24gbW9yZSBzbWFydCBhbmQgZWZmaWNpZW50LiBCdXQgaG93IHRvIHJlcHJl c2VudCB0aGUgY2FwYWJpbGl0eSBhbmQgaW4gd2hpY2ggZ3JhbnVsYXJpdHkgaXMgaW5kZWVkIGEg cXVlc3Rpb24uIEkgdGVuZCB0byBjaG9vc2UgYSBjb2Fyc2UtZ3JhaW5lZCBjYXRlZ29yeSBmb3Ig YXBwbGljYWJpbGl0eS48L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkV2ZW4gbGVhdmluZyBhc2lkZSB0aGUgU2lzeXBoZWFuIHRhc2sgb2Yg dHJ5aW5nIHRvIG5lZ290aWF0ZSB3aXRoIHVwc3RyZWFtIGVsZW1lbnRzIHdoZW4gdGhlIHRhcmdl dCBuZXR3b3Jr4oCZcyBsaW5rcyBhcmUgY29uZ2VzdGVkLCBpdCBzZWVtcyBtaXNndWlkZWQgdG8g YmFzZSB0aGUgZGVjaXNpb24gb2Ygd2hlcmUgdG8gc2VuZCBhIHNpZ25hbCBmb3IgaGVscCBvbiB1 bmNlcnRpZmllZA0KIGFuZCBuZWNlc3NhcmlseSBhYnN0cmFjdCBjYXBhYmlsaXRpZXMgYWR2ZXJ0 aXNlZCBmcm9tIHVwc3RyZWFtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+V2hlbiB0byBtaXRpZ2F0ZSwgYW5kIHdob20gdG8gYXNrIGZvciBoZWxwIG1p dGlnYXRpbmcsIHNob3VsZCBiZSBsZWZ0IHVwIHRvIG5ldHdvcmsgb3BlcmF0b3JzLiAoVGhpcyBj YW4gb2YgY291cnNlIGluY2x1ZGUgYXV0b21pdGlnYXRpb24sIGFzIHRoZSBvcGVyYXRvciB3aWxs IGp1c3QgaGF2ZSBtYWRlIHRoZSBkZWNpc2lvbnMgYmVmb3JlaGFuZC4pPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bRnJhbmtdIDogSSByZWFsbHkgdGhp bmsgc29tZSBnb29kIGV4YW1wbGVzIGFuZCByZWFsIHVzZSBjYXNlcyBjYW4gaGVscCB1cyB0byBz ZWUgaWYgdGhlIGNhcGFiaWxpdHkgbmVnb3RpYXRpb24gaXMgbmVlZGVkLiBCdXQgaW4gYWRkaXRp b24NCiB0byBjYXBhYmlsaXR5IGluZm8sIHRoZXJlIGFyZSBwb3NzaWJseSBvdGhlciBwYXJhbWV0 ZXJzIG5lZWQgdG8gYmUgbmVnb3RpYXRlLjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7V2hhdCB1cHN0cmVhbSBkb2Vz PC9zcGFuPuKAlDxzcGFuIGxhbmc9IkVOLVVTIj5vciBldmVuIGNhbiBkbzwvc3Bhbj7igJQ8c3Bh biBsYW5nPSJFTi1VUyI+b24gcmVjZWlwdCBvZiBhIGRpc3RyZXNzIGNhbGwgZnJvbSBkb3duc3Ry ZWFtIGJleW9uZCBET1RTLiBVcHN0cmVhbSBlbGVtZW50cyBhcmUgb2YgY291cnNlIHVuZGVyIG5v IG9ibGlnYXRpb24gdG8gbWl0aWdhdGUgdGhlIGF0dGFjaw0KIHdoZW4gaXQ8L3NwYW4+4oCZPHNw YW4gbGFuZz0iRU4tVVMiPnMgcmVxdWVzdGVkIGJ5IHRoZSBvbi1wcmVtaXNlIGRldmljZSwgYW5k IHRoZSBkb3duc3RyZWFtIG9uLXByZW1pc2UgbWl0aWdhdGlvbi9kZXRlY3Rpb24gZGV2aWNlIGlz IHVuZGVyIG5vIG9ibGlnYXRpb24gdG8gcmVxdWVzdCB1cHN0cmVhbSBoZWxwIHdoZW4gdW5kZXIg YXR0YWNrLiBHaXZlbiBjb3N0IGNvbmNlcm5zPC9zcGFuPuKAlDxzcGFuIGxhbmc9IkVOLVVTIj5h bmQgdXBzdHJlYW0NCiBpbnRlcnZlbnRpb24gaXMgbGlrZWx5IHRvIGhhdmUgYXNzb2NpYXRlZCBj b3N0PC9zcGFuPuKAlDxzcGFuIGxhbmc9IkVOLVVTIj5hIGRvd25zdHJlYW0gbmV0d29yayBvcGVy YXRvciBpcyBnb2luZyB0byB3YW50IHRvIGhhdmUgdGhlIG9wdGlvbiB0byBjb250cm9sIHdoZXRo ZXIgbWl0aWdhdGlvbiB1cHN0cmVhbSBpcyBlbmFibGVkIGZvciB0aGVpciBuZXR3b3JrLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+W0ZyYW5rXSA6IER1ZSB0byB0aGUgdXBzdHJlYW0gaW50ZXJ2ZW50 aW9uIGlzIGFzc29jaWF0ZWQgY29zdCwgdGhlIGRvd25zdHJlYW0gZGV2aWNlIGlzIG1vcmUgbGlr ZWx5IHRvIGRlcGVuZCBvbiB0aGUgbmVnb3RpYXRpb24gbWVjaGFuaXNtDQogdG8gaGVscCBpdCBj aG9vc2UgdGhlIHN1aXRhYmxlIHVwc3RyZWFtLjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPknigJlkIHZlcnkgbXVjaCBsaWtlIHRvIGF2b2lkIHRyeWlu ZyB0byBzdGFuZGFyZGl6ZSB3aGF0IGFtb3VudCB0byBidXNpbmVzcyBuZWdvdGlhdGlvbnMgb24g YmVoYWxmIG9mIG5ldHdvcmsgb3duZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+V2hlbiB0aGUgdGFyZ2V0IG5ldHdvcmsgaXMgdW5kZXIgYXR0YWNr LCB0aGUgbWVhc3VyYWJsZSByZXN1bHQgb2YgYSByZXF1ZXN0IGZvciBoZWxwIHdpbGwgYmUgcmVk dWNlZCBsb2FkLiBUaGUgdWx0aW1hdGUganVkZ2Ugb2YgdGhlIG5lZWQgZm9yIG1pdGlnYXRpb24s IGl0cyBlZmZlY3RpdmVuZXNzLCBpdHMgZHVyYXRpb24sIGFuZCBpdHMgdmFsdWUgd2lsbCBiZSB0 aGUgbmV0d29yaw0KIG93bmVycyB3aG8gcmVxdWVzdGVkIGludGVydmVudGlvbiBpbiB0aGUgZmly c3QgcGxhY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZsdDtzbmlwJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+LTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNwZWNpZmljDQogZmxvdyBzdGF0cyBhbmQgZmxvdyBh d2FyZW5lc3Mg4oCTIG5vdCBpbiBzY29wZSBiZWNhdXNlIGl0IGlzIG5vdCBERG9TIGFuZCB0aGVy ZSBhcmUgb3RoZXIgcHJvdG9jb2xzIHRoYXQgcmVwcmVzZW50IHRoaXMga2luZCBvZiBpbmZvPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TWF5 YmUgbW9yZSBpbXBvcnRhbnRseSwgdGhleSBhcmVuJ3QgZ29pbmcgdG8gZ2V0IHRocm91Z2ggYSBj b25nZXN0ZWQgY2hhbm5lbCB0byBhbnkgdXBzdHJlYW0gZWxlbWVudCByZWxpYWJseS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PltGcmFua10gOiBJIGNhbm5vdCB0b3RhbGx5IGFncmVlIHdpdGggdGhpcyBwb2ludC4gSW4gYWRk aXRpb24gdG8gdGhlIHByZWNpc2UgYXR0YWNrIGluZm8gaW5zcGVjdGVkIGJ5IHRoZSBERG9TIG1p dGlnYXRpb24gZGV2aWNlLCB0aGUgc3BlY2lmaWMNCiBmbG93IHN0YXRzIGluZm8gaW5zcGVjdGVk IGJ5IHRoZSBub3JtYWwgbmV0d29yayBkZXZpY2VzIChpLmUuLCByb3V0ZXIsIHN3aXRjaCkgYXJl IGFsc28gdmVyeSB2YWx1YWJsZSBmb3IgdGhlIHVwc3RyZWFtIHBsYXRmb3JtIHRvIGJlIGF3YXJl IG9mIHdoYXQgaGFwcGVuIGluIG5ldHdvcmsgYW5kIHdoYXQgdG8gZG8gdGhlbi4gV2Ugc2hvdWxk IGNvbnNpZGVyIGEgZ2VuZXJhbCB1c2UgY2FzZSwgYW5kIG5vdCBleGNsdWRlIHRoZSBuZXR3b3Jr IGRldmljZXMNCiBvdXQgb2YgdGhlIHNjb3BlLjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlcmUgYXJlIHBsZW50eSBvZiBkZXZpY2Vz IG91dCB0aGVyZSBkZXNpZ25lZCB0byBwZXJmb3JtIGZsb3cgYW5hbHlzaXMgYW5kIGRlcml2ZSBp bnRlbGxpZ2VuY2UgZnJvbSBpdCwgaW5jbHVkaW5nIGF0dGFjayBkZXRlY3Rpb24uIFN1Y2ggZGV2 aWNlcyB3b3VsZCBiZSBuYXR1cmFsIERPVFMgY2xpZW50cywgd2VsbC1wb3NpdGlvbmVkIHRvIHNp Z25hbCBmb3IgdXBzdHJlYW0gaW50ZXJ2ZW50aW9uDQogd2hlbiBhdHRhY2tzIGFyZSBkZXRlY3Rl ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJ1dCBp dCBzb3VuZHMgbGlrZSBpbnN0ZWFkIG9mIHVzaW5nIG9uLXByZW1pc2UgY29sbGVjdG9ycywgeW91 4oCZcmUgc3VnZ2VzdGluZyBzYW1wbGVkIGZsb3cgc2hvdWxkIGJlIGV4cG9ydGVkIHVwc3RyZWFt IGR1cmluZyBhdHRhY2suIElzIHRoYXQgYWNjdXJhdGU/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bRnJhbmtdIDogTm8uIHdoYXQgSSBzdWdnZXN0IGlz IHRoZSBmbG93IHNhbXBsaW5nIGluZm9ybWF0aW9uIGNhbiBiZSBleHBvcnRlZCBmcm9tIHRoZSBy b3V0ZXIsIHN3aXRjaCB0byB0aGUgdXBzdHJlYW0gYW50aS1kZG9zIHBsYXRmb3JtLg0KIE9mIGNv dXJzZSwgdGhlIG9uLXByZW1pc2UgY29sbGVjdG9ycyB5b3UgbWVudGlvbiBoZXJlIGNhbiBkbyB0 aGUgc2FtZSBqb2IuPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RERvUw0KIGF0dGFjayByZXByZXNlbnRhdGlvbiDi gJMgaW4tc2NvcGUgYmVjYXVzZSBpdCBpcyBERG9TLiZuYnNwOyBPZiBjb3Vyc2UsIGlmIGEgZGV2 aWNlIGNhbuKAmXQgY2xhc3NpZnkgdGhlIGF0dGFjayBiZWNhdXNlIGl0IGlzIGVpdGhlciBub3Qg dGhhdCBraW5kIG9mIGRldmljZSBvciBpdCBpcyBhIG5ldyBhdHRhY2ssIHRoZW4gd2UgbmVlZCBh IHdheSBmb3IgdGhpcyB0byBpbmRpY2F0ZSDigJh1bmtub3du4oCZPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBzY29wZSwgYnV0IG5vdCByZXF1aXJl ZC4gSXQgaXMgdW5kb3VidGVkbHkgdXNlZnVsIGluZm9ybWF0aW9uIGZvciB0aGUgdXBzdHJlYW0g c2VydmljZSwgYnV0IGlzIG5vdCBhIHJlcXVpcmVtZW50IGJlZm9yZSB1cHN0cmVhbSBjYW4gYmVn aW4gbWl0aWdhdGluZy4gQXQgYSBtaW5pbXVtLCBhIGRvd25zdHJlYW0gb24tcHJlbWlzZSBkZXZp Y2Ugc2hvdWxkIGF0IG5lZWQgYmUNCiBhYmxlIHRvIHJlcXVlc3QgbWl0aWdhdGlvbiBhbmQgcmVx dWVzdCBtaXRpZ2F0aW9uIGRlYWN0aXZhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltGcmFua10gOiBCeSBteSB1bmRl cnN0YW5kaW5nLCBhbiBpbXBvcnRhbnQgZ29hbCBvZiBET1RTIHdvcmsgaXMgdG8gaW1wcm92ZSB0 aGUgc2VjdXJpdHkgaW50ZWxsaWdlbmNlIHNoYXJpbmcgYW1vbmcgdGhlIHdob2xlIG5ldHdvcmsg c2VjdXJpdHkNCiBlY29zeXN0ZW0uIFNvLCBob3cgdG8gcmVwcmVzZW50IHRoZSBERG9TIGF0dGFj a3MgYW5kIHNoYXJpbmcgdGhlbSBpcyBhIHZlcnkgdXNlZnVsIHdvcmsuIFNvLCBkZWZpbml0ZWx5 LCBpdCBzaG91bGQgYmUgaW4gc2NvcGUsIGFuZCB0aGUgRERvUyBhdHRhY2sgaW5mbyBzaG91bGQg YmUgc2hhcmVkIGFtb25nIHRoZSBmZWRlcmFsIHBlZXJzIGluIHRpbWUuIEZvciB0aGUgbmV3IGF0 dGFjaywgdG8gaW5kaWNhdGUg4oCYdW5rbm93buKAmSBpcyB0aGUgZGVmYXVsdA0KIG1ldGhvZCwg YnV0IGl0IGlzIGFsc28gcG9zc2libGUgdG8gYmV0dGVyIHJlcHJlc2VudCB0aGVtIGJ5IHVzaW5n IHNvbWUgZ29vZCBkZXNpZ24gYW5kIGV4dGVuc2libGUgaW5mb3JtYXRpb24gc2NoZW1lPC9zcGFu PjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGlzIHNvdW5kcyBhIGxvdCBsaWtlIE1JTEUsIG5vPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy93Zy9taWxlL2NoYXJ0ZXIvIj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL3dnL21pbGUvY2hhcnRlci88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3XigJlsbCBnZXQgbm8gYXJndW1lbnQgZnJvbSBtZSB0aGF0 IHJlcHJlc2VudGluZyBhbmQgc2hhcmluZyBERG9TIGF0dGFjayBwcm9maWxlcyBpcyB1c2VmdWwg d29yay4gVGhlIHNjb3BlIG9mIHRoYXQgd29yayBpcyBlbm9ybW91cywgdGhvdWdoLCBhbmQgRE9U UyBpcyBmb2N1c2VkIG9uIHRoZSBzaWduYWxpbmcgYXNwZWN0OiBwcm92aWRpbmcgKGluIG15IHZp ZXcpIG1pbmltYWxseQ0KIG5lY2Vzc2FyeSBpbmZvcm1hdGlvbiB0byBhbiB1cHN0cmVhbSBlbGVt ZW50IHRvIHNpZ25hbCB0aGUgbmVlZCBmb3IgYWlkIGZpZ2h0aW5nIG9mZiBhbiBhdHRhY2suIFdo YXQg4oCcbWluaW1hbGx5IG5lY2Vzc2FyeeKAnSBtZWFucyByZW1haW5zIGEgbWF0dGVyIGZvciBk ZWJhdGUsIG9mIGNvdXJzZSwgYnV0IGluIG15IG1pbmQgdGhhdCBleGNsdWRlcyBhIGdyZWF0IGRl YWwgb2YgdGhlIHNvcnQgb2YgcmljaCBpbmZvcm1hdGlvbiB0aGF0IHdvdWxkIGJlDQogZnVsbHkg aW4tc2NvcGUgZm9yIHNvbWV0aGluZyBsaWtlIE1JTEUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bRnJhbmtdIDogYSBjbGVhciBnYXAgYW5hbHlzaXMg YmV0d2VlbiBET1RTIGFuZCBNSUxFIGlzIHZlcnkgdXNlZnVsIGZvciB0aGlzIHBvaW50fn48L3Nw YW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+YW5kcmV3PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB131CSZXEMA502MBSchi_-- From nobody Wed Apr 15 12:37:22 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749CA1A898A for ; Wed, 15 Apr 2015 12:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBFieZtRte2p for ; Wed, 15 Apr 2015 12:37:19 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::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 E273C1A8988 for ; Wed, 15 Apr 2015 12:37:18 -0700 (PDT) Received: by lagv1 with SMTP id v1so40707597lag.3 for ; Wed, 15 Apr 2015 12:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=opava1cbxbAhK5v8G5EciWb9GYOp+/CU5+IVFiPqS14=; b=DKKE5rR3ynJhEN8DGYpo6CTPgPvAylwHwdvr1Wro/N14KVga2FJXdTkfprD9AAacdN UJM6tIjILdKW5ZtZ84E4IlliaMh4H5VdcNkQxaPAVfXq2xOQhSGvKhQn+Uawc0uS21FB D3zITIG+3/a1wTaQ3beb5cv0yQAKgNz2emnr7XJ1KvZ1AG0ApHzLymvNAO61G1BbEWbE ksL8FK70ojyenhlgQBc1VKGe4MskJNip2C0qlmc6Pcm97XKF9yrrr3QGTPhrP4VFRbbi Zkot4BHzYm6uWi4nd8+IW5vlsWw/7RbJwj5daESWizQbnmyYmY7n7UsiRYEBR1XjeUwN arPQ== MIME-Version: 1.0 X-Received: by 10.112.97.202 with SMTP id ec10mr25151064lbb.4.1429126637370; Wed, 15 Apr 2015 12:37:17 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Wed, 15 Apr 2015 12:37:17 -0700 (PDT) Date: Wed, 15 Apr 2015 15:37:17 -0400 Message-ID: From: Kathleen Moriarty To: "dots@ietf.org" Content-Type: multipart/alternative; boundary=001a1133b1c48f42f30513c87980 Archived-At: Subject: [Dots] Timeline X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 19:37:20 -0000 --001a1133b1c48f42f30513c87980 Content-Type: text/plain; charset=UTF-8 Hello, Requests for BoFs in Prague are due by June 5th. I encourage the group to work on a charter once you figure out the scope. If you don't have a final charter in for approval a couple of weeks before the cutoff, the group should plan to request a working group forming BoF. You would be able to continue charter discussions in the BoF and finalize it after Prague. http://www.ietf.org/meeting/important-dates-2015.html#ietf93 Deadlines approach quickly, and the work is a bit behind if your goal is to form a WG to start work on drafts in Prague. -- Best regards, Kathleen --001a1133b1c48f42f30513c87980 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

Req= uests for BoFs in Prague are due by June 5th.=C2=A0 I encourage the group t= o work on a charter once you figure out the scope.=C2=A0 If you don't h= ave a final charter in for approval a couple of weeks before the cutoff, th= e group should plan to request a working group forming BoF.=C2=A0 You would= be able to continue charter discussions in the BoF and finalize it after P= rague.


Deadlines approach quickly= , and the work is a bit behind if your goal is to form a WG to start work o= n drafts in Prague.

--

Best regards,
Kathleen
--001a1133b1c48f42f30513c87980-- From nobody Mon Apr 20 00:36:04 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0CC1AC3D5 for ; Mon, 20 Apr 2015 00:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kv1ovWkv8RfU for ; Mon, 20 Apr 2015 00:36:01 -0700 (PDT) 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 66F3D1AC3B5 for ; Mon, 20 Apr 2015 00:36:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRP21768; Mon, 20 Apr 2015 07:35:58 +0000 (GMT) Received: from SZXEML434-HUB.china.huawei.com (10.82.67.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 20 Apr 2015 08:35:57 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.131]) by szxeml434-hub.china.huawei.com ([10.82.67.225]) with mapi id 14.03.0158.001; Mon, 20 Apr 2015 15:34:50 +0800 From: "Hedanping (Ana)" To: "Roman D. Danyliw" , "dots@ietf.org" Thread-Topic: Overlap with DOTS drafts to MILE Thread-Index: AQHQZkn466+PgLhkVky8NpyqaFNMzp1Vnr1Q Date: Mon, 20 Apr 2015 07:34:49 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D95E9BD@szxeml557-mbs.china.huawei.com> References: <359EC4B99E040048A7131E0F4E113AFCD93D22A7@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCD93D22A7@marathon> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.94.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Dots] Overlap with DOTS drafts to MILE X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 07:36:03 -0000 Hi Roman,=20 Thanks for the comment. I think this thread is a good place to discuss the = gap/relationship between DOTS and MILE, which is also mentioned by Daniel.= =20 I have some doubts, please see my reply inline. >-----Original Message----- >From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman D. Danyliw >Sent: Tuesday, March 24, 2015 11:48 PM >To: dots@ietf.org >Subject: [Dots] Overlap with DOTS drafts to MILE > >Hello! > >BOF chair hat off ... > >Ignoring the necessary discussion on whether XML is appropriate occurrin= g on >a separate thread, I conducted a superficial crosswalk of >draft-teague-open-threat-signaling-00 and draft-fu-ipfix-network-securit= y >against existing MILE drafts to see how the information models line up. >There is some overlap. These observations are anecdotally enumerated >below. A more detailed analysis would be required if an XML representat= ion >or linkages with MILE was deemed appropriate. > >Both DOTS drafts have various counters in their IPFIX information models= , >MILE's IODEF (draft-ietf-mile-rfc5070-bis-11) can represent many of the = them. >For example, draft-fu-ipfix-network-security's tcpFinTotalCount field wo= uld >look as follows in IODEF: > > > >
1.2.3.4
> > > 1 > > 29234 > Allow me also first ignore whether xml is appropriate. IMO, IODEF should pr= ovide flow representation if it is used to represent IPFIX parameters of se= veral sampled flows, is it possible? Cheers, Ana =20 >However, there are certain counters such as >draft-teague-open-threat-signaling's Typical Pps that IODEF does not >represent. > >draft-teague-open-threat-signaling encodes threat information which IODE= F >appears could represent in the Method class. > >Finally, there are packet specific features of flows (e.g., >draft-fu-ipfix-network-security's maximumIpTotalLength) that IODEF doesn= 't >represent. Likewise, most of the elements of >draft-teague-open-threat-signaling's JSON channel don't align with MILE'= s RID >or IODEF. > >In most cases where IODEF is lacking, there appears to be a way to creat= e an >extension. > >Roman >_______________________________________________ >Dots mailing list >Dots@ietf.org >https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 20 06:49:44 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE561B2BAF for ; Mon, 20 Apr 2015 06:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NbhxoX6yNE4 for ; Mon, 20 Apr 2015 06:49:42 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E9A1B2BB0 for ; Mon, 20 Apr 2015 06:49:42 -0700 (PDT) Received: by wiun10 with SMTP id n10so92355109wiu.1 for ; Mon, 20 Apr 2015 06:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=1xYWlRXq11k+6YeggaKzYPM2wjHs1plvbBEp2N/K2zE=; b=bHiZhxw8TPHgG9EJy4llATer4j+YYkDh+8pc55tJAIeoU3k+kbLyFgD+LNSdeMwTHs vaY85PfGGo/AIX2FdwIkYeYiawddz/RZpsolRZVr2eu0JjR0Psan/F0xF5lFGI5HZPHr cO8xXT8oyBFjWIdX74Hi2H8F3Lmzx0TJhXFW6etM5dWKIGZ2khK7u1bn5cSy0vh3aVDt iw6X4HL3x6KWc8j4Or1LWnUTpBOq6DaIhuc6ywarpGqqpXRApjU2CBecudx60U5WiU7J G8FW5d2xQy+8Y/hqU8QuqTiJRuCuZzWlMWzv4id4cCSJAB+rDt5Xv1wlQ0CTxpzMkXaB TNOA== MIME-Version: 1.0 X-Received: by 10.194.189.12 with SMTP id ge12mr20923315wjc.83.1429537780740; Mon, 20 Apr 2015 06:49:40 -0700 (PDT) Received: by 10.194.11.2 with HTTP; Mon, 20 Apr 2015 06:49:40 -0700 (PDT) In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C15EF577@eusaamb107.ericsson.se> References: <20150420134322.6798.72876.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C15EF577@eusaamb107.ericsson.se> Date: Mon, 20 Apr 2015 09:49:40 -0400 Message-ID: From: Daniel Migault To: dots@ietf.org Content-Type: multipart/alternative; boundary=047d7bacc0069d36c405142833a9 Archived-At: Subject: [Dots] Fwd: FW: New Version Notification for draft-mglt-dots-use-cases-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 13:49:44 -0000 --047d7bacc0069d36c405142833a9 Content-Type: text/plain; charset=UTF-8 Hi, Please find a use case document for DDoS Open Threat Signaling. This is a first version, so feel free to comment. I hope it will be useful to help defining the scope of the WG. BR, Daniel -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, April 20, 2015 9:43 AM To: Daniel Migault; Daniel Migault Subject: New Version Notification for draft-mglt-dots-use-cases-00.txt A new version of I-D, draft-mglt-dots-use-cases-00.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-dots-use-cases Revision: 00 Title: DDoS Open Threat Signaling use cases Document date: 2015-04-20 Group: Individual Submission Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-mglt-dots-use-cases-00.txt Status: https://datatracker.ietf.org/doc/draft-mglt-dots-use-cases/ Htmlized: http://tools.ietf.org/html/draft-mglt-dots-use-cases-00 Abstract: The document details use cases to mitigate DDoS attacks. These use cases are expected to illustrates involved communications to detect and mitigate DDoS attacks. It is expected that these communications will be in the future handled by the DDoS Open Threat Signaling (DOTS). These scenarios are intended to be useful to derive requirements for the design of DDoS Open threat Signaling. 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 -- Daniel Migault Ericsson --047d7bacc0069d36c405142833a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please find a use case do= cument for DDoS Open Threat Signaling. This is a first version, so feel fre= e to comment. I hope it will be useful to help defining the scope of the WG= .

BR,
Daniel=C2=A0

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Monday, April 20, 2015 9:43 AM
To: Daniel Migault; Daniel Migault
Subject: New Version Notification for draft-mglt-dots-use-cases-00.txt


A new version of I-D, draft-mglt-dots-use-cases-00.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mglt-dots-use-cases
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DDoS Open Threat Signaling use cas= es
Document date:=C2=A0 2015-04-20
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http:= //www.ietf.org/internet-drafts/draft-mglt-dots-use-cases-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker= .ietf.org/doc/draft-mglt-dots-use-cases/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/d= raft-mglt-dots-use-cases-00


Abstract:
=C2=A0 =C2=A0The document details use cases to mitigate DDoS attacks.=C2=A0= These use
=C2=A0 =C2=A0cases are expected to illustrates involved communications to d= etect
=C2=A0 =C2=A0and mitigate DDoS attacks.=C2=A0 It is expected that these com= munications
=C2=A0 =C2=A0will be in the future handled by the DDoS Open Threat Signalin= g
=C2=A0 =C2=A0(DOTS).=C2=A0 These scenarios are intended to be useful to der= ive
=C2=A0 =C2=A0requirements for the design of DDoS Open threat Signaling.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Daniel Migault
Ericsson
--047d7bacc0069d36c405142833a9-- From nobody Tue Apr 21 09:24:38 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C191AD0B3 for ; Tue, 21 Apr 2015 09:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKfgPSo-jPx3 for ; Tue, 21 Apr 2015 09:24:35 -0700 (PDT) Received: from mail-oi0-f97.google.com (mail-oi0-f97.google.com [209.85.218.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 4AC6A1AD0BC for ; Tue, 21 Apr 2015 09:24:33 -0700 (PDT) Received: by oiax69 with SMTP id x69so6716610oia.0 for ; Tue, 21 Apr 2015 09:24:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:user-agent:content-type :content-id:content-transfer-encoding:mime-version; bh=uUaACaVtJUCE91uq4+7YjRWEkKvIfJNTit/XMVhWNFY=; b=MlJfddSEazFYLyf1HfGM9NdzRxCdJL7jASV86UgfePYon+AZ1kfhKCUP35lEqtM6Ut /JAnyKOkuCsesEqfGHKAukyGIRBuBkDroF7/6526WfZU7wYT2ngMnBTngzXPXhoyFFjy xpy1aWn0lrPkO/7YyTaNqR2hsT92UW5W0qeBga4DeaE5qXywyU7dTcK4iTpDDzmXlHOZ aW2i7brdqmgETlMrPttEeluHtn954llu3ArIsg92/g6iBbttTVXig8Jt2nt07WuCJ2Sp uTzLTzwgLOJUAlqKngeLfjAGPXfnIhXaD9CPdnLY0dAnkp9KjeJbAjPIvMXubnre5FxU PaBw== X-Gm-Message-State: ALoCoQnanspDdBOl2iHK+qfBJa7Ik1TBbNFhCujoaYcHVisIDz/Ako+91nmDW4zduPrkvZbfEtHyOE9WN/VmE8y8npj5ZuGX9w== X-Received: by 10.55.31.40 with SMTP id f40mr39627496qkf.49.1429633472737; Tue, 21 Apr 2015 09:24:32 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id bn4sm628605qcb.1.2015.04.21.09.24.32 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 21 Apr 2015 09:24:32 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t3LGOVgD029920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Apr 2015 12:24:31 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 21 Apr 2015 12:24:32 -0400 From: "Teague, Nik" To: "dots@ietf.org" Thread-Topic: Draft Charter Thread-Index: AQHQfE+l/Sly82ObQkmwTXHnIFPOXA== Date: Tue, 21 Apr 2015 16:24:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 16:24:37 -0000 Hi, Please see a 1st pass draft charter below - comments and feedback always welcome. -Nik The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards based approach to the real time signaling of DDoS related telemetry and threat handling data between elements concerned with attack mitigation. The elements may be described as: * On-premise DDoS mitigation platforms * Service provider DDoS mitigation platforms * Other network devices/platforms that are able to sense DDoS and respond * Chained instances of the above These elements may be communicating inter-domain or intra-domain over links that may be congested by attack traffic resulting in hostile conditions for traditional connection oriented approaches and more generalized signaling and telemetry solutions. Robustness under these conditions is paramount while ensuring appropriate regard for authentication, authorization, privacy and data integrity. Elements may be deployed as part of a wider strategy incorporating multiple points of detection and mitigation, both on premise or service provider based. Should mitigation need to move between elements in the chain then effective signaling of telemetry and current threat handling is essential. Feedback between participating elements is required for increased awareness for effective decision making. The WG will, where appropriate, reuse existing standard protocols and mechanisms, for instance IPFIX and its templating mechanism. The charter of the working group is to produce one or more standards track specification to provide for this open signaling in the DDoS problem space. While the resulting standards should be designed so that there=B9s = a possibility of applying them to network security applications beyond DDoS mitigation, this working group will focus on just DDoS mitigation. This streamlined focus of the charter is intended to lead to an earlier result due to community interests in having such capability in a short timeframe. The specification(s) produced by the WG will include a standard mechanism for authentication and authorization, for data integrity, and for providing for privacy in operation. The WG will produce the following deliverables: * Use case document to ensure commonality of the work among the participants in the Working Group. This document may be determined by the working group to remain informal and not be published. * Document or Documents describing the problem space, use cases, protocol requirements and other qualifying information as the WG sees fit. * Document or Documents specifying a protocol and associated data models to address the WG stated goal. From nobody Tue Apr 21 09:42:08 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF381B29AA for ; Tue, 21 Apr 2015 09:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvhBA5RhAmbb for ; Tue, 21 Apr 2015 09:42:04 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.98]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A99F1B29E3 for ; Tue, 21 Apr 2015 09:40:13 -0700 (PDT) Received: from [216.82.253.227] by server-2.bemta-7.messagelabs.com id 5B/92-04694-C6D76355; Tue, 21 Apr 2015 16:40:12 +0000 X-Env-Sender: Dave.Larson@corero.com X-Msg-Ref: server-14.tower-170.messagelabs.com!1429634411!24691483!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 749 invoked from network); 21 Apr 2015 16:40:12 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-14.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 21 Apr 2015 16:40:12 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0224.002; Tue, 21 Apr 2015 12:40:11 -0400 From: Dave Larson To: "Teague, Nik" , "dots@ietf.org" Thread-Topic: [Dots] Draft Charter Thread-Index: AQHQfFHVCFk3V4v99UStTbKvqxZK1g== Date: Tue, 21 Apr 2015 16:40:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [169.130.41.242] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 16:42:06 -0000 VGhpcyBpcyBleGNlbGxlbnQgTmlrLg0KDQpJdCBpcyBjcml0aWNhbCB0aGF0IHdlIHN0YXkgZm9j dXNlZCBvbiBzb21ldGhpbmcgdGhhdCBjYW4gc2hvdyBiZW5lZml0IGFzDQplYXJseSBhcyBwb3Nz aWJsZSBhbmQgSSB0aGluayB0aGlzIGNoYXJ0ZXIgZWZmZWN0aXZlbHkgZW5zdXJlcyB0aGF0Lg0K DQpCZXN0LA0KDQpEYXZlDQoNCk9uIDQvMjEvMTUsIDk6MjQgQU0sICJUZWFndWUsIE5payIgPG50 ZWFndWVAdmVyaXNpZ24uY29tPiB3cm90ZToNCg0KPkhpLA0KPg0KPlBsZWFzZSBzZWUgYSAxc3Qg cGFzcyBkcmFmdCBjaGFydGVyIGJlbG93IC0gY29tbWVudHMgYW5kIGZlZWRiYWNrIGFsd2F5cw0K PndlbGNvbWUuDQo+DQo+LU5paw0KPg0KPg0KPlRoZSBhaW0gb2YgRERvUyBPcGVuIFRocmVhdCBT aWduYWxpbmcgKERPVFMpIGlzIHRvIGRldmVsb3AgYSBzdGFuZGFyZHMNCj5iYXNlZCBhcHByb2Fj aCB0byB0aGUgcmVhbCB0aW1lIHNpZ25hbGluZyBvZiBERG9TIHJlbGF0ZWQgdGVsZW1ldHJ5IGFu ZA0KPnRocmVhdCBoYW5kbGluZyBkYXRhIGJldHdlZW4gZWxlbWVudHMgY29uY2VybmVkIHdpdGgg YXR0YWNrIG1pdGlnYXRpb24uDQo+DQo+VGhlIGVsZW1lbnRzIG1heSBiZSBkZXNjcmliZWQgYXM6 DQo+KiBPbi1wcmVtaXNlIEREb1MgbWl0aWdhdGlvbiBwbGF0Zm9ybXMNCj4qIFNlcnZpY2UgcHJv dmlkZXIgRERvUyBtaXRpZ2F0aW9uIHBsYXRmb3Jtcw0KPiogT3RoZXIgbmV0d29yayBkZXZpY2Vz L3BsYXRmb3JtcyB0aGF0IGFyZSBhYmxlIHRvIHNlbnNlIEREb1MgYW5kIHJlc3BvbmQNCj4qIENo YWluZWQgaW5zdGFuY2VzIG9mIHRoZSBhYm92ZQ0KPg0KPlRoZXNlIGVsZW1lbnRzIG1heSBiZSBj b21tdW5pY2F0aW5nIGludGVyLWRvbWFpbiBvciBpbnRyYS1kb21haW4gb3Zlcg0KPmxpbmtzIHRo YXQgbWF5IGJlIGNvbmdlc3RlZCBieSBhdHRhY2sgdHJhZmZpYyByZXN1bHRpbmcgaW4gaG9zdGls ZQ0KPmNvbmRpdGlvbnMgZm9yIHRyYWRpdGlvbmFsIGNvbm5lY3Rpb24gb3JpZW50ZWQgYXBwcm9h Y2hlcyBhbmQgbW9yZQ0KPmdlbmVyYWxpemVkIHNpZ25hbGluZyBhbmQgdGVsZW1ldHJ5IHNvbHV0 aW9ucy4gIFJvYnVzdG5lc3MgdW5kZXIgdGhlc2UNCj5jb25kaXRpb25zIGlzIHBhcmFtb3VudCB3 aGlsZSBlbnN1cmluZyBhcHByb3ByaWF0ZSByZWdhcmQgZm9yDQo+YXV0aGVudGljYXRpb24sIGF1 dGhvcml6YXRpb24sIHByaXZhY3kgYW5kIGRhdGEgaW50ZWdyaXR5LiAgRWxlbWVudHMgbWF5DQo+ YmUgZGVwbG95ZWQgYXMgcGFydCBvZiBhIHdpZGVyIHN0cmF0ZWd5IGluY29ycG9yYXRpbmcgbXVs dGlwbGUgcG9pbnRzIG9mDQo+ZGV0ZWN0aW9uIGFuZCBtaXRpZ2F0aW9uLCBib3RoIG9uIHByZW1p c2Ugb3Igc2VydmljZSBwcm92aWRlciBiYXNlZC4NCj5TaG91bGQgbWl0aWdhdGlvbiBuZWVkIHRv IG1vdmUgYmV0d2VlbiBlbGVtZW50cyBpbiB0aGUgY2hhaW4gdGhlbg0KPmVmZmVjdGl2ZSBzaWdu YWxpbmcgb2YgdGVsZW1ldHJ5IGFuZCBjdXJyZW50IHRocmVhdCBoYW5kbGluZyBpcyBlc3NlbnRp YWwuDQo+IEZlZWRiYWNrIGJldHdlZW4gcGFydGljaXBhdGluZyBlbGVtZW50cyBpcyByZXF1aXJl ZCBmb3IgaW5jcmVhc2VkDQo+YXdhcmVuZXNzIGZvciBlZmZlY3RpdmUgZGVjaXNpb24gbWFraW5n Lg0KPg0KPlRoZSBXRyB3aWxsLCB3aGVyZSBhcHByb3ByaWF0ZSwgcmV1c2UgZXhpc3Rpbmcgc3Rh bmRhcmQgcHJvdG9jb2xzIGFuZA0KPm1lY2hhbmlzbXMsIGZvciBpbnN0YW5jZSBJUEZJWCBhbmQg aXRzIHRlbXBsYXRpbmcgbWVjaGFuaXNtLg0KPg0KPlRoZSBjaGFydGVyIG9mIHRoZSB3b3JraW5n IGdyb3VwIGlzIHRvIHByb2R1Y2Ugb25lIG9yIG1vcmUgc3RhbmRhcmRzIHRyYWNrDQo+c3BlY2lm aWNhdGlvbiB0byBwcm92aWRlIGZvciB0aGlzIG9wZW4gc2lnbmFsaW5nIGluIHRoZSBERG9TIHBy b2JsZW0NCj5zcGFjZS4gIFdoaWxlIHRoZSByZXN1bHRpbmcgc3RhbmRhcmRzIHNob3VsZCBiZSBk ZXNpZ25lZCBzbyB0aGF0IHRoZXJlqfZzIGENCj5wb3NzaWJpbGl0eSBvZiBhcHBseWluZyB0aGVt IHRvIG5ldHdvcmsgc2VjdXJpdHkgYXBwbGljYXRpb25zIGJleW9uZCBERG9TDQo+bWl0aWdhdGlv biwgdGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgZm9jdXMgb24ganVzdCBERG9TIG1pdGlnYXRpb24u ICBUaGlzDQo+c3RyZWFtbGluZWQgZm9jdXMgb2YgdGhlIGNoYXJ0ZXIgaXMgaW50ZW5kZWQgdG8g bGVhZCB0byBhbiBlYXJsaWVyIHJlc3VsdA0KPmR1ZSB0byBjb21tdW5pdHkgaW50ZXJlc3RzIGlu IGhhdmluZyBzdWNoIGNhcGFiaWxpdHkgaW4gYSBzaG9ydCB0aW1lZnJhbWUuDQo+IFRoZSBzcGVj aWZpY2F0aW9uKHMpIHByb2R1Y2VkIGJ5IHRoZSBXRyB3aWxsIGluY2x1ZGUgYSBzdGFuZGFyZCBt ZWNoYW5pc20NCj5mb3IgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24sIGZvciBkYXRh IGludGVncml0eSwgYW5kIGZvcg0KPnByb3ZpZGluZyBmb3IgcHJpdmFjeSBpbiBvcGVyYXRpb24u DQo+DQo+VGhlIFdHIHdpbGwgcHJvZHVjZSB0aGUgZm9sbG93aW5nIGRlbGl2ZXJhYmxlczoNCj4N Cj4qIFVzZSBjYXNlIGRvY3VtZW50IHRvIGVuc3VyZSBjb21tb25hbGl0eSBvZiB0aGUgd29yayBh bW9uZyB0aGUNCj5wYXJ0aWNpcGFudHMgaW4gdGhlIFdvcmtpbmcgR3JvdXAuICBUaGlzIGRvY3Vt ZW50IG1heSBiZSBkZXRlcm1pbmVkIGJ5IHRoZQ0KPndvcmtpbmcgZ3JvdXAgdG8gcmVtYWluIGlu Zm9ybWFsIGFuZCBub3QgYmUgcHVibGlzaGVkLg0KPiogRG9jdW1lbnQgb3IgRG9jdW1lbnRzIGRl c2NyaWJpbmcgdGhlIHByb2JsZW0gc3BhY2UsIHVzZSBjYXNlcywgcHJvdG9jb2wNCj5yZXF1aXJl bWVudHMgYW5kIG90aGVyIHF1YWxpZnlpbmcgaW5mb3JtYXRpb24gYXMgdGhlIFdHIHNlZXMgZml0 Lg0KPiogRG9jdW1lbnQgb3IgRG9jdW1lbnRzIHNwZWNpZnlpbmcgYSBwcm90b2NvbCBhbmQgYXNz b2NpYXRlZCBkYXRhIG1vZGVscw0KPnRvIGFkZHJlc3MgdGhlIFdHIHN0YXRlZCBnb2FsLg0KPg0K Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+RG90cyBt YWlsaW5nIGxpc3QNCj5Eb3RzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kb3RzDQoNCg== From nobody Tue Apr 21 15:55:48 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EFC1B2DFA; Tue, 21 Apr 2015 15:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUdyrLKVvEWr; Tue, 21 Apr 2015 15:55:42 -0700 (PDT) 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 8707B1B2DFB; Tue, 21 Apr 2015 15:55:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVD24326; Tue, 21 Apr 2015 22:55:38 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Apr 2015 23:55:37 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Tue, 21 Apr 2015 15:55:35 -0700 From: Linda Dunbar To: "i2nsf@ietf.org" Thread-Topic: New Version Notification for draft-merged-i2nsf-framework-00.txt Thread-Index: AQHQfINyor7fMB1FSUC6JcO7boLwQJ1YDq9g Date: Tue, 21 Apr 2015 22:55:35 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C087D9@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.84] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C087D9dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "pcp@ietf.org" , "dots@ietf.org" , "sacm@ietf.org" Subject: [Dots] FW: New Version Notification for draft-merged-i2nsf-framework-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 22:55:45 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C087D9dfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGZyYW1ld29yayBmb3IgSW50ZXJmYWNlIHRvIE5l dHdvcmsgU2VjdXJpdHkgRnVuY3Rpb25zIGFuZCBkZWZpbmVzIGEgcmVmZXJlbmNlIG1vZGVsIGFs b25nIHdpdGggZnVuY3Rpb25hbCBjb21wb25lbnRzLg0KDQoNCkNvcHkgdG8gRE9UUy9QQ1AvU0FD TSBhdWRpZW5jZSBpbiBob3BlIGZvciBnZXR0aW5nIGZlZWRiYWNrIGZyb20gd2lkZXIgYXVkaWVu Y2UuIEkyTlNGIGlzIGFib3V0IHNlY3VyaXR5IGZ1bmN0aW9ucyBtYW5hZ2VtZW50LCBpLmUuIGhv dyBjdXN0b21lcnMgY2FuIHJlcXVlc3QgJiBtb25pdG9yIHRoZWlyIGRlc2lyZWQgc2VjdXJpdHkg cG9saWNpZXMgZnJvbSBzZWN1cml0eSBzZXJ2aWNlIHByb3ZpZGVycyBhbmQgaW50ZXJmYWNlIHRv IG1hbmFnZS9tb25pdG9yIHBhY2tldCBiYXNlZCBzZWN1cml0eSBmdW5jdGlvbnMgZnJvbSBtdWx0 aXBsZSB2ZW5kb3JzLCB3aGVyZWFzIERPVFMgaXMgdGhlIGluZm9ybWF0aW9uIGV4Y2hhbmdlIGJl dHdlZW4gbXVsdGlwbGUgQW50aURvUyBmdW5jdGlvbnMuDQoNClRoZXJlIGFyZSB0d28gYXNwZWN0 cyBvZiBJMk5TRjoNCjEpICB0aGUgc2VjdXJpdHkgcG9saWN5IGluZm9ybWF0aW9uIGV4Y2hhbmdl IGJldHdlZW4gY3VzdG9tZXJzIGFuZCB0aGUgc2VydmljZSBwcm92aWRlciB0aGF0IG9mZmVycyB0 aGUgaG9zdGVkIHNlY3VyaXR5IGZ1bmN0aW9ucw0KMikgdGhlIHNlY3VyZSBjaGFubmVsIGZvciB0 aGUgaW5mb3JtYXRpb24gZXhjaGFuZ2UsICh3aGljaCBjYW4gYmUgYWNoaWV2ZWQgYnkgVExTIG9y IFNBU0wgb3IgY29tYmluYXRpb24gb2YgdGhlbSApDQoNCkkyTlNGJ3MgZmlyc3Qgc3RlcCB3aWxs IGZvY3VzIG9uIDEpIGFib3ZlLiBUaGUgImNvbW11bmljYXRpb24gc2VjdXJpdHkiICgyKSBhYm92 ZSBpcyBzZWNvbmRhcnkuDQoNClRoZSBJMk5TRiBmcmFtZXdvcmsgdXRpbGl6ZXMgdGhlIGNhdGVn b3JpZXMgY2hhcmFjdGVyaXplZCBieSBkcmFmdC1sb3Blei1pMm5zZi1wYWNrZXQtMDAgZm9yIE5T RjoNCg0K4oCiICAgICAgIFN1YmplY3Qg4oCTIG1hdGNoIHZhbHVlcyBiYXNlZCBvbiBwYWNrZXQg ZGF0YQ0KICAgICAgUGFja2V0IGhlYWRlciAtIENhbiBiZSBzdGFuZGFyZGl6ZWQNCiAgICAgIFBh Y2tldCBwYXlsb2FkIC0gUHJvdmlkZWQgYnkgTlNGIGNhcGFiaWxpdGllcw0K4oCiICAgICAgIE9i amVjdCDigJMgbWF0Y2ggdmFsdWVzIGJhc2VkIG9uIGNvbnRleHQNCiAgICAgIEV4LjogU3RhdGUs IHRpbWUsIGdlby1sb2NhdGlvbiwgZXRjLg0KICAgICAgTWFueSBjYW4gKGFuZCBzaG91bGQpIGJl IHN0YW5kYXJkaXplZCwgYnV0IG1hbnkgYWxzbyBmcm9tIE5TRiBjYXBhYmlsaXRpZXMNCuKAoiAg ICAgICBGdW5jdGlvbiDigJMgaW52b2tlZCBzZWN1cml0eSBmdW5jdGlvbg0KICAgICAgRGVmaW5l ZCBieSBOU0YgY2FwYWJpbGl0aWVzDQogICAgICBGdW5jdGlvbjpJbnN0YW5jZSAoZXguIElQUzo8 c2lnbmF0dXJlIGJhc2U+IHdoaWNoIGNhbiBiZSBwcm92aWRlZCBieSB2ZW5kb3JzKQ0K4oCiICAg ICAgIEFjdGlvbiDigJMgZWdyZXNzIHByb2Nlc3NpbmcNCiAgICAgIEludm9rZSBzaWduYWxpbmcN CiAgICAgIFBhY2tldCBmb3J3YXJkaW5nIGFuZC9vciB0cmFuc2Zvcm1hdGlvbg0KICAgICAgUG9z c2liaWxpdHkgZm9yIFNETi9ORlYgaW50ZWdyYXRpb24NCg0KDQpBbnkgZmVlZGJhY2ssIGNvbW1l bnRzIG9yIHN1Z2dlc3Rpb25zIGFyZSBncmVhdGx5IGFwcHJlY2lhdGVkLg0KDQpDaGVlcnMsDQpM aW5kYQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQpTZW50OiBUdWVz ZGF5LCBBcHJpbCAyMSwgMjAxNSA1OjM1IFBNDQpUbzogSm9lIFBhcnJvdHQ7IFNlZXRoYXJhbWEg UmFvIER1cmJoYTsgWGlhb2p1biBaaHVhbmc7IExpbmRhIER1bmJhcjsgTGluZGEgRHVuYmFyOyBE aWVnbyBMb3BlejsgU2VldGhhcmFtYSBSYW8gRHVyYmhhOyBSYW0gKFJhbWtpKSBLcmlzaG5hbjsg RGllZ28gTG9wZXo7IFhpYW9KdW4gWmh1YW5nOyBKb2UgUGFycm90dDsgUmFta2kgS3Jpc2huYW4N ClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWVyZ2VkLWkybnNm LWZyYW1ld29yay0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWVyZ2Vk LWkybnNmLWZyYW1ld29yay0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgTGluZGEgRHVuYmFyIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFt ZTogICAgICAgICAgIGRyYWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcmsNClJldmlzaW9uOiAgICAg ICAwMA0KVGl0bGU6ICAgICAgICAgIEZyYW1ld29yayBmb3IgSW50ZXJmYWNlIHRvIE5ldHdvcmsg U2VjdXJpdHkgRnVuY3Rpb25zDQpEb2N1bWVudCBkYXRlOiAgMjAxNS0wNC0yMQ0KR3JvdXA6ICAg ICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDE2DQpVUkw6ICAg ICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWVyZ2Vk LWkybnNmLWZyYW1ld29yay0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1tZXJnZWQtaTJuc2YtZnJhbWV3b3JrLw0KSHRtbGl6ZWQ6 ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1lcmdlZC1pMm5zZi1mcmFt ZXdvcmstMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBm cmFtZXdvcmsgZm9yIEludGVyZmFjZSB0byBOZXR3b3JrDQogICBTZWN1cml0eSBGdW5jdGlvbnMg YW5kIGRlZmluZXMgYSByZWZlcmVuY2UgbW9kZWwgYWxvbmcgd2l0aA0KICAgZnVuY3Rpb25hbCBj b21wb25lbnRzLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K --_000_4A95BA014132FF49AE685FAB4B9F17F657C087D9dfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDb25zb2xhcyIgc2l6ZT0iMiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Ij4NCjxkaXY+VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhl IGZyYW1ld29yayBmb3IgSW50ZXJmYWNlIHRvIE5ldHdvcmsgU2VjdXJpdHkgRnVuY3Rpb25zIGFu ZCBkZWZpbmVzIGEgcmVmZXJlbmNlIG1vZGVsIGFsb25nIHdpdGggZnVuY3Rpb25hbCBjb21wb25l bnRzLiA8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj5Db3B5IHRvIERPVFMvUENQL1NBQ00g YXVkaWVuY2UgaW4gaG9wZSBmb3IgZ2V0dGluZyBmZWVkYmFjayBmcm9tIHdpZGVyIGF1ZGllbmNl LiBJMk5TRiBpcyBhYm91dCBzZWN1cml0eSBmdW5jdGlvbnMgbWFuYWdlbWVudCwgaS5lLiBob3cg Y3VzdG9tZXJzIGNhbiByZXF1ZXN0ICZhbXA7IG1vbml0b3IgdGhlaXIgZGVzaXJlZCBzZWN1cml0 eSBwb2xpY2llcyBmcm9tIHNlY3VyaXR5IHNlcnZpY2UgcHJvdmlkZXJzIGFuZCBpbnRlcmZhY2Ug dG8gbWFuYWdlL21vbml0b3INCnBhY2tldCBiYXNlZCBzZWN1cml0eSBmdW5jdGlvbnMgZnJvbSBt dWx0aXBsZSB2ZW5kb3JzLCB3aGVyZWFzIERPVFMgaXMgdGhlIGluZm9ybWF0aW9uIGV4Y2hhbmdl IGJldHdlZW4gbXVsdGlwbGUgQW50aURvUyBmdW5jdGlvbnMuIDwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+VGhlcmUgYXJl IHR3byBhc3BlY3RzIG9mIEkyTlNGOjwvZGl2Pg0KPGRpdj4xKSZuYnNwOyB0aGUgc2VjdXJpdHkg cG9saWN5IGluZm9ybWF0aW9uIGV4Y2hhbmdlIGJldHdlZW4gY3VzdG9tZXJzIGFuZCB0aGUgc2Vy dmljZSBwcm92aWRlciB0aGF0IG9mZmVycyB0aGUgaG9zdGVkIHNlY3VyaXR5IGZ1bmN0aW9ucyA8 L2Rpdj4NCjxkaXY+MikgdGhlIHNlY3VyZSBjaGFubmVsIGZvciB0aGUgaW5mb3JtYXRpb24gZXhj aGFuZ2UsICh3aGljaCBjYW4gYmUgYWNoaWV2ZWQgYnkgVExTIG9yIFNBU0wgb3IgY29tYmluYXRp b24gb2YgdGhlbSApPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JMk5TRidzIGZpcnN0 IHN0ZXAgd2lsbCBmb2N1cyBvbiAxKSBhYm92ZS4gVGhlICZxdW90O2NvbW11bmljYXRpb24gc2Vj dXJpdHkmcXVvdDsgKDIpIGFib3ZlIGlzIHNlY29uZGFyeS4gPC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj5UaGUgSTJOU0YgZnJhbWV3b3JrIHV0aWxpemVzIHRoZSBjYXRlZ29yaWVzIGNo YXJhY3Rlcml6ZWQgYnkgZHJhZnQtbG9wZXotaTJuc2YtcGFja2V0LTAwIGZvciBOU0Y6PC9kaXY+ DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj7igKImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgU3ViamVjdCDigJMgbWF0Y2ggdmFsdWVzIGJhc2VkIG9uIHBhY2tldCBkYXRhPC9k aXY+DQo8ZGl2IHN0eWxlPSJwYWRkaW5nLWxlZnQ6MzZwdDsiPlBhY2tldCBoZWFkZXIgLSBDYW4g YmUgc3RhbmRhcmRpemVkPC9kaXY+DQo8ZGl2IHN0eWxlPSJwYWRkaW5nLWxlZnQ6MzZwdDsiPlBh Y2tldCBwYXlsb2FkIC0gUHJvdmlkZWQgYnkgTlNGIGNhcGFiaWxpdGllczwvZGl2Pg0KPGRpdj7i gKImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT2JqZWN0IOKAkyBtYXRjaCB2 YWx1ZXMgYmFzZWQgb24gY29udGV4dDwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0OjM2 cHQ7Ij5FeC46IFN0YXRlLCB0aW1lLCBnZW8tbG9jYXRpb24sIGV0Yy48L2Rpdj4NCjxkaXYgc3R5 bGU9InBhZGRpbmctbGVmdDozNnB0OyI+TWFueSBjYW4gKGFuZCBzaG91bGQpIGJlIHN0YW5kYXJk aXplZCwgYnV0IG1hbnkgYWxzbyBmcm9tIE5TRiBjYXBhYmlsaXRpZXM8L2Rpdj4NCjxkaXY+4oCi Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZ1bmN0aW9uIOKAkyBpbnZva2Vk IHNlY3VyaXR5IGZ1bmN0aW9uPC9kaXY+DQo8ZGl2IHN0eWxlPSJwYWRkaW5nLWxlZnQ6MzZwdDsi PkRlZmluZWQgYnkgTlNGIGNhcGFiaWxpdGllczwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1s ZWZ0OjM2cHQ7Ij5GdW5jdGlvbjpJbnN0YW5jZSAoZXguIElQUzombHQ7c2lnbmF0dXJlIGJhc2Um Z3Q7IHdoaWNoIGNhbiBiZSBwcm92aWRlZCBieSB2ZW5kb3JzKTwvZGl2Pg0KPGRpdj7igKImbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQWN0aW9uIOKAkyBlZ3Jlc3MgcHJvY2Vz c2luZzwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0OjM2cHQ7Ij5JbnZva2Ugc2lnbmFs aW5nPC9kaXY+DQo8ZGl2IHN0eWxlPSJwYWRkaW5nLWxlZnQ6MzZwdDsiPlBhY2tldCBmb3J3YXJk aW5nIGFuZC9vciB0cmFuc2Zvcm1hdGlvbjwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0 OjM2cHQ7Ij5Qb3NzaWJpbGl0eSBmb3IgU0ROL05GViBpbnRlZ3JhdGlvbjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2PkFueSBm ZWVkYmFjaywgY29tbWVudHMgb3Igc3VnZ2VzdGlvbnMgYXJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQu IDwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48 L2Rpdj4NCjxkaXY+Q2hlZXJzLCA8L2Rpdj4NCjxkaXY+TGluZGE8L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjwv ZGl2Pg0KPGRpdj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCg0KRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIj5tYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPl0NCjxicj4NCg0KU2VudDog VHVlc2RheSwgQXByaWwgMjEsIDIwMTUgNTozNSBQTTxicj4NCg0KVG86IEpvZSBQYXJyb3R0OyBT ZWV0aGFyYW1hIFJhbyBEdXJiaGE7IFhpYW9qdW4gWmh1YW5nOyBMaW5kYSBEdW5iYXI7IExpbmRh IER1bmJhcjsgRGllZ28gTG9wZXo7IFNlZXRoYXJhbWEgUmFvIER1cmJoYTsgUmFtIChSYW1raSkg S3Jpc2huYW47IERpZWdvIExvcGV6OyBYaWFvSnVuIFpodWFuZzsgSm9lIFBhcnJvdHQ7IFJhbWtp IEtyaXNobmFuPGJyPg0KDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcmstMDAudHh0PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+QSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcmstMDAudHh0PC9kaXY+DQo8ZGl2Pmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTGluZGEgRHVuYmFyIGFuZCBwb3N0ZWQg dG8gdGhlIElFVEYgcmVwb3NpdG9yeS48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk5h bWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGRyYWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcms8L2Rpdj4NCjxkaXY+UmV2aXNpb246 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAwPC9kaXY+DQo8ZGl2PlRpdGxl OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBG cmFtZXdvcmsgZm9yIEludGVyZmFjZSB0byBOZXR3b3JrIFNlY3VyaXR5IEZ1bmN0aW9uczwvZGl2 Pg0KPGRpdj5Eb2N1bWVudCBkYXRlOiZuYnNwOyAyMDE1LTA0LTIxPC9kaXY+DQo8ZGl2Pkdyb3Vw OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJ bmRpdmlkdWFsIFN1Ym1pc3Npb248L2Rpdj4NCjxkaXY+UGFnZXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE2PC9kaXY+DQo8ZGl2PlVSTDom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtbWVyZ2VkLWkybnNmLWZyYW1ld29yay0wMC50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcmstMDAudHh0PC9hPjwvZGl2 Pg0KPGRpdj5TdGF0dXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1l cmdlZC1pMm5zZi1mcmFtZXdvcmsvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1tZXJnZWQtaTJuc2YtZnJhbWV3b3JrLzwvYT48L2Rpdj4NCjxkaXY+SHRtbGl6ZWQ6Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcmstMDAiPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcmstMDA8L2E+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxk aXY+QWJzdHJhY3Q6PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyB0aGUgZnJhbWV3b3JrIGZvciBJbnRlcmZhY2UgdG8gTmV0d29yazwvZGl2Pg0KPGRpdj4m bmJzcDsmbmJzcDsgU2VjdXJpdHkgRnVuY3Rpb25zIGFuZCBkZWZpbmVzIGEgcmVmZXJlbmNlIG1v ZGVsIGFsb25nIHdpdGg8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IGZ1bmN0aW9uYWwgY29tcG9u ZW50cy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlRoZSBJRVRGIFNlY3Jl dGFyaWF0PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657C087D9dfweml701chm_-- From nobody Wed Apr 22 06:35:26 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6160D1A1A02 for ; Wed, 22 Apr 2015 06:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1jUJzDoQHAq for ; Wed, 22 Apr 2015 06:35:23 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (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 428911A3BA7 for ; Wed, 22 Apr 2015 06:35:23 -0700 (PDT) Received: by pabsx10 with SMTP id sx10so273257168pab.3 for ; Wed, 22 Apr 2015 06:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MOaNkTSOnmuY+oglKXwfFTdxn1riIqCLW6ZoztBx3Uw=; b=xJGNItfrdO8z8oNkFFdWgSaHYf6mFmbE3H097A0ntVaJES1GgbuA/AYZrXH9g8/Uwl HqiWdZFnqI+t68ArB+UJKo7f/mPNYCxk6xpX0MBfd4Kxdg6EDWrm1tLVYeiLdjo9tcAT oX7VVX9HLeREMcXi1LTMVzzRSalBKwH4XnFnGW9yYQ+2QEp/P5l4lzWMatRDlnkxCBPt RFz4NXThu57xXcmvnjn1Sgyhk+Eub9UuB5WECvhxM8h6G4f9UagPgU4SfspqwzU3xP1M NJmDVPiD3meUYVCCMKF6htGVC/2jX4W4A/OqJxxGuiwHiy+L6S2ThKQH9jn+kdQ1vIBH h+wg== X-Received: by 10.66.102.34 with SMTP id fl2mr46823936pab.40.1429709722894; Wed, 22 Apr 2015 06:35:22 -0700 (PDT) Received: from adams-mac-mini.attlocal.net ([2602:306:3406:4830:79fd:6bbe:4c97:1e99]) by mx.google.com with ESMTPSA id l14sm4875513pdm.16.2015.04.22.06.35.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Apr 2015 06:35:21 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: "Adam W. Montville" In-Reply-To: Date: Wed, 22 Apr 2015 08:35:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1C8B68F6-75A6-4869-B03A-7DCFD0092437@gmail.com> References: To: "Teague, Nik" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 13:35:25 -0000 Well-written, Nik. I spotted a couple of minor nits (there may be = others), and have a couple of observations/comments - all inline. > On Apr 21, 2015, at 11:24 AM, Teague, Nik = wrote: >=20 > Hi, >=20 > Please see a 1st pass draft charter below - comments and feedback = always > welcome. >=20 > -Nik >=20 >=20 > The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards > based approach to the real time signaling of DDoS related telemetry = and > threat handling data between elements concerned with attack = mitigation. >=20 > The elements may be described as: > * On-premise DDoS mitigation platforms > * Service provider DDoS mitigation platforms > * Other network devices/platforms that are able to sense DDoS and = respond > * Chained instances of the above >=20 The first two points seem pretty tight, but the third bullet seems less = so. As a reader, it feels that you may have wanted to write something = like =93Other DDoS mitigation platforms=94, but didn=92t for what is = likely an important reason. Maybe another way to look at it is that the = first two bullets seem to be distinguished based on mitigation platform = location, but the third is a catch-all not necessarily related to = location. =20 This isn=92t a suggestion to change, but an observation you might choose = to consider to clarify your meaning. > These elements may be communicating inter-domain or intra-domain over > links that may be congested by attack traffic resulting in hostile > conditions for traditional connection oriented approaches and more > generalized signaling and telemetry solutions. Robustness under these > conditions is paramount while ensuring appropriate regard for > authentication, authorization, privacy and data integrity. Elements = may > be deployed as part of a wider strategy incorporating multiple points = of > detection and mitigation, both on premise or service provider based. > Should mitigation need to move between elements in the chain then > effective signaling of telemetry and current threat handling is = essential. Consider a comma between =93chain=94 and =93then=94 resulting in: = =93Should mitigation need to move between elements in the chain, then=85" > Feedback between participating elements is required for increased > awareness for effective decision making. Could this be =93=85required for increased awareness supporting = effective decision making=94? >=20 > The WG will, where appropriate, reuse existing standard protocols and > mechanisms, for instance IPFIX and its templating mechanism. Would it be helpful to also say that you intend (if you do) to = coordinate efforts with other working groups that may be working on = similar problems? Consider i2nsf, supa, sacm, and mile. Some of these = have standards you might leverage, but others are still working on = solutions. In sacm, for example, we are working to define models and = protocols based on endpoint posture assessment, which includes some = expression of policy, endpoint attributes, and so on. Pieces of these = things may be useful to dots. >=20 > The charter of the working group is to produce one or more standards = track > specification to provide for this open signaling in the DDoS problem > space. =20 Make =93specification=94 plural, so that the sentence reads: =93=85to = produce one or more standards track specifications=85=94. > While the resulting standards should be designed so that there=B9s a > possibility of applying them to network security applications beyond = DDoS > mitigation, this working group will focus on just DDoS mitigation. =20 The =91 in =93there=92s=94 came up funny (probably a copy/paste issue). > This > streamlined focus of the charter is intended to lead to an earlier = result > due to community interests in having such capability in a short = timeframe. > The specification(s) produced by the WG will include a standard = mechanism > for authentication and authorization, for data integrity, and for > providing for privacy in operation. >=20 > The WG will produce the following deliverables: >=20 > * Use case document to ensure commonality of the work among the > participants in the Working Group. This document may be determined by = the > working group to remain informal and not be published. > * Document or Documents describing the problem space, use cases, = protocol > requirements and other qualifying information as the WG sees fit. > * Document or Documents specifying a protocol and associated data = models > to address the WG stated goal. Something we recently did in sacm is to create a milestone for = revisiting milestones. The idea is that we know we=92re going to have = some data models and protocols, but we=92re not sure how many or how = they might be divided among multiple drafts. Something like that could = be useful here as well, because it is clear that you will have models = and protocols, but it=92s not clear how that work will ultimately = materialize. It might be too early, but do you have any idea as to dates for these = milestones? >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Apr 22 15:47:39 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045301B2C8F for ; Wed, 22 Apr 2015 15:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9dcPFq5pETs for ; Wed, 22 Apr 2015 15:47:36 -0700 (PDT) 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 0E2C31B3AFD for ; Wed, 22 Apr 2015 15:47:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVE36532; Wed, 22 Apr 2015 22:47:26 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Apr 2015 23:47:25 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Wed, 22 Apr 2015 15:47:21 -0700 From: Linda Dunbar To: "Adam W. Montville" , "Teague, Nik" Thread-Topic: [Dots] Draft Charter Thread-Index: AQHQfE+l/Sly82ObQkmwTXHnIFPOXJ1ZfxCAgAAiHMA= Date: Wed, 22 Apr 2015 22:47:21 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C090E5@dfweml701-chm> References: <1C8B68F6-75A6-4869-B03A-7DCFD0092437@gmail.com> In-Reply-To: <1C8B68F6-75A6-4869-B03A-7DCFD0092437@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.72] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 22:47:39 -0000 I have a few questions on the DOTS scope: on the this paragraph: > These elements may be communicating inter-domain or intra-domain over=20 > links that may be congested by attack traffic resulting in hostile=20 > conditions for traditional connection oriented approaches and more=20 > generalized signaling and telemetry solutions. Robustness under these=20 > conditions is paramount while ensuring appropriate regard for=20 > authentication, authorization, privacy and data integrity. Is it the goal of the DOTS group to ensure the secure channels and congesti= on status for paths between the On-premise DDoS mitigation platforms and th= e Service provider DDoS mitigation platforms? Is it in the scope for DDOS elements to communicate with Network Management= system to figure out an optimal path between the DDOS elements?=20 Linda -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Adam W. Montville Sent: Wednesday, April 22, 2015 8:35 AM To: Teague, Nik Cc: dots@ietf.org Subject: Re: [Dots] Draft Charter Well-written, Nik. I spotted a couple of minor nits (there may be others),= and have a couple of observations/comments - all inline. > On Apr 21, 2015, at 11:24 AM, Teague, Nik wrote: >=20 > Hi, >=20 > Please see a 1st pass draft charter below - comments and feedback=20 > always welcome. >=20 > -Nik >=20 >=20 > The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards=20 > based approach to the real time signaling of DDoS related telemetry=20 > and threat handling data between elements concerned with attack mitigatio= n. >=20 > The elements may be described as: > * On-premise DDoS mitigation platforms > * Service provider DDoS mitigation platforms > * Other network devices/platforms that are able to sense DDoS and=20 > respond > * Chained instances of the above >=20 The first two points seem pretty tight, but the third bullet seems less so.= As a reader, it feels that you may have wanted to write something like "O= ther DDoS mitigation platforms", but didn't for what is likely an important= reason. Maybe another way to look at it is that the first two bullets see= m to be distinguished based on mitigation platform location, but the third = is a catch-all not necessarily related to location. =20 This isn't a suggestion to change, but an observation you might choose to c= onsider to clarify your meaning. > These elements may be communicating inter-domain or intra-domain over=20 > links that may be congested by attack traffic resulting in hostile=20 > conditions for traditional connection oriented approaches and more=20 > generalized signaling and telemetry solutions. Robustness under these=20 > conditions is paramount while ensuring appropriate regard for=20 > authentication, authorization, privacy and data integrity. Elements=20 > may be deployed as part of a wider strategy incorporating multiple=20 > points of detection and mitigation, both on premise or service provider b= ased. > Should mitigation need to move between elements in the chain then=20 > effective signaling of telemetry and current threat handling is essential= . Consider a comma between "chain" and "then" resulting in: "Should mitigatio= n need to move between elements in the chain, then." > Feedback between participating elements is required for increased=20 > awareness for effective decision making. Could this be ".required for increased awareness supporting effective decis= ion making"? >=20 > The WG will, where appropriate, reuse existing standard protocols and=20 > mechanisms, for instance IPFIX and its templating mechanism. Would it be helpful to also say that you intend (if you do) to coordinate e= fforts with other working groups that may be working on similar problems? = Consider i2nsf, supa, sacm, and mile. Some of these have standards you mig= ht leverage, but others are still working on solutions. In sacm, for examp= le, we are working to define models and protocols based on endpoint posture= assessment, which includes some expression of policy, endpoint attributes,= and so on. Pieces of these things may be useful to dots. >=20 > The charter of the working group is to produce one or more standards=20 > track specification to provide for this open signaling in the DDoS=20 > problem space. Make "specification" plural, so that the sentence reads: ".to produce one o= r more standards track specifications.". > While the resulting standards should be designed so that there=B9s a=20 > possibility of applying them to network security applications beyond=20 > DDoS mitigation, this working group will focus on just DDoS mitigation. The ' in "there's" came up funny (probably a copy/paste issue). > This > streamlined focus of the charter is intended to lead to an earlier=20 > result due to community interests in having such capability in a short ti= meframe. > The specification(s) produced by the WG will include a standard=20 > mechanism for authentication and authorization, for data integrity,=20 > and for providing for privacy in operation. >=20 > The WG will produce the following deliverables: >=20 > * Use case document to ensure commonality of the work among the=20 > participants in the Working Group. This document may be determined by=20 > the working group to remain informal and not be published. > * Document or Documents describing the problem space, use cases,=20 > protocol requirements and other qualifying information as the WG sees fit= . > * Document or Documents specifying a protocol and associated data=20 > models to address the WG stated goal. Something we recently did in sacm is to create a milestone for revisiting m= ilestones. The idea is that we know we're going to have some data models a= nd protocols, but we're not sure how many or how they might be divided amon= g multiple drafts. Something like that could be useful here as well, becau= se it is clear that you will have models and protocols, but it's not clear = how that work will ultimately materialize. It might be too early, but do you have any idea as to dates for these miles= tones? >=20 > _______________________________________________ > 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 Thu Apr 23 08:49:34 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797241B2D05 for ; Thu, 23 Apr 2015 08:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.628 X-Spam-Level: X-Spam-Status: No, score=0.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4U6DKhR93VGH for ; Thu, 23 Apr 2015 08:49:26 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.101]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1541B2E98 for ; Thu, 23 Apr 2015 08:49:18 -0700 (PDT) Received: from [216.82.253.227] by server-5.bemta-7.messagelabs.com id DC/C3-28176-B7419355; Thu, 23 Apr 2015 15:49:15 +0000 X-Env-Sender: Scott.Barvick@corero.com X-Msg-Ref: server-15.tower-170.messagelabs.com!1429804154!32156459!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9112 invoked from network); 23 Apr 2015 15:49:15 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-15.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 23 Apr 2015 15:49:15 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0224.002; Thu, 23 Apr 2015 11:49:14 -0400 From: Scott Barvick To: Linda Dunbar , "Adam W. Montville" , "Teague, Nik" Thread-Topic: [Dots] Draft Charter Thread-Index: AQHQfE+l/Sly82ObQkmwTXHnIFPOXJ1ZTMWAgACaP4CAANpyAA== Date: Thu, 23 Apr 2015 15:49:13 +0000 Message-ID: References: <1C8B68F6-75A6-4869-B03A-7DCFD0092437@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657C090E5@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C090E5@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [192.168.60.117] Content-Type: text/plain; charset="euc-kr" Content-ID: <542BB957B6AAF24C86C84FD1CA65D6D5@corero.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 15:49:32 -0000 TGluZGEsDQoNCklmIEkgdW5kZXJzdGFuZCB5b3VyIHF1ZXN0aW9ucywgSU1PICB0aGUgYW5zd2Vy IHRvIGJvdGggb2YgdGhlbSBpcyBubywgYnV0DQp3ZSBkbyBuZWVkIHRvIGNsYXJpZnkuDQoNCjEp IKGwZW5zdXJlIKGmIGNvbmdlc3Rpb24gc3RhdHVzobEgICAtICBVbmRlciBhIGJpZyBERG9TIGF0 dGFjaywgdGhlIGluYm91bmQNCmxpbmsgdG8gdGhlIEREb1MgZGV2aWNlIG1heSBiZSBzbyBzYXR1 cmF0ZWQgdGhhdCChrnRyYWRpdGlvbmFsIG1ldGhvZHOhpg0Kc29sdXRpb25zobEgd2lsbCBub3Qg d29yayBiZWNhdXNlIHRoZXkgbW9zdCBsaWtlbHkgdXRpbGl6ZSAyIHdheQ0KKGNvbm5lY3Rpb24t b3JpZW50ZWQpIHRyYWZmaWMuICAgSWYgdGhlIGluYm91bmQgbGluayBpcyBzYXR1cmF0ZWQsIHdl DQptaWdodCBvbmx5IGJlIGFibGUgdG8gobByZWxpYWJseaGxIGdldCB0aGUgc2l0dWF0aW9uIHNp Z25hbGVkIHRocm91Z2ggYQ0KY29ubmVjdGlvbmxlc3MgcHJvdG9jb2wgdGhhdCBjb3VudHMgb24g cmVwZXRpdGlvbiBhbmQgc3RhdGlzdGljYWwNCmxpa2VsaWhvb2QgZm9yIHN1Y2Nlc3MuICBTbywg SSBkb26hr3QgdGhpbmsgd2UgY2FuIGVuc3VyZSBjb25nZXN0aW9uIHN0YXR1cw0KKG90aGVyIHRo YW4gZGVzaWduaW5nIGZvciBjb25nZXN0aW9uOikuDQoNCjIpIKGwZW5zdXJlIHNlY3VyZSBjaGFu bmVsc6GxIC4gICBUaGUgY2hhbm5lbCBpcyBub3QgZGVkaWNhdGVkIHNvIHRoZQ0KcHJvdG9jb2wg bmVlZHMgdG8gZG8gdGhlIHJpZ2h0IHRoaW5nLCBhcyB0aGUgY2hhcnRlciBzYXlzIGFib3V0IKGw oaYNCkFwcHJvcHJpYXRlIHJlZ2FyZCBmb3IgoaYgZGF0YSBpbnRlZ3JpdHmhsS4gIElmIG15IGNo YW5uZWwsIHlvdSBtZWFuIHRoZQ0KbG9naWNhbCBjaGFubmVsIGJldHdlZW4gdGhlIGRldmljZXMs IHRoZW4sIHllcywgSSB0aGluayB3ZSBoYXZlIHRvIGFkZHJlc3MNCnRoYXQuDQoNCjMpIEF0IGxl YXN0IGluIHRoZSBmaXJzdCByb3VuZCwgSSBkb26hr3Qgc2VlIHVzIGhhdmluZyB0aGUgRERvUyBl bGVtZW50cw0KdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgb3B0aW1hbCBwYXRocyBiZXR3ZWVuIHRoZSBk ZXZpY2VzLiAgIFRoZSBERG9TIGRldmljZXMNCnNpZ25hbCwgdGhlIHVwc3RyZWFtIHJlY2VpdmVy cyB0YWtlIGFjdGlvbiwgYW5kIHRoZSByb3V0aW5nL3Jlcm91dGluZw0KaGFwcGVucyBhcm91bmQg dGhlIEREb1MgZGV2aWNlcy4NCg0KUmVnYXJkcywNClNjb3R0DQoNCg0KT24gNC8yMi8xNSwgNjo0 NyBQTSwgIkxpbmRhIER1bmJhciIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPiB3cm90ZToNCg0K PkkgaGF2ZSBhIGZldyBxdWVzdGlvbnMgb24gdGhlIERPVFMgc2NvcGU6DQo+DQo+b24gdGhlIHRo aXMgcGFyYWdyYXBoOg0KPg0KPj4gVGhlc2UgZWxlbWVudHMgbWF5IGJlIGNvbW11bmljYXRpbmcg aW50ZXItZG9tYWluIG9yIGludHJhLWRvbWFpbiBvdmVyDQo+PiBsaW5rcyB0aGF0IG1heSBiZSBj b25nZXN0ZWQgYnkgYXR0YWNrIHRyYWZmaWMgcmVzdWx0aW5nIGluIGhvc3RpbGUNCj4+IGNvbmRp dGlvbnMgZm9yIHRyYWRpdGlvbmFsIGNvbm5lY3Rpb24gb3JpZW50ZWQgYXBwcm9hY2hlcyBhbmQg bW9yZQ0KPj4gZ2VuZXJhbGl6ZWQgc2lnbmFsaW5nIGFuZCB0ZWxlbWV0cnkgc29sdXRpb25zLiAg Um9idXN0bmVzcyB1bmRlciB0aGVzZQ0KPj4gY29uZGl0aW9ucyBpcyBwYXJhbW91bnQgd2hpbGUg ZW5zdXJpbmcgYXBwcm9wcmlhdGUgcmVnYXJkIGZvcg0KPj4gYXV0aGVudGljYXRpb24sIGF1dGhv cml6YXRpb24sIHByaXZhY3kgYW5kIGRhdGEgaW50ZWdyaXR5Lg0KPg0KPklzIGl0IHRoZSBnb2Fs IG9mIHRoZSBET1RTIGdyb3VwIHRvIGVuc3VyZSB0aGUgc2VjdXJlIGNoYW5uZWxzIGFuZA0KPmNv bmdlc3Rpb24gc3RhdHVzIGZvciBwYXRocyBiZXR3ZWVuIHRoZSBPbi1wcmVtaXNlIEREb1MgbWl0 aWdhdGlvbg0KPnBsYXRmb3JtcyBhbmQgdGhlICBTZXJ2aWNlIHByb3ZpZGVyIEREb1MgbWl0aWdh dGlvbiBwbGF0Zm9ybXM/DQo+DQo+SXMgaXQgaW4gdGhlIHNjb3BlIGZvciBERE9TIGVsZW1lbnRz IHRvIGNvbW11bmljYXRlIHdpdGggTmV0d29yaw0KPk1hbmFnZW1lbnQgc3lzdGVtIHRvIGZpZ3Vy ZSBvdXQgYW4gb3B0aW1hbCBwYXRoIGJldHdlZW4gdGhlIERET1MNCj5lbGVtZW50cz8gDQo+DQo+ TGluZGENCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IERvdHMgW21haWx0 bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZGFtIFcuIE1vbnR2aWxsZQ0K PlNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjIsIDIwMTUgODozNSBBTQ0KPlRvOiBUZWFndWUsIE5p aw0KPkNjOiBkb3RzQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtEb3RzXSBEcmFmdCBDaGFydGVy DQo+DQo+V2VsbC13cml0dGVuLCBOaWsuICBJIHNwb3R0ZWQgYSBjb3VwbGUgb2YgbWlub3Igbml0 cyAodGhlcmUgbWF5IGJlDQo+b3RoZXJzKSwgYW5kIGhhdmUgYSBjb3VwbGUgb2Ygb2JzZXJ2YXRp b25zL2NvbW1lbnRzIC0gYWxsIGlubGluZS4NCj4NCj4+IE9uIEFwciAyMSwgMjAxNSwgYXQgMTE6 MjQgQU0sIFRlYWd1ZSwgTmlrIDxudGVhZ3VlQHZlcmlzaWduLmNvbT4gd3JvdGU6DQo+PiANCj4+ IEhpLA0KPj4gDQo+PiBQbGVhc2Ugc2VlIGEgMXN0IHBhc3MgZHJhZnQgY2hhcnRlciBiZWxvdyAt IGNvbW1lbnRzIGFuZCBmZWVkYmFjaw0KPj4gYWx3YXlzIHdlbGNvbWUuDQo+PiANCj4+IC1OaWsN Cj4+IA0KPj4gDQo+PiBUaGUgYWltIG9mIEREb1MgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIChET1RT KSBpcyB0byBkZXZlbG9wIGEgc3RhbmRhcmRzDQo+PiBiYXNlZCBhcHByb2FjaCB0byB0aGUgcmVh bCB0aW1lIHNpZ25hbGluZyBvZiBERG9TIHJlbGF0ZWQgdGVsZW1ldHJ5DQo+PiBhbmQgdGhyZWF0 IGhhbmRsaW5nIGRhdGEgYmV0d2VlbiBlbGVtZW50cyBjb25jZXJuZWQgd2l0aCBhdHRhY2sNCj4+ bWl0aWdhdGlvbi4NCj4+IA0KPj4gVGhlIGVsZW1lbnRzIG1heSBiZSBkZXNjcmliZWQgYXM6DQo+ PiAqIE9uLXByZW1pc2UgRERvUyBtaXRpZ2F0aW9uIHBsYXRmb3Jtcw0KPj4gKiBTZXJ2aWNlIHBy b3ZpZGVyIEREb1MgbWl0aWdhdGlvbiBwbGF0Zm9ybXMNCj4+ICogT3RoZXIgbmV0d29yayBkZXZp Y2VzL3BsYXRmb3JtcyB0aGF0IGFyZSBhYmxlIHRvIHNlbnNlIEREb1MgYW5kDQo+PiByZXNwb25k DQo+PiAqIENoYWluZWQgaW5zdGFuY2VzIG9mIHRoZSBhYm92ZQ0KPj4gDQo+DQo+VGhlIGZpcnN0 IHR3byBwb2ludHMgc2VlbSBwcmV0dHkgdGlnaHQsIGJ1dCB0aGUgdGhpcmQgYnVsbGV0IHNlZW1z IGxlc3MNCj5zby4gIEFzIGEgcmVhZGVyLCBpdCBmZWVscyB0aGF0IHlvdSBtYXkgaGF2ZSB3YW50 ZWQgdG8gd3JpdGUgc29tZXRoaW5nDQo+bGlrZSAiT3RoZXIgRERvUyBtaXRpZ2F0aW9uIHBsYXRm b3JtcyIsIGJ1dCBkaWRuJ3QgZm9yIHdoYXQgaXMgbGlrZWx5IGFuDQo+aW1wb3J0YW50IHJlYXNv bi4gIE1heWJlIGFub3RoZXIgd2F5IHRvIGxvb2sgYXQgaXQgaXMgdGhhdCB0aGUgZmlyc3QgdHdv DQo+YnVsbGV0cyBzZWVtIHRvIGJlIGRpc3Rpbmd1aXNoZWQgYmFzZWQgb24gbWl0aWdhdGlvbiBw bGF0Zm9ybSBsb2NhdGlvbiwNCj5idXQgdGhlIHRoaXJkIGlzIGEgY2F0Y2gtYWxsIG5vdCBuZWNl c3NhcmlseSByZWxhdGVkIHRvIGxvY2F0aW9uLg0KPg0KPlRoaXMgaXNuJ3QgYSBzdWdnZXN0aW9u IHRvIGNoYW5nZSwgYnV0IGFuIG9ic2VydmF0aW9uIHlvdSBtaWdodCBjaG9vc2UgdG8NCj5jb25z aWRlciB0byBjbGFyaWZ5IHlvdXIgbWVhbmluZy4NCj4NCj4+IFRoZXNlIGVsZW1lbnRzIG1heSBi ZSBjb21tdW5pY2F0aW5nIGludGVyLWRvbWFpbiBvciBpbnRyYS1kb21haW4gb3Zlcg0KPj4gbGlu a3MgdGhhdCBtYXkgYmUgY29uZ2VzdGVkIGJ5IGF0dGFjayB0cmFmZmljIHJlc3VsdGluZyBpbiBo b3N0aWxlDQo+PiBjb25kaXRpb25zIGZvciB0cmFkaXRpb25hbCBjb25uZWN0aW9uIG9yaWVudGVk IGFwcHJvYWNoZXMgYW5kIG1vcmUNCj4+IGdlbmVyYWxpemVkIHNpZ25hbGluZyBhbmQgdGVsZW1l dHJ5IHNvbHV0aW9ucy4gIFJvYnVzdG5lc3MgdW5kZXIgdGhlc2UNCj4+IGNvbmRpdGlvbnMgaXMg cGFyYW1vdW50IHdoaWxlIGVuc3VyaW5nIGFwcHJvcHJpYXRlIHJlZ2FyZCBmb3INCj4+IGF1dGhl bnRpY2F0aW9uLCBhdXRob3JpemF0aW9uLCBwcml2YWN5IGFuZCBkYXRhIGludGVncml0eS4gIEVs ZW1lbnRzDQo+PiBtYXkgYmUgZGVwbG95ZWQgYXMgcGFydCBvZiBhIHdpZGVyIHN0cmF0ZWd5IGlu Y29ycG9yYXRpbmcgbXVsdGlwbGUNCj4+IHBvaW50cyBvZiBkZXRlY3Rpb24gYW5kIG1pdGlnYXRp b24sIGJvdGggb24gcHJlbWlzZSBvciBzZXJ2aWNlIHByb3ZpZGVyDQo+PmJhc2VkLg0KPj4gU2hv dWxkIG1pdGlnYXRpb24gbmVlZCB0byBtb3ZlIGJldHdlZW4gZWxlbWVudHMgaW4gdGhlIGNoYWlu IHRoZW4NCj4+IGVmZmVjdGl2ZSBzaWduYWxpbmcgb2YgdGVsZW1ldHJ5IGFuZCBjdXJyZW50IHRo cmVhdCBoYW5kbGluZyBpcw0KPj5lc3NlbnRpYWwuDQo+DQo+Q29uc2lkZXIgYSBjb21tYSBiZXR3 ZWVuICJjaGFpbiIgYW5kICJ0aGVuIiByZXN1bHRpbmcgaW46ICJTaG91bGQNCj5taXRpZ2F0aW9u IG5lZWQgdG8gbW92ZSBiZXR3ZWVuIGVsZW1lbnRzIGluIHRoZSBjaGFpbiwgdGhlbi4iDQo+DQo+ PiBGZWVkYmFjayBiZXR3ZWVuIHBhcnRpY2lwYXRpbmcgZWxlbWVudHMgaXMgcmVxdWlyZWQgZm9y IGluY3JlYXNlZA0KPj4gYXdhcmVuZXNzIGZvciBlZmZlY3RpdmUgZGVjaXNpb24gbWFraW5nLg0K Pg0KPkNvdWxkIHRoaXMgYmUgIi5yZXF1aXJlZCBmb3IgaW5jcmVhc2VkIGF3YXJlbmVzcyBzdXBw b3J0aW5nIGVmZmVjdGl2ZQ0KPmRlY2lzaW9uIG1ha2luZyI/DQo+DQo+PiANCj4+IFRoZSBXRyB3 aWxsLCB3aGVyZSBhcHByb3ByaWF0ZSwgcmV1c2UgZXhpc3Rpbmcgc3RhbmRhcmQgcHJvdG9jb2xz IGFuZA0KPj4gbWVjaGFuaXNtcywgZm9yIGluc3RhbmNlIElQRklYIGFuZCBpdHMgdGVtcGxhdGlu ZyBtZWNoYW5pc20uDQo+DQo+V291bGQgaXQgYmUgaGVscGZ1bCB0byBhbHNvIHNheSB0aGF0IHlv dSBpbnRlbmQgKGlmIHlvdSBkbykgdG8gY29vcmRpbmF0ZQ0KPmVmZm9ydHMgd2l0aCBvdGhlciB3 b3JraW5nIGdyb3VwcyB0aGF0IG1heSBiZSB3b3JraW5nIG9uIHNpbWlsYXINCj5wcm9ibGVtcz8g IENvbnNpZGVyIGkybnNmLCBzdXBhLCBzYWNtLCBhbmQgbWlsZS4gIFNvbWUgb2YgdGhlc2UgaGF2 ZQ0KPnN0YW5kYXJkcyB5b3UgbWlnaHQgbGV2ZXJhZ2UsIGJ1dCBvdGhlcnMgYXJlIHN0aWxsIHdv cmtpbmcgb24gc29sdXRpb25zLg0KPkluIHNhY20sIGZvciBleGFtcGxlLCB3ZSBhcmUgd29ya2lu ZyB0byBkZWZpbmUgbW9kZWxzIGFuZCBwcm90b2NvbHMgYmFzZWQNCj5vbiBlbmRwb2ludCBwb3N0 dXJlIGFzc2Vzc21lbnQsIHdoaWNoIGluY2x1ZGVzIHNvbWUgZXhwcmVzc2lvbiBvZiBwb2xpY3ks DQo+ZW5kcG9pbnQgYXR0cmlidXRlcywgYW5kIHNvIG9uLiBQaWVjZXMgb2YgdGhlc2UgdGhpbmdz IG1heSBiZSB1c2VmdWwgdG8NCj5kb3RzLg0KPg0KPg0KPj4gDQo+PiBUaGUgY2hhcnRlciBvZiB0 aGUgd29ya2luZyBncm91cCBpcyB0byBwcm9kdWNlIG9uZSBvciBtb3JlIHN0YW5kYXJkcw0KPj4g dHJhY2sgc3BlY2lmaWNhdGlvbiB0byBwcm92aWRlIGZvciB0aGlzIG9wZW4gc2lnbmFsaW5nIGlu IHRoZSBERG9TDQo+PiBwcm9ibGVtIHNwYWNlLg0KPg0KPk1ha2UgInNwZWNpZmljYXRpb24iIHBs dXJhbCwgc28gdGhhdCB0aGUgc2VudGVuY2UgcmVhZHM6ICIudG8gcHJvZHVjZSBvbmUNCj5vciBt b3JlIHN0YW5kYXJkcyB0cmFjayBzcGVjaWZpY2F0aW9ucy4iLg0KPg0KPj4gV2hpbGUgdGhlIHJl c3VsdGluZyBzdGFuZGFyZHMgc2hvdWxkIGJlIGRlc2lnbmVkIHNvIHRoYXQgdGhlcmWp9nMgYQ0K Pj4gcG9zc2liaWxpdHkgb2YgYXBwbHlpbmcgdGhlbSB0byBuZXR3b3JrIHNlY3VyaXR5IGFwcGxp Y2F0aW9ucyBiZXlvbmQNCj4+IEREb1MgbWl0aWdhdGlvbiwgdGhpcyB3b3JraW5nIGdyb3VwIHdp bGwgZm9jdXMgb24ganVzdCBERG9TIG1pdGlnYXRpb24uDQo+DQo+VGhlICcgaW4gInRoZXJlJ3Mi IGNhbWUgdXAgZnVubnkgKHByb2JhYmx5IGEgY29weS9wYXN0ZSBpc3N1ZSkuDQo+DQo+PiBUaGlz DQo+PiBzdHJlYW1saW5lZCBmb2N1cyBvZiB0aGUgY2hhcnRlciBpcyBpbnRlbmRlZCB0byBsZWFk IHRvIGFuIGVhcmxpZXINCj4+IHJlc3VsdCBkdWUgdG8gY29tbXVuaXR5IGludGVyZXN0cyBpbiBo YXZpbmcgc3VjaCBjYXBhYmlsaXR5IGluIGEgc2hvcnQNCj4+dGltZWZyYW1lLg0KPj4gVGhlIHNw ZWNpZmljYXRpb24ocykgcHJvZHVjZWQgYnkgdGhlIFdHIHdpbGwgaW5jbHVkZSBhIHN0YW5kYXJk DQo+PiBtZWNoYW5pc20gZm9yIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uLCBmb3Ig ZGF0YSBpbnRlZ3JpdHksDQo+PiBhbmQgZm9yIHByb3ZpZGluZyBmb3IgcHJpdmFjeSBpbiBvcGVy YXRpb24uDQo+PiANCj4+IFRoZSBXRyB3aWxsIHByb2R1Y2UgdGhlIGZvbGxvd2luZyBkZWxpdmVy YWJsZXM6DQo+PiANCj4+ICogVXNlIGNhc2UgZG9jdW1lbnQgdG8gZW5zdXJlIGNvbW1vbmFsaXR5 IG9mIHRoZSB3b3JrIGFtb25nIHRoZQ0KPj4gcGFydGljaXBhbnRzIGluIHRoZSBXb3JraW5nIEdy b3VwLiAgVGhpcyBkb2N1bWVudCBtYXkgYmUgZGV0ZXJtaW5lZCBieQ0KPj4gdGhlIHdvcmtpbmcg Z3JvdXAgdG8gcmVtYWluIGluZm9ybWFsIGFuZCBub3QgYmUgcHVibGlzaGVkLg0KPj4gKiBEb2N1 bWVudCBvciBEb2N1bWVudHMgZGVzY3JpYmluZyB0aGUgcHJvYmxlbSBzcGFjZSwgdXNlIGNhc2Vz LA0KPj4gcHJvdG9jb2wgcmVxdWlyZW1lbnRzIGFuZCBvdGhlciBxdWFsaWZ5aW5nIGluZm9ybWF0 aW9uIGFzIHRoZSBXRyBzZWVzDQo+PmZpdC4NCj4+ICogRG9jdW1lbnQgb3IgRG9jdW1lbnRzIHNw ZWNpZnlpbmcgYSBwcm90b2NvbCBhbmQgYXNzb2NpYXRlZCBkYXRhDQo+PiBtb2RlbHMgdG8gYWRk cmVzcyB0aGUgV0cgc3RhdGVkIGdvYWwuDQo+DQo+U29tZXRoaW5nIHdlIHJlY2VudGx5IGRpZCBp biBzYWNtIGlzIHRvIGNyZWF0ZSBhIG1pbGVzdG9uZSBmb3IgcmV2aXNpdGluZw0KPm1pbGVzdG9u ZXMuICBUaGUgaWRlYSBpcyB0aGF0IHdlIGtub3cgd2UncmUgZ29pbmcgdG8gaGF2ZSBzb21lIGRh dGENCj5tb2RlbHMgYW5kIHByb3RvY29scywgYnV0IHdlJ3JlIG5vdCBzdXJlIGhvdyBtYW55IG9y IGhvdyB0aGV5IG1pZ2h0IGJlDQo+ZGl2aWRlZCBhbW9uZyBtdWx0aXBsZSBkcmFmdHMuICBTb21l dGhpbmcgbGlrZSB0aGF0IGNvdWxkIGJlIHVzZWZ1bCBoZXJlDQo+YXMgd2VsbCwgYmVjYXVzZSBp dCBpcyBjbGVhciB0aGF0IHlvdSB3aWxsIGhhdmUgbW9kZWxzIGFuZCBwcm90b2NvbHMsIGJ1dA0K Pml0J3Mgbm90IGNsZWFyIGhvdyB0aGF0IHdvcmsgd2lsbCB1bHRpbWF0ZWx5IG1hdGVyaWFsaXpl Lg0KPg0KPkl0IG1pZ2h0IGJlIHRvbyBlYXJseSwgYnV0IGRvIHlvdSBoYXZlIGFueSBpZGVhIGFz IHRvIGRhdGVzIGZvciB0aGVzZQ0KPm1pbGVzdG9uZXM/DQo+DQo+PiANCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBEb3RzIG1haWxpbmcgbGlz dA0KPj4gRG90c0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kb3RzDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj5Eb3RzIG1haWxpbmcgbGlzdA0KPkRvdHNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCj4NCj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPkRvdHMgbWFpbGluZyBsaXN0DQo+RG90c0BpZXRm Lm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KDQo= From nobody Thu Apr 23 10:00:39 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1E81ACD9A for ; Thu, 23 Apr 2015 10:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YoZyeG_q5HZ for ; Thu, 23 Apr 2015 10:00:35 -0700 (PDT) Received: from mail-oi0-f98.google.com (mail-oi0-f98.google.com [209.85.218.98]) (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 7C5EF1ACD0E for ; Thu, 23 Apr 2015 10:00:34 -0700 (PDT) Received: by oiax69 with SMTP id x69so805880oia.0 for ; Thu, 23 Apr 2015 10:00:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:content-id :content-transfer-encoding:mime-version; bh=qaE6NdrvkQWFAD8jAOxtZm9fHLLk4eABPwmZUCEiSkw=; b=Mr7402it+aqQbt9qrwjqV/BPBwMRub2GADItDOZ87hUJn22Zf4NUnmrIcIfgoPCtKU nn+R0HVo1crWsSADlHg4YTnVDpxyZnAXvx8jEEMqvotOE5mQKxv/zt6EnYHEJVRMif1Z MCJi2QwT5EzFgxQ888iB0niKWyG3W/SqEsMIsUjxqF2hTH5peXFlxMeJewzMT21sMgPh 0cUfp+EzJxyjvqC17Ylhzn6/E4OdGXlOhc2BGVPlV0ByewLjLdKg/hxzrouXn5Yj2oJQ F8UlladzQ3b/VDYsawHhYdiKLGqu3porXuuzj1HK6jfcHPy5b6ijMu4RX2yXHtfaTZep bOxA== X-Gm-Message-State: ALoCoQnp9UUTGbdfCw70YXOfgM1Dgzf1oZYD+DH8ZvQrNHm51rMRpWrPvXjxtLvcvB7mIKHreHJHi2jya1+u9y7rz5y9yqwgmg== X-Received: by 10.55.22.88 with SMTP id g85mr7102214qkh.48.1429808433570; Thu, 23 Apr 2015 10:00:33 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id hl17sm2297817qcb.4.2015.04.23.10.00.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 23 Apr 2015 10:00:33 -0700 (PDT) X-Relaying-Domain: verisign.com 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 t3NH0Wmo011787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 13:00:32 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 23 Apr 2015 13:00:32 -0400 From: "Teague, Nik" To: "Adam W. Montville" Thread-Topic: [Dots] Draft Charter Thread-Index: AQHQfE+l/Sly82ObQkmwTXHnIFPOXJ1ZTMWAgAHcboA= Date: Thu, 23 Apr 2015 17:00:32 +0000 Message-ID: References: <1C8B68F6-75A6-4869-B03A-7DCFD0092437@gmail.com> In-Reply-To: <1C8B68F6-75A6-4869-B03A-7DCFD0092437@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4D2B0DAEBBC56344A2FE0B5B53936CF2@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:00:37 -0000 Adam hi, Thanks! - comments inline to the inline re scope, collaboration, milestones. On 22/04/2015 14:35, "Adam W. Montville" wrote: >... >>=20 >>=20 >> The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards >> based approach to the real time signaling of DDoS related telemetry and >> threat handling data between elements concerned with attack mitigation. >>=20 >> The elements may be described as: >> * On-premise DDoS mitigation platforms >> * Service provider DDoS mitigation platforms >> * Other network devices/platforms that are able to sense DDoS and >>respond >> * Chained instances of the above >>=20 > >The first two points seem pretty tight, but the third bullet seems less >so. As a reader, it feels that you may have wanted to write something >like =B3Other DDoS mitigation platforms=B2, but didn=B9t for what is likel= y an >important reason. Maybe another way to look at it is that the first two >bullets seem to be distinguished based on mitigation platform location, >but the third is a catch-all not necessarily related to location. > >This isn=B9t a suggestion to change, but an observation you might choose t= o >consider to clarify your meaning. This is a little vague, yes. What I was trying to express was a way to define other devices (routers, firewalls, ids, monitoring platforms etc.) that may be able to make a basic assessment on traffic profile that a DDoS is occurring and signal such. These components may not have a specific DDoS focus but may be able to still participate in the detection/mitigation. My concern was expressing such so as not to mire the scope by making it too wide ranging while still attempting to address the need. Or maybe we should just omit stating such explicitly above and have it covered by the more implicit statement: "While the resulting standards should be designed so that there=B9s a possibility of applying them to network security applications beyond DDoS mitigation, this working group will focus on just DDoS mitigation.=B2 >... >>=20 >> The WG will, where appropriate, reuse existing standard protocols and >> mechanisms, for instance IPFIX and its templating mechanism. > >Would it be helpful to also say that you intend (if you do) to coordinate >efforts with other working groups that may be working on similar >problems? Consider i2nsf, supa, sacm, and mile. Some of these have >standards you might leverage, but others are still working on solutions. >In sacm, for example, we are working to define models and protocols based >on endpoint posture assessment, which includes some expression of policy, >endpoint attributes, and so on. Pieces of these things may be useful to >dots. Yes this should be a consideration and we should endeavour to understand where we can collaborate and leverage some of the parallel efforts. > >... > >Something we recently did in sacm is to create a milestone for revisiting >milestones. The idea is that we know we=B9re going to have some data >models and protocols, but we=B9re not sure how many or how they might be >divided among multiple drafts. Something like that could be useful here >as well, because it is clear that you will have models and protocols, but >it=B9s not clear how that work will ultimately materialize. > >It might be too early, but do you have any idea as to dates for these >milestones? I agree on the milestone re-evaluation - I don=B9t have dates yet on milestones - I still think we need a little more work there before we can agree on those. Thanks again, -Nik From nobody Thu Apr 23 10:16:15 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002261ACDBC; Thu, 23 Apr 2015 10:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xy2gqxZa2nZv; Thu, 23 Apr 2015 10:13:03 -0700 (PDT) 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 5311B1ACDA7; Thu, 23 Apr 2015 10:13:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRT49007; Thu, 23 Apr 2015 17:12:59 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Apr 2015 18:12:58 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Thu, 23 Apr 2015 10:12:53 -0700 From: Linda Dunbar To: "i2nsf@ietf.org" , "i2rs@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" , "pcp@ietf.org" , "sfc@ietf.org" , "dots@ietf.org" , "opsawg@ietf.org" , "ops-dir@ietf.org" , "ops-ads@tools.ietf.org" Thread-Topic: I2NSF: Interface to network security functions : problem-statement, framework, use cases, and potential solution Thread-Index: AQHQfeL7u793L89A7kyGIFebPlU0DZ1aykFw Date: Thu, 23 Apr 2015 17:12:53 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C09765@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Thu, 23 Apr 2015 10:16:05 -0700 Cc: "mile@ietf.org" Subject: [Dots] I2NSF: Interface to network security functions : problem-statement, framework, use cases, and potential solution X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:13:05 -0000 VGhlICJpMm5zZi1wcm9ibGVtLXN0YXRlbWVudCIgZHJhZnQgZGVzY3JpYmVzIHRoZSBtb3RpdmF0 aW9uIGFuZCB0aGUgcHJvYmxlbSBzcGFjZSBhc3NvY2lhdGVkIHdpdGggc2VydmljZSBwcm92aWRl cnMgcHJvdmlkaW5nIGhvc3RlZCBzZWN1cml0eSBzb2x1dGlvbnMgdG8gZGVsaXZlciBjb3N0LWVm ZmVjdGl2ZSBtYW5hZ2VkIHNlY3VyaXR5IHNlcnZpY2VzIHRvIGVudGVycHJpc2UgY3VzdG9tZXJz IHdobyBkb24ndCBvd24gb3IgaGF2ZSB0aGUgc2VjdXJpdHkgZnVuY3Rpb25zIG9uIHRoZWlyIHBy ZW1pc2VzLiANCg0KU2luY2UgdGhlIGkybnNmLXByb2JsZW0tc3RhdGVtZW50LTAxIGRyYWZ0LCB0 aHJlZSBJMk5TRiB1c2UgY2FzZSBkcmFmdHMsIGEgZ2FwIGFuYWx5c2lzIGRyYWZ0LCBhbmQgYSBw YWNrZXQtYmFzZWQgcGFyYWRpZ20gZHJhZnQgaGF2ZSBiZWVuIHB1Ymxpc2hlZC4gDQpXZSByZW1v dmVkIHRoZSByZWR1bmRhbnQgY29udGVudCBmcm9tIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBkcmFm dCwgbWFraW5nIGl0IGZvY3VzIGV4Y2x1c2l2ZWx5IG9uIHRoZSBwcm9ibGVtIHNwYWNlIG9mIHNl Y3VyaXR5IGZ1bmN0aW9ucyBub3QgaG9zdGVkIG9uIGN1c3RvbWVyJ3MgcHJlbWlzZXMgYW5kIGJl aW5nIGRpc3RyaWJ1dGVkIChkcml2ZW4gYnkgTkZWIGFuZCBob3N0ZWQgc2VjdXJpdHkgc2Vydmlj ZXMpLg0KDQpJbiBjb25qdW5jdGlvbiB3aXRoIHRoZSAiaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnRz IiwgdGhlcmUgYXJlIGFsc28gSTJOU0YgZnJhbWV3b3JrIGRyYWZ0LCBwb3RlbnRpYWwgSTJOU0Yg c29sdXRpb24gZHJhZnQsIHVzZSBjYXNlIGRyYWZ0cyAodW5kZXIgcHJvY2VzcyBvZiBtZXJnaW5n KSwgZ2FwLWFuYWx5c2lzIGFuZCBkYXRhIG1vZGVsaW5nIGRyYWZ0Og0KDQpodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcmsvDQoNCmh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbG9wZXotaTJuc2YtcGFja2V0Lw0KDQpo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXhpYS1pMm5zZi1jYXBhYmlsaXR5 LWludGVyZmFjZS1pbS8gKG5ldyByZXZpc2lvbiBpcyB0byBiZSB1cGxvYWRlZCBzb29uIHRvIHJl ZmxlY3QgdGhlIGRpc2N1c3Npb24gb2YgRjJGIG1lZXRpbmdzIGF0IElFVEY5MiBEYWxsYXMpLiAN Cg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wYXN0b3ItaTJuc2YtYWNj ZXNzLXVzZWNhc2VzLw0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1xaS1p Mm5zZi1hY2Nlc3MtbmV0d29yay11c2VjYXNlLw0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC16YXJueS1pMm5zZi1kYXRhLWNlbnRlci11c2UtY2FzZXMvDQoNCmh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctZ2FwLWFuYWx5c2lzLw0KDQpJMk5T RiBpcyBhYm91dCBzZWN1cml0eSBmdW5jdGlvbnMgbWFuYWdlbWVudC4gVGhlIHVsdGltYXRlIGdv YWwgb2YgSTJOU0YgaXMgdG8gZW5hYmxlIGVudGVycHJpc2VzIHRvIHV0aWxpemUgc2VjdXJpdHkg ZnVuY3Rpb25zIG5vdCBob3N0ZWQgb24gdGhlaXIgb3duIHByZW1pc2UgYnV0IGluc3RlYWQgaG9z dGVkIGluIHNlcnZpY2UgcHJvdmlkZXIgZG9tYWluLCB0byBlc3RhYmxpc2ggaG93IHRvIGNvbW11 bmljYXRlIGRlc2lyZWQgc2VjdXJpdHkgcG9saWNpZXMgdG8gTlNGIGFuZCBob3cgdG8gZ2V0IHBl cmZvcm1hbmNlIGRhdGEgb3IgcmVwb3J0IG91dCBvZiBOU0YuICANCg0KQWxzbyBjb3B5IHRvIHRo ZSBJMk5TRiByZWxldmFudCBJRVRGIFdHczogSTJSUywgTkVUTU9ELCBORVRDT05GLCBTQUNNLCBN SUxFLCBQQ1AsIERPVFMsIFNGQywgYW5kIE9wQXJlYXMsIGluIGhvcGUgdG8gZ2V0IGZlZWRiYWNr IGFuZCBzdWdnZXN0aW9ucyBmcm9tIHdpZGVyIGF1ZGllbmNlLiANCg0KVGhhbmtzIGluIGFkdmFu Y2UsIA0KDQpMaW5kYSBEdW5iYXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Z10gDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMjMsIDIwMTUgMTE6MzEgQU0NClRvOiBNb2hhbWVk IEJvdWNhZGFpcjsgU2hhaWJhbCBDaGFrcmFiYXJ0eTsgTGluZGEgRHVuYmFyOyBDaHJpc3RpYW4g SmFjcXVlbmV0OyBNeW8gWmFybnk7IENocmlzdGlhbiBKYWNxdWVuZXQ7IE15byBaYXJueTsgU2hh aWJhbCBDaGFrcmFiYXJ0eTsgTGluZGEgRHVuYmFyOyBNb2hhbWVkIEJvdWNhZGFpcg0KU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kdW5iYXItaTJuc2YtcHJvYmxl bS1zdGF0ZW1lbnQtMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWR1bmJh ci1pMm5zZi1wcm9ibGVtLXN0YXRlbWVudC0wMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgTGluZGEgRHVuYmFyIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9y eS4NCg0KTmFtZToJCWRyYWZ0LWR1bmJhci1pMm5zZi1wcm9ibGVtLXN0YXRlbWVudA0KUmV2aXNp b246CTAzDQpUaXRsZToJCUludGVyZmFjZSB0byBOZXR3b3JrIFNlY3VyaXR5IEZ1bmN0aW9ucyAo STJOU0YpIFByb2JsZW0gU3RhdGVtZW50DQpEb2N1bWVudCBkYXRlOgkyMDE1LTA0LTIzDQpHcm91 cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkyMQ0KVVJMOiAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWR1bmJhci1pMm5zZi1wcm9i bGVtLXN0YXRlbWVudC0wMy50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1kdW5iYXItaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnQvDQpIdG1s aXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHVuYmFyLWkybnNm LXByb2JsZW0tc3RhdGVtZW50LTAzDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtZHVuYmFyLWkybnNmLXByb2JsZW0tc3RhdGVtZW50LTAzDQoN CkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIG1vdGl2YXRpb24gYW5k IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBmb3INCiAgIEludGVyZmFjZSB0byBOZXR3b3JrIFNlY3Vy aXR5IEZ1bmN0aW9ucyAoSTJOU0YpLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQo= From nobody Thu Apr 23 18:55:11 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975121B34F8 for ; Thu, 23 Apr 2015 18:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmB59gsQNFyo for ; Thu, 23 Apr 2015 18:55:06 -0700 (PDT) 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 4023E1B34ED for ; Thu, 23 Apr 2015 18:54:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRT72632; Fri, 24 Apr 2015 01:54:27 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Apr 2015 02:54:27 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.144]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Fri, 24 Apr 2015 09:54:23 +0800 From: "Xialiang (Frank)" To: "Teague, Nik" , "Adam W. Montville" Thread-Topic: [Dots] Draft Charter Thread-Index: AQHQfE+l/Sly82ObQkmwTXHnIFPOXJ1Yg5uAgAHLrQCAARRsEA== Date: Fri, 24 Apr 2015 01:54:22 +0000 Message-ID: References: <1C8B68F6-75A6-4869-B03A-7DCFD0092437@gmail.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 01:55:08 -0000 SGkgTmlrLA0KRmlyc3RseSwgdGhhbmtzIGZvciB5b3VyIGV4Y2VsbGVudCB3b3JrIG9uIHRoZSBj aGFydGVyLiBJIHRoaW5rIGl0J3MgZ29vZCBhbmQgY2FwdHVyZSBtb3N0IG9mIG91ciB0aG91Z2h0 cyBhYm91dCBET1RTIHdvcmsuDQpJIGFsc28gaGF2ZSBzb21lIGNvbW1lbnRzIGFzIGZvbGxvd2Vk Og0KMS4gUGxlYXNlIGRvIG5vdCBsaW1pdCB0aGUgcG9zc2libGUgZWxlbWVudHMgKG5ldHdvcmsg ZGV2aWNlcyBzdWNoIGFzIHJvdXRlciwgc3dpdGNoKSBpbnZvbHZlZCBpbiB0aGUgQW50aS1ERG9T IHdvcmsgb2YgRE9UUyBhcmNoaXRlY3R1cmUgbm93LCBiZWNhdXNlIHRoZXkgcmVwcmVzZW50IGRp ZmZlcmVudCB1c2UgY2FzZSB3aXRoIHJlc3BlY3RpdmUgcHJvIGFuZCBjb24uIFdlIHdpbGwgaGF2 ZSBtb3JlIG1hdGVyaWFscyB0byBlbGFib3JhdGUgbW9yZSB1c2UgY2FzZXMgdW5kZXIgdGhlIHNh bWUgRE9UUyBzY29wZS4gV2UgdGhpbmsgdGhleSBjYW4gaW5jcmVhc2UgRE9UUyB2YWx1ZSB3aXRo b3V0IG5ldyBpbmZsdWVuY2UgdG8gaXQuDQoyLiBzaG91bGQgd2UgY29uc2lkZXIgdGhlIGluaXRp YWwgbmVnb3RpYXRpb24gbWVjaGFuaXNtIGFuZCB0aGUgb3Blbm5lc3MgbWVjaGFuaXNtIGZvciBE T1RTIHRvIGFkYXB0IHRvIG5ldyBraW5kIG9mIEREb1MgYXR0YWNrcz8gTXkgc3VnZ2VzdGVkIG1v ZGlmaWNhdGlvbiBpczogIkZlZWRiYWNrIGFuZCBpbml0aWFsIGNhcGFiaWxpdHkgbmVnb3RpYXRp b24gbWVjaGFuaXNtcyBiZXR3ZWVuIHBhcnRpY2lwYXRpbmcgZWxlbWVudHMgaXMgcmVxdWlyZWQg Zm9yIGluY3JlYXNlZCBhd2FyZW5lc3MgZm9yIGVmZmVjdGl2ZSBkZWNpc2lvbiBtYWtpbmcuIg0K DQpCLlIuDQpGcmFuaw0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IERvdHMg W21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBUZWFndWUsIE5paw0K5Y+R6YCB 5pe26Ze0OiAyMDE15bm0NOaciDI05pelIDE6MDENCuaUtuS7tuS6ujogQWRhbSBXLiBNb250dmls bGUNCuaKhOmAgTogZG90c0BpZXRmLm9yZw0K5Li76aKYOiBSZTogW0RvdHNdIERyYWZ0IENoYXJ0 ZXINCg0KQWRhbSBoaSwNCg0KVGhhbmtzISAtIGNvbW1lbnRzIGlubGluZSB0byB0aGUgaW5saW5l IHJlIHNjb3BlLCBjb2xsYWJvcmF0aW9uLCBtaWxlc3RvbmVzLg0KDQpPbiAyMi8wNC8yMDE1IDE0 OjM1LCAiQWRhbSBXLiBNb250dmlsbGUiIDxhZGFtLncubW9udHZpbGxlQGdtYWlsLmNvbT4NCndy b3RlOg0KDQo+Li4uDQo+PiANCj4+IA0KPj4gVGhlIGFpbSBvZiBERG9TIE9wZW4gVGhyZWF0IFNp Z25hbGluZyAoRE9UUykgaXMgdG8gZGV2ZWxvcCBhIA0KPj4gc3RhbmRhcmRzIGJhc2VkIGFwcHJv YWNoIHRvIHRoZSByZWFsIHRpbWUgc2lnbmFsaW5nIG9mIEREb1MgcmVsYXRlZCANCj4+IHRlbGVt ZXRyeSBhbmQgdGhyZWF0IGhhbmRsaW5nIGRhdGEgYmV0d2VlbiBlbGVtZW50cyBjb25jZXJuZWQg d2l0aCBhdHRhY2sgbWl0aWdhdGlvbi4NCj4+IA0KPj4gVGhlIGVsZW1lbnRzIG1heSBiZSBkZXNj cmliZWQgYXM6DQo+PiAqIE9uLXByZW1pc2UgRERvUyBtaXRpZ2F0aW9uIHBsYXRmb3Jtcw0KPj4g KiBTZXJ2aWNlIHByb3ZpZGVyIEREb1MgbWl0aWdhdGlvbiBwbGF0Zm9ybXMNCj4+ICogT3RoZXIg bmV0d29yayBkZXZpY2VzL3BsYXRmb3JtcyB0aGF0IGFyZSBhYmxlIHRvIHNlbnNlIEREb1MgYW5k IA0KPj5yZXNwb25kDQo+PiAqIENoYWluZWQgaW5zdGFuY2VzIG9mIHRoZSBhYm92ZQ0KPj4gDQo+ DQo+VGhlIGZpcnN0IHR3byBwb2ludHMgc2VlbSBwcmV0dHkgdGlnaHQsIGJ1dCB0aGUgdGhpcmQg YnVsbGV0IHNlZW1zIGxlc3MgDQo+c28uICBBcyBhIHJlYWRlciwgaXQgZmVlbHMgdGhhdCB5b3Ug bWF5IGhhdmUgd2FudGVkIHRvIHdyaXRlIHNvbWV0aGluZyANCj5saWtlIMKzT3RoZXIgRERvUyBt aXRpZ2F0aW9uIHBsYXRmb3Jtc8KyLCBidXQgZGlkbsK5dCBmb3Igd2hhdCBpcyBsaWtlbHkgDQo+ YW4gaW1wb3J0YW50IHJlYXNvbi4gIE1heWJlIGFub3RoZXIgd2F5IHRvIGxvb2sgYXQgaXQgaXMg dGhhdCB0aGUgZmlyc3QgDQo+dHdvIGJ1bGxldHMgc2VlbSB0byBiZSBkaXN0aW5ndWlzaGVkIGJh c2VkIG9uIG1pdGlnYXRpb24gcGxhdGZvcm0gDQo+bG9jYXRpb24sIGJ1dCB0aGUgdGhpcmQgaXMg YSBjYXRjaC1hbGwgbm90IG5lY2Vzc2FyaWx5IHJlbGF0ZWQgdG8gbG9jYXRpb24uDQo+DQo+VGhp cyBpc27CuXQgYSBzdWdnZXN0aW9uIHRvIGNoYW5nZSwgYnV0IGFuIG9ic2VydmF0aW9uIHlvdSBt aWdodCBjaG9vc2UgDQo+dG8gY29uc2lkZXIgdG8gY2xhcmlmeSB5b3VyIG1lYW5pbmcuDQoNClRo aXMgaXMgYSBsaXR0bGUgdmFndWUsIHllcy4gIFdoYXQgSSB3YXMgdHJ5aW5nIHRvIGV4cHJlc3Mg d2FzIGEgd2F5IHRvIGRlZmluZSBvdGhlciBkZXZpY2VzIChyb3V0ZXJzLCBmaXJld2FsbHMsIGlk cywgbW9uaXRvcmluZyBwbGF0Zm9ybXMgZXRjLikgdGhhdCBtYXkgYmUgYWJsZSB0byBtYWtlIGEg YmFzaWMgYXNzZXNzbWVudCBvbiB0cmFmZmljIHByb2ZpbGUgdGhhdCBhIEREb1MgaXMgb2NjdXJy aW5nIGFuZCBzaWduYWwgc3VjaC4gIFRoZXNlIGNvbXBvbmVudHMgbWF5IG5vdCBoYXZlIGEgc3Bl Y2lmaWMgRERvUyBmb2N1cyBidXQgbWF5IGJlIGFibGUgdG8gc3RpbGwgcGFydGljaXBhdGUgaW4g dGhlIGRldGVjdGlvbi9taXRpZ2F0aW9uLiAgTXkgY29uY2VybiB3YXMgZXhwcmVzc2luZyBzdWNo IHNvIGFzIG5vdCB0byBtaXJlIHRoZSBzY29wZSBieSBtYWtpbmcgaXQgdG9vIHdpZGUgcmFuZ2lu ZyB3aGlsZSBzdGlsbCBhdHRlbXB0aW5nIHRvIGFkZHJlc3MgdGhlIG5lZWQuICBPciBtYXliZSB3 ZSBzaG91bGQganVzdCBvbWl0IHN0YXRpbmcgc3VjaCBleHBsaWNpdGx5ICBhYm92ZSBhbmQgaGF2 ZSBpdCBjb3ZlcmVkIGJ5IHRoZSBtb3JlIGltcGxpY2l0IHN0YXRlbWVudDoNCg0KIldoaWxlIHRo ZSByZXN1bHRpbmcgc3RhbmRhcmRzIHNob3VsZCBiZSBkZXNpZ25lZCBzbyB0aGF0IHRoZXJlwrlz IGEgcG9zc2liaWxpdHkgb2YgYXBwbHlpbmcgdGhlbSB0byBuZXR3b3JrIHNlY3VyaXR5IGFwcGxp Y2F0aW9ucyBiZXlvbmQgRERvUyBtaXRpZ2F0aW9uLCB0aGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBm b2N1cyBvbiBqdXN0IEREb1MgbWl0aWdhdGlvbi7Csg0KDQoNCj4uLi4NCj4+IA0KPj4gVGhlIFdH IHdpbGwsIHdoZXJlIGFwcHJvcHJpYXRlLCByZXVzZSBleGlzdGluZyBzdGFuZGFyZCBwcm90b2Nv bHMgYW5kIA0KPj4gbWVjaGFuaXNtcywgZm9yIGluc3RhbmNlIElQRklYIGFuZCBpdHMgdGVtcGxh dGluZyBtZWNoYW5pc20uDQo+DQo+V291bGQgaXQgYmUgaGVscGZ1bCB0byBhbHNvIHNheSB0aGF0 IHlvdSBpbnRlbmQgKGlmIHlvdSBkbykgdG8gDQo+Y29vcmRpbmF0ZSBlZmZvcnRzIHdpdGggb3Ro ZXIgd29ya2luZyBncm91cHMgdGhhdCBtYXkgYmUgd29ya2luZyBvbiANCj5zaW1pbGFyIHByb2Js ZW1zPyAgQ29uc2lkZXIgaTJuc2YsIHN1cGEsIHNhY20sIGFuZCBtaWxlLiAgU29tZSBvZiB0aGVz ZSANCj5oYXZlIHN0YW5kYXJkcyB5b3UgbWlnaHQgbGV2ZXJhZ2UsIGJ1dCBvdGhlcnMgYXJlIHN0 aWxsIHdvcmtpbmcgb24gc29sdXRpb25zLg0KPkluIHNhY20sIGZvciBleGFtcGxlLCB3ZSBhcmUg d29ya2luZyB0byBkZWZpbmUgbW9kZWxzIGFuZCBwcm90b2NvbHMgDQo+YmFzZWQgb24gZW5kcG9p bnQgcG9zdHVyZSBhc3Nlc3NtZW50LCB3aGljaCBpbmNsdWRlcyBzb21lIGV4cHJlc3Npb24gb2Yg DQo+cG9saWN5LCBlbmRwb2ludCBhdHRyaWJ1dGVzLCBhbmQgc28gb24uIFBpZWNlcyBvZiB0aGVz ZSB0aGluZ3MgbWF5IGJlIA0KPnVzZWZ1bCB0byBkb3RzLg0KDQpZZXMgdGhpcyBzaG91bGQgYmUg YSBjb25zaWRlcmF0aW9uIGFuZCB3ZSBzaG91bGQgZW5kZWF2b3VyIHRvIHVuZGVyc3RhbmQgd2hl cmUgd2UgY2FuIGNvbGxhYm9yYXRlIGFuZCBsZXZlcmFnZSBzb21lIG9mIHRoZSBwYXJhbGxlbCBl ZmZvcnRzLg0KDQo+DQo+Li4uDQo+DQo+U29tZXRoaW5nIHdlIHJlY2VudGx5IGRpZCBpbiBzYWNt IGlzIHRvIGNyZWF0ZSBhIG1pbGVzdG9uZSBmb3IgDQo+cmV2aXNpdGluZyBtaWxlc3RvbmVzLiAg VGhlIGlkZWEgaXMgdGhhdCB3ZSBrbm93IHdlwrlyZSBnb2luZyB0byBoYXZlIA0KPnNvbWUgZGF0 YSBtb2RlbHMgYW5kIHByb3RvY29scywgYnV0IHdlwrlyZSBub3Qgc3VyZSBob3cgbWFueSBvciBo b3cgdGhleSANCj5taWdodCBiZSBkaXZpZGVkIGFtb25nIG11bHRpcGxlIGRyYWZ0cy4gIFNvbWV0 aGluZyBsaWtlIHRoYXQgY291bGQgYmUgDQo+dXNlZnVsIGhlcmUgYXMgd2VsbCwgYmVjYXVzZSBp dCBpcyBjbGVhciB0aGF0IHlvdSB3aWxsIGhhdmUgbW9kZWxzIGFuZCANCj5wcm90b2NvbHMsIGJ1 dCBpdMK5cyBub3QgY2xlYXIgaG93IHRoYXQgd29yayB3aWxsIHVsdGltYXRlbHkgbWF0ZXJpYWxp emUuDQo+DQo+SXQgbWlnaHQgYmUgdG9vIGVhcmx5LCBidXQgZG8geW91IGhhdmUgYW55IGlkZWEg YXMgdG8gZGF0ZXMgZm9yIHRoZXNlIA0KPm1pbGVzdG9uZXM/DQoNCkkgYWdyZWUgb24gdGhlIG1p bGVzdG9uZSByZS1ldmFsdWF0aW9uIC0gSSBkb27CuXQgaGF2ZSBkYXRlcyB5ZXQgb24gbWlsZXN0 b25lcyAtIEkgc3RpbGwgdGhpbmsgd2UgbmVlZCBhIGxpdHRsZSBtb3JlIHdvcmsgdGhlcmUgYmVm b3JlIHdlIGNhbiBhZ3JlZSBvbiB0aG9zZS4NCg0KVGhhbmtzIGFnYWluLA0KDQotTmlrDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEb3RzIG1haWxp bmcgbGlzdA0KRG90c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kb3RzDQo=