From nobody Thu Sep 7 10:36:07 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D98F132F3E for ; Thu, 7 Sep 2017 10:36:06 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWstvjCErOYQ for ; Thu, 7 Sep 2017 10:36:04 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89859132F32 for ; Thu, 7 Sep 2017 10:36:04 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v87Ha3eV045215 for ; Thu, 7 Sep 2017 13:36:03 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu v87Ha3eV045215 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1504805763; bh=A7SLzZdD4HPh0XsnR2BsyM4CkWBWAD4ouuDbZUuRdUI=; h=From:To:Subject:Date:From; b=VXCFVk+8cbe4MDqU1MQBVvR4lPEbjM6gVYXzhSqIC+XG22x23y08ApansQIvtQKRb 8Z8sr0q3ImnIAeN+uKsHrX5vrLOw/aeJz6BR9uhufzk4nPq6+gApqBbjqp49kOuE5/ F/6dL6xL36ZlVIKdqX9fwtYjBz8+LJ8t0RVKAlZk= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v87HZtQ2025591 for ; Thu, 7 Sep 2017 13:35:55 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0351.000; Thu, 7 Sep 2017 13:35:55 -0400 From: Roman Danyliw To: "'dots@ietf.org'" Thread-Topic: October 2017 Virtual Interim Meeting Scheduling Poll Thread-Index: AdMn/8BkFAuv4G+3QE+okwLNDUk/oQ== Date: Thu, 7 Sep 2017 17:35:55 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104FC45AF@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] October 2017 Virtual Interim Meeting Scheduling Poll X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 07 Sep 2017 17:36:06 -0000 Hello WG! We're approaching the half-way point between the Prague and upcoming Singap= ore meeting and would benefit from synchronizing with a virtual interim mee= ting. The proposed agenda would be a subset of the following: ** Hackathon participation ** Use Cases, Requirements and Architecture drafts ** Signal and Data channel drafts Help suggest the best day to virtual meet during the week of October 2nd by= completing a Doodle poll -- https://doodle.com/poll/65anbcr64ny95cm3. Your input would be appreciated by Thursday, September 14, 2017 and results= will be announced on Friday, September 15, 2017. Regards, Roman From nobody Thu Sep 7 21:05:47 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1FE127517 for ; Thu, 7 Sep 2017 21:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeAXxheRjYTB for ; Thu, 7 Sep 2017 21:05:44 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 D596E124319 for ; Thu, 7 Sep 2017 21:05:43 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id c80so3063093lfh.0 for ; Thu, 07 Sep 2017 21:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VwUcg/v3cVNEv697eUUw0YGUsm+Jh+8ZRYx0c6jf3xY=; b=dcLVn+HmO6M+Qz8HV3v5B9eGLNonx4fBU5svbvulpUCjV/7qf3Vig5puI/H8Ufb5xH OqE95v35ZwU0jFize3w84IKd5flF7fVwrT3eO7AkH+PcmJ3fLkLQiRcy0k72siX0cgzE GgLE/rWcICF/TQ11NILEyq6yTjVUo1KzaZzCMX5XH4pWsvMVoCKa6pm5sTddHb3UNi5X PD1Y7gQFfcZmJswAbWpJVqlAWx5gXZMjmL5lWD6All/LDZP9FLgcRk8dVhYj5tnTZsn5 jpVnm0QYkPgR+5vei1Wxkja+7ZF5Zvkd7m/DMqY57GReJ6A0xHwws2+xvbzqOliACWFO Mbnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VwUcg/v3cVNEv697eUUw0YGUsm+Jh+8ZRYx0c6jf3xY=; b=SS1FCB7kEkgal79iQTQpF/ZRT5HznZm4Yfu+nFeclWqR07Ir0mgFYHMs8ttztvJuOv oeEUKfkMgnfyJmxhTmcN+dZtvsi3wqToOl+0YHX0OOr6yGUMkPv0MgFt90c4d7CUjsCd /sOGrnvGiKLOm+3HfLqB1ACSpwGEWn9KE4qnM6T6yZfjsMXCbyhE2q1IRsRkkf9CxwBE H3pU14/1xEudojXVu/UPBUa7Cgl4yp9QVZw/6txdNyOUI9G+oy4J8XrWWI8RGgQVEnRU kIkOxO5MtrzFasHDIObSy5aEfHjWO8IiqZK84G3kAeCXuJMsR9cG5XO3Bec408FYaMQS wzZw== X-Gm-Message-State: AHPjjUiAH6ezxZxlW2glrizYIDTVb7B2mmtaIO/CRJiQCwDorjtLVQ+P J01p0edDjZw1/tO0O+9XW72dVAdxeQyfRh4= X-Google-Smtp-Source: AOwi7QCin5vcT0PeaMexhTrlGlARYYYqZuoHKep1OXjxCIH+UPnb0JqqBR9hbmNKfEc/aZsnPGiD8eYO17TL+PJhKQA= X-Received: by 10.25.223.86 with SMTP id q22mr502523lfj.45.1504843541858; Thu, 07 Sep 2017 21:05:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.198.209 with HTTP; Thu, 7 Sep 2017 21:05:41 -0700 (PDT) From: Mayank Bhatnagar Date: Fri, 8 Sep 2017 09:35:41 +0530 Message-ID: To: dots@ietf.org Content-Type: multipart/alternative; boundary="f403045e58a4c14d270558a5b06e" Archived-At: Subject: [Dots] Some queries and comments on DOTS requirements draft "draft-ietf-dots-requirements-06" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 08 Sep 2017 04:05:46 -0000 --f403045e58a4c14d270558a5b06e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi group, Completed study on requirements document draft. Some of my views and notes are provided below. Request your time to provide your remarks and clarifications, if those considerations may have already been discussed, adv/disadv if any. *Signal Channel TCP or UDP* 1. I think we should make a signal channel also MANDATORY using a reliable channel. What if a signal to start DOTS mitigationis itself lost? On Page 6, 3rd pra we see *"Operators of peer DOTS-enabled domains may enable quality- or classof-* *service traffic tagging to increase the probability of successful* *DOTS signal delivery, but DOTS requires no such policies be in place."* If thats the reqirement from a DOTS enabled domain, then how will DOTS honor it, unless we have a reliable transport in place. So its mandatory to have transport protocol to be used for signal channel. 2. What are the *preconditions/thresholds* over which a DOTS client need to start communicating with DOTS server? Can we define some examples of attacks and pre-conditions exisiting. This will serve as a guideline for new attacks and way we need to classify and handle. Or if we can define different stages of a possibe DDOS attack and then identify metrics for these, it will be beneficial to both DOTS client and server to understand the state of the network. *3. DOTS Dictionary of attack types* Can we define a dictionary or classification of types of DDOS which is arrived at and which is currently being handled. Since DOTS client and servers are inteligent DDOS agents, they can share after some considerations and after arriving at observing the kind of traffic, that this DDOS attack is a particular kind and the manner to be mitigated decided is so and so. In effect, the DOTS communicatin logs can also be looked at by a DOTS admin, so it will be helpful if any manual intervention may be needed. 3. *DOTS Logs*. What kind of logging will a DOTS server and client be doing= ? 5.* SIG-004 Channel Redirection:* What if the load mitigation effectiveness of a DOTS server begins to reduce during an ongoing attack. In that case shouldnt a mltihomed DOTS client can be asked to also share the load of attack with another DOTS server? As I study in DOTS architecture, this has been taken care by a recursive signalling mechanism hidden from client. Then is client TRUSTING the new server? Are we modelling it in same way as recursive DNS and recursive certificate chain of trust. 6.* Page 9, while discussing DOTS metrics* "Once a DOTS client requests mitigation, the client MAY withdraw that request at any time, regardless of whether mitigation is currently active. The DOTS server MUST immediately acknowledge a DOTS client=E2=80=99s request to stop mitigation." I beleive DOTS server should be intelligent enough. Based on the conditions existing, server can advice DOTS client not to stop mitigation as of now. *7. Default values* The active-but-terminating period is initially 30 seconds and mximum value as 240 seconds Is it a proposed default or can it be negotiated? *8. Section 3 : Congestion Control Considerations* "Signal channel implementations using TCP may rely on built-in TCP congestion control support." So are we open to signal channel imlementations over TCP. Is it left upto the software developers to use TCP or UDP for signal channel. thanks & regards, Mayank --f403045e58a4c14d270558a5b06e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi group,

Completed study on requiremen= ts document draft.

Some of my views and notes are = provided below. Request your time to provide your remarks and clarification= s, if those considerations may have already been discussed, adv/disadv if a= ny.

Signal Channel TCP or UDP
1. I think we should make a signal channel also MANDATORY usin= g a reliable channel. What if a signal to start DOTS mitigationis itself lo= st?

On Page 6, 3rd pra we see
"O= perators of peer DOTS-enabled domains may enable quality- or classof-
service traffic tagging to increase the probability of successf= ul
DOTS signal delivery, but DOTS requires no such policie= s be in place."

If thats the reqirement f= rom a DOTS enabled domain, then how will DOTS honor it, unless we have a re= liable transport in place. So its mandatory to have transport protocol to b= e used for signal channel.

2. What are the p= reconditions/thresholds over which a DOTS client need to start comm= unicating with DOTS server? Can we define some examples of attacks and pre-= conditions exisiting. This will serve as a guideline for new attacks and wa= y we need to classify and handle.

Or if we can def= ine different stages of a possibe DDOS attack and then identify metrics for= these, it will be beneficial to both DOTS client and server to understand = the state of the network.

3. DOTS Dictionary= of attack types
Can we define a dictionary or classifica= tion of types of DDOS which is arrived at =C2=A0and which is currently bein= g handled.=C2=A0
Since DOTS client and servers are inteligent DDO= S agents, they can share after some considerations and after arriving at ob= serving the kind of traffic, that this DDOS attack is a particular kind and= the manner to be mitigated decided is so and so.=C2=A0
In effect= , the DOTS communicatin logs can also be looked at by a DOTS admin, so it w= ill be helpful if any manual intervention may be needed.

3. DOTS Logs. What kind of logging will a DOTS server = and client be doing?


5. SIG-0= 04 Channel Redirection:
What if the load mitigation effec= tiveness of a DOTS server begins to reduce during an ongoing attack. In tha= t case shouldnt a mltihomed DOTS client can be asked to also share the load= of attack with another DOTS server?

As I study in= DOTS architecture, this has been taken care by a recursive signalling mech= anism hidden from client. Then is client TRUSTING the new server?
Are we modelling it in same way as recursive DNS and recursive certificate= chain of trust.



6.<= b> Page 9, while discussing DOTS metrics
"Once a = DOTS client requests mitigation, the client MAY withdraw
that req= uest at any time, regardless of whether mitigation is
currently a= ctive. The DOTS server MUST immediately acknowledge a
DOTS client= =E2=80=99s request to stop mitigation."

I bel= eive DOTS server should be intelligent enough. Based on the conditions exis= ting, server can advice DOTS client not to stop mitigation as of now.
=


7. Default values
The active-but-terminating period is initially 30 seconds and mximum valu= e as 240 seconds
Is it a proposed default or can it be negotiated= ?


8. Section 3 : Congestion C= ontrol Considerations
"Signal channel implementation= s using TCP may rely on built-in TCP
congestion control support.&= quot;

So are we open to signal channel imlementati= ons over TCP. Is it left upto the software developers to use TCP or UDP for= signal channel.


=C2=A0
=

thanks & regards,
Mayank
--f403045e58a4c14d270558a5b06e-- From nobody Fri Sep 8 00:27:10 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD51133134 for ; Fri, 8 Sep 2017 00:27:08 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5ZNxGJ40xus for ; Fri, 8 Sep 2017 00:27:06 -0700 (PDT) Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2747013219A for ; Fri, 8 Sep 2017 00:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=12973; q=dns/txt; s=VRSN; t=1504855533; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=k9fgOfS/6MTZUjdIjHCDdnvdGxpmifjb28z/NDoGnoY=; b=ImoUqLRFNv0d9iIxqWHxTa9axcSWkcjQG/UzL8QbD1cH5xbL7JWZaKAI dcI5WVMbsS0o4dCWMyihYSnbN37citlcsh9ZvbIwbiAif0dZcJiFb8zBW 85Ar0D3XvCPjRpGMKRR7RBeBaTXfYiFvkHLY2TQJi131BgQUlcsimdU4F FPHVZj38YONU/FeYnaLN8u8p7SiMZ8T/FBnwG9O84lMoC5OLiNhTlNWBg a05RmBJDnaLtEjGIAMKqYo8TiRw1FGI8GN0Oa8lVKxOjq52x+Dmux+cPQ rKGJ11+l9FYJSqY5ohIatoYBsryTfC5xEQWMPNR28iy8NJU5aJoIfaqEX w==; X-IronPort-AV: E=Sophos;i="5.42,360,1500940800"; d="scan'208,217";a="2405304" IronPort-PHdr: =?us-ascii?q?9a23=3AhFPG/xJR8btXmWNciNmcpTZWNBhigK39O0sv0rFi?= =?us-ascii?q?tYgeI/TxwZ3uMQTl6Ol3ixeRBMOAuqIC07KempujcFRI2YyGvnEGfc4EfD4+ou?= =?us-ascii?q?JSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgpp?= =?us-ascii?q?POT1HZPZg9iq2+yo9ZDeZwZFiCChbb9uMR67sRjfus4KjIV4N60/0AHJonxGe+?= =?us-ascii?q?RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84TaFDAzQ9L281/szrugLd?= =?us-ascii?q?QgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QKsqUjq+8ahkVB7oiD?= =?us-ascii?q?8GNzEn9mHXltdwh79frB64uhBz35LYbISTOfFjfK3SYMkaSHJBUMhPSiJBHo2y?= =?us-ascii?q?YYgBD+UDIelXoJLwqEESoRu7HwSgGP/jxz9Oi3Tr3aM6yeMhEQTe0QAuAdwBrm?= =?us-ascii?q?7brNroNKgMSey+0bHGzTTAb/9YxDzw747Icgw/rv6WUrJwbNTexFIxFwzblFWQ?= =?us-ascii?q?qJflPzKa1uQLqWSU8+1gVee2hmMhtgp/rD+vxsI2hYnIgIIY0lHE+jtlwIY7P9?= =?us-ascii?q?G4T1R7YdGiHZBNtC+aL5N7Tt4+T21ypSo3yLMLtYSmcCUKxpkr3QDTZvOIfoWO?= =?us-ascii?q?/xntTvyeIS1ii3JgYL+/ghGy/lW+xeDkTcm01UpKrjJCktnRqnABzxzT5daDSv?= =?us-ascii?q?t65kquwiyP1wbO5uFALkE0kLDUK58lwr43i5oTrVjPEjLslEXokqCWbEQk+vOp?= =?us-ascii?q?6+ToZLXqvIOTN4hxig3mM6QunNKwAfggPwQTQ2SX4/mw2b/t8EHjXblHjvM7nr?= =?us-ascii?q?PHvJ3VKskXvqu5DBVU0oYn5Ra/FTCm0NEAkHkBMFJKZgiIj4f0O17QO/34E+mw?= =?us-ascii?q?g06tkDdwxvDGMbvhDo/RIXjElbftZax95FJEyAov0dBf4IpZBawGIPLvQU/8r9?= =?us-ascii?q?3YAQElMwy62ernD8991owGU2KVHqCZKL/SsUOP5u83JumDfo8Utyz7K/gm/PHu?= =?us-ascii?q?jWU2mUMbfaaz0psYcmq4Eul7L0ibYnfhmdgBEWIQsQo/SOzmkkGNUTlWZyX6Y6?= =?us-ascii?q?VpwzgqAYSlRa3DT5yribOIxm/vG5RHb2ZFAFCFDXHheIyeAq5TOAqdJ8ZglnoP?= =?us-ascii?q?Ur33GKE70hT7/jP3wrV6I66c3Cwb/9q30sR47uLOmDks+CZ1FMWS1SeGSGQizT?= =?us-ascii?q?BAfCM/wK0q+R818VyEy6UtxqUATdE=3D?= X-IPAS-Result: =?us-ascii?q?A2GTAADLRbJZ//SZrQpSChoBAQEBAgEBAQEIAQEBARUBAQE?= =?us-ascii?q?BAgEBAQEIAQEBAYMCgRGBFY4YmkuNb4ILBwoYAQqBYIM7AoREGAEBAQEBAQEBA?= =?us-ascii?q?QEBAoEQgjMkAQ1GLAEBAQEBAU8CPi0CAQMBAWwGBRACAQgNBS0HIQYLFAMOAgQ?= =?us-ascii?q?OAwKJTUwDJa1KhzINg3sBAQEBBgEBAQEBAQEBGwWDJgSBJ4IqgWIrgn2CV4FzF?= =?us-ascii?q?QRIgw2CMQWgODwCj1mFApJljFOIKwIECwIZAYE5H3pMdxVJEgGFOoFNAUQyih4?= =?us-ascii?q?BAQE?= Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id v887R1d5004297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 Sep 2017 03:27:01 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Fri, 8 Sep 2017 03:27:01 -0400 From: "Teague, Nik" To: Mayank Bhatnagar CC: "dots@ietf.org" Thread-Topic: [Dots] Some queries and comments on DOTS requirements draft "draft-ietf-dots-requirements-06" Thread-Index: AQHTKHPcCyYUihuqpEqK/5tO9fJsxA== Date: Fri, 8 Sep 2017 07:27:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E0A029D63E5C4A37A25F440BEA0664D0Verisigncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Some queries and comments on DOTS requirements draft "draft-ietf-dots-requirements-06" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 08 Sep 2017 07:27:08 -0000 --_000_E0A029D63E5C4A37A25F440BEA0664D0Verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Thanks for the review and questions! Briefly addressing some of these: #8 and #1 - the signal channel is transport agnostic and could be over tcp = or udp. In certain conditions tcp will be fine where reliable OOB connecti= ons are available, however, if the inbound links are congested then maintai= ning tcp may be an issue and therefore udp is preferable. The signal channel works on the idea that a client will keep sending reques= ts for help like a beacon until it sees a suitable ack from the server. #2 preconditions, thresholds or triggers will depend upon the client and th= e assets being protected. E.g volumes exceeds n% of available link, sessio= ns exceed n% of web server capacity or it could be that the operator has a = policy to swing everything regardless to a path of greater scrutiny as soon= as it shows up as suspicious. #3 falls into telemetry and later work but there's scope to include this. #4 it will be implementation specific and should follow best practices. #6 the server can advise but the client is assumed to own or have suitable = authority over their assets to control the mitigation. The client may hav= e triggered a mitigation for a low level annoyance attack but once swung tr= affic is messed up badly or there's some collateral damage or w/e... not al= lowing the client to recover their traffic could be nasty. #7!I think most parameters should be negotiable where it makes sense. Thanks, -Nik On 8 Sep 2017, at 05:05, Mayank Bhatnagar > wrote: Hi group, Completed study on requirements document draft. Some of my views and notes are provided below. Request your time to provide= your remarks and clarifications, if those considerations may have already = been discussed, adv/disadv if any. Signal Channel TCP or UDP 1. I think we should make a signal channel also MANDATORY using a reliable = channel. What if a signal to start DOTS mitigationis itself lost? On Page 6, 3rd pra we see "Operators of peer DOTS-enabled domains may enable quality- or classof- service traffic tagging to increase the probability of successful DOTS signal delivery, but DOTS requires no such policies be in place." If thats the reqirement from a DOTS enabled domain, then how will DOTS hono= r it, unless we have a reliable transport in place. So its mandatory to hav= e transport protocol to be used for signal channel. 2. What are the preconditions/thresholds over which a DOTS client need to s= tart communicating with DOTS server? Can we define some examples of attacks= and pre-conditions exisiting. This will serve as a guideline for new attac= ks and way we need to classify and handle. Or if we can define different stages of a possibe DDOS attack and then iden= tify metrics for these, it will be beneficial to both DOTS client and serve= r to understand the state of the network. 3. DOTS Dictionary of attack types Can we define a dictionary or classification of types of DDOS which is arri= ved at and which is currently being handled. Since DOTS client and servers are inteligent DDOS agents, they can share af= ter some considerations and after arriving at observing the kind of traffic= , that this DDOS attack is a particular kind and the manner to be mitigated= decided is so and so. In effect, the DOTS communicatin logs can also be looked at by a DOTS admin= , so it will be helpful if any manual intervention may be needed. 3. DOTS Logs. What kind of logging will a DOTS server and client be doing? 5. SIG-004 Channel Redirection: What if the load mitigation effectiveness of a DOTS server begins to reduce= during an ongoing attack. In that case shouldnt a mltihomed DOTS client ca= n be asked to also share the load of attack with another DOTS server? As I study in DOTS architecture, this has been taken care by a recursive si= gnalling mechanism hidden from client. Then is client TRUSTING the new serv= er? Are we modelling it in same way as recursive DNS and recursive certificate = chain of trust. 6. Page 9, while discussing DOTS metrics "Once a DOTS client requests mitigation, the client MAY withdraw that request at any time, regardless of whether mitigation is currently active. The DOTS server MUST immediately acknowledge a DOTS client=92s request to stop mitigation." I beleive DOTS server should be intelligent enough. Based on the conditions= existing, server can advice DOTS client not to stop mitigation as of now. 7. Default values The active-but-terminating period is initially 30 seconds and mximum value = as 240 seconds Is it a proposed default or can it be negotiated? 8. Section 3 : Congestion Control Considerations "Signal channel implementations using TCP may rely on built-in TCP congestion control support." So are we open to signal channel imlementations over TCP. Is it left upto t= he software developers to use TCP or UDP for signal channel. thanks & regards, Mayank _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_E0A029D63E5C4A37A25F440BEA0664D0Verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for the review and questions!

Briefly addressing some of these:

#8 and #1 - the signal channel is transport = agnostic and could be over tcp or udp.  In certain conditions tcp will= be fine where reliable OOB connections are available, however, if the inbo= und links are congested then maintaining tcp may be an issue and therefore udp is preferable.

The signal channel works on the idea that a = client will keep sending requests for help like a beacon until it sees a su= itable ack from the server.

#2 preconditions, thresholds or triggers will depend upon the client a= nd the assets being protected.  E.g volumes exceeds n% of available li= nk, sessions exceed n% of web server capacity or it could be that the opera= tor has a policy to swing everything regardless to a path of greater scrutiny as soon as it shows up as suspici= ous.

#3 falls into telemetry and later work but there's scope to include th= is.

#4 it will be implementation specific and should follow best practices= .

#6 the server can advise but the client is assumed to own or have suit= able authority over their assets to control the mitigation.  The clien= t may  have triggered a mitigation for a low level annoyance attack bu= t once swung traffic is messed up badly or there's some collateral damage or w/e... not allowing the client to recove= r their traffic could be nasty.

#7!I think most parameters should be negotiable where it makes sense.<= /div>

Thanks,

-Nik

On 8 Sep 2017, at 05:05, Mayank Bhatnagar <mayankbhatnagar1178@gmail.com> wrote:

Hi group,

Completed study on requirements document draft.

Some of my views and notes are provided below. Request your time to pr= ovide your remarks and clarifications, if those considerations may have alr= eady been discussed, adv/disadv if any.

Signal Channel TCP or UDP
1. I think we should make a signal channel also MANDATORY using a reli= able channel. What if a signal to start DOTS mitigationis itself lost?

On Page 6, 3rd pra we see
"Operators of peer DOTS-enabled domains may enable quality- or= classof-
service traffic tagging to increase the probability of successful
DOTS signal delivery, but DOTS requires no such policies be in plac= e."

If thats the reqirement from a DOTS enabled domain, then how will DOTS= honor it, unless we have a reliable transport in place. So its mandatory t= o have transport protocol to be used for signal channel.

2. What are the preconditions/thresholds over which a DO= TS client need to start communicating with DOTS server? Can we define some = examples of attacks and pre-conditions exisiting. This will serve as a guid= eline for new attacks and way we need to classify and handle.

Or if we can define different stages of a possibe DDOS attack and then= identify metrics for these, it will be beneficial to both DOTS client and = server to understand the state of the network.

3. DOTS Dictionary of attack types
Can we define a dictionary or classification of types of DDOS which is= arrived at  and which is currently being handled. 
Since DOTS client and servers are inteligent DDOS agents, they can sha= re after some considerations and after arriving at observing the kind of tr= affic, that this DDOS attack is a particular kind and the manner to be miti= gated decided is so and so. 
In effect, the DOTS communicatin logs can also be looked at by a DOTS = admin, so it will be helpful if any manual intervention may be needed.

3. DOTS Logs. What kind of logging will a DOTS server an= d client be doing?


5. SIG-004 Channel Redirection:
What if the load mitigation effectiveness of a DOTS server begins to r= educe during an ongoing attack. In that case shouldnt a mltihomed DOTS clie= nt can be asked to also share the load of attack with another DOTS server?<= /div>

As I study in DOTS architecture, this has been taken care by a recursi= ve signalling mechanism hidden from client. Then is client TRUSTING the new= server?
Are we modelling it in same way as recursive DNS and recursive certifi= cate chain of trust.



6. Page 9, while discussing DOTS metrics
"Once a DOTS client requests mitigation, the client MAY withdraw<= /div>
that request at any time, regardless of whether mitigation is
currently active. The DOTS server MUST immediately acknowledge a
DOTS client=92s request to stop mitigation."

I beleive DOTS server should be intelligent enough. Based on the condi= tions existing, server can advice DOTS client not to stop mitigation as of = now.


7. Default values
The active-but-terminating period is initially 30 seconds and mximum v= alue as 240 seconds
Is it a proposed default or can it be negotiated?


8. Section 3 : Congestion Control Considerations
"Signal channel implementations using TCP may rely on built-in TC= P
congestion control support."

So are we open to signal channel imlementations over TCP. Is it left u= pto the software developers to use TCP or UDP for signal channel.


 

thanks & regards,
Mayank
_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ie= tf.org/mailman/listinfo/dots


--_000_E0A029D63E5C4A37A25F440BEA0664D0Verisigncom_-- From nobody Fri Sep 8 08:56:20 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C63C132EF6 for ; Fri, 8 Sep 2017 08:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVpVDheMU20b for ; Fri, 8 Sep 2017 08:56:16 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFAAA13292E for ; Fri, 8 Sep 2017 08:56:15 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dqLdd-0004fn-3j for ietf-supjps-dots@ietf.org; Fri, 08 Sep 2017 16:56:13 +0100 From: "Jon Shallow" To: Date: Fri, 8 Sep 2017 16:56:14 +0100 Message-ID: <070601d328ba$ffbbc440$ff334cc0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0707_01D328C3.6181D9F0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AdMouv44Udo0NFExSCOHW+HXkRNTEQ== Archived-At: Subject: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 08 Sep 2017 15:56:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0707_01D328C3.6181D9F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, We are in the process of trying to code up a DOTS Client / Server implementation based on the draft standards so far and have come up with the following list of issues / questions. Nttdots ======= An excellent starting point, but CBOR ------- The nttdots server only accepts strings for the various parameters. It does not (yet) accept CBOR that uses the CBOR mapping parameters (draft-ietf-dots-signal-channel Section 6). Signal Channel ------------------- Nttdots is expecting an additional path parameter in the POST/PUT etc path (.wellknown), so instead of /v1/dots-signal/signal, it requires /.wellknown/v1/dots-signal/signal which is not stated anywhere in the draft-ietf-dots-signal-channel draft. If not present, it returns a 4.05 code. RFC6690 refers to "/.wellknown/core" as a default entry point for discovering what resources are available. RESTCONF rfc8040 refers to "/.wellknown/host-meta" to determine the RESTCONF root resource. Data channel ----------------- Data channel support uses CBOR / COAP, not RESTCONF (well actually it goes over the signal channel), but that is documented as a current limitation, but does need to be fixed. Libcoap ======= The currently available c libcoap library (develop branch) from https://github.com/obgm/libcoap only supports DTLS with PreSharedKeys, not Certificates. Work needs to be done with this library to support PKI as well as COAP over TLS (not yet an IETF standard) to support the signal channel requirements. Doing a hack to libcoap to force known PKI keys works when used against Nttdots, so there is potential here to use a fixed version of this library. RawPublicKey has not been tried out. Libcoap requires openssl 1.1.0 or TinyDTLS - GnuTLS support is not currently available. Red Hat/Centos distributions do not have openssl 1.1.0 - DTLS support is only version 1, not version 1.2 in their versions of openssl. The openssl libraries cannot be replaced in Red Hat/Centos - the 1.1.0 version has to be installed in addition to the existing openssl libraries. Libcoap assumes that all IP addresses are IPv4 (see coap_address_t), even though there are some references to IPv6 elsewhere in the library. Default Values ============ There is a list of configurable parameters, but no suggested defaults. Signal Port - UDP ---------------------- COAP using DTLS default port is 5684 (RFC 7252), nttdots port is 4646. Should DOTS be going for / defining the same port as COAP? (https://tools.ietf.org/html/draft-mortensen-dots-over-udp-00 refers to 4646) Signal Port - TCP --------------------- This does not have to be the same as the UDP port, but looks like it is going to be 5684 as per draft-ietf-core-coap-tcp-tls. Should DOTS be going for / defining the same default port as COAP? Data Port ------------- RFC8040 - "2.2 HTTPS with X.509v3 Certificates" defines RESTCONF implementations MUST support the "https" URI scheme, which has the IANA-assigned default port 443 for "/.wellknown/host-meta". Data Port cannot easily be the same as the Signal Port (TCP) as new incoming connections are either COAP or RESTCONF and it may be difficult to differentiate. Port 443 may clash with other GUIs or applications running on port 443 on the same host as the DOTS server. However, the other GUI/applications may have to add in "/.wellknown/host-meta" to support replying that RESTCONF is running on another port. Is the Link 'restconf' definition sufficient, or de we need a link definition something like 'restconf-dots' added? What should the suggested default RESTCONF port be? Mitigation Lifetime ------------------------ This will be DOTS Server provider specific, but should be the order of days. Do we need to suggest a default lifetime? DOTS Client Restarts ================= The DOTS Client will need to re-synchronize with the DOTS Server to get the DOTS Server's current shared state (mitigation / filters etc) when it gets restarted or reconnected. Should this be stated? DOTS Server Restarts ================= The DOTS Server needs some way to signal to the DOTS client that it has restarted and that shared state needs to be re-synchronized. Should this be stated? ========================= Regards Jon ------=_NextPart_000_0707_01D328C3.6181D9F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = there,

 

We are in the process of trying to code up a DOTS = Client / Server implementation based on the draft standards so far and = have come up with the following list of issues / = questions.

 

Nttdots

=3D=3D=3D=3D=3D=3D=3D

 

An excellent = starting point, but

 

CBOR

-------

 

The nttdots = server only accepts strings for the various parameters.  It does = not (yet) accept CBOR that uses the CBOR mapping parameters = (draft-ietf-dots-signal-channel Section 6).

 

Signal = Channel

-------------------

 

Nttdots is = expecting an additional path parameter in the POST/PUT etc path = (.wellknown), so instead of /v1/dots-signal/signal, it requires = /.wellknown/v1/dots-signal/signal which is not stated anywhere in the = draft-ietf-dots-signal-channel draft.  If not present, it returns a = 4.05 code.

RFC6690 refers to =  “/.wellknown/core” as a default entry point for = discovering what resources are available.

RESTCONF rfc8040 refers to = “/.wellknown/host-meta” to determine the RESTCONF root = resource.

 

Data channel

-----------------

 

Data channel = support uses CBOR / COAP, not RESTCONF (well actually it goes over the = signal channel), but that is documented as a current limitation, but = does need to be fixed.

 

Libcoap

=3D=3D=3D=3D=3D=3D=3D

 

The = currently available c libcoap library (develop branch) from https://github.com/obgm/libcoap<= /a> only supports DTLS with PreSharedKeys, not Certificates.  Work = needs to be done with this library to support PKI as well as COAP over = TLS (not yet an IETF standard) to support the signal channel = requirements.

 

Doing a hack to libcoap to force known PKI keys works = when used against Nttdots, so there is potential here to use a fixed = version of this library.

 

RawPublicKey = has not been tried out.

 

Libcoap = requires openssl 1.1.0 or TinyDTLS – GnuTLS support is not = currently available.  Red Hat/Centos distributions do not have = openssl 1.1.0 – DTLS support is only version 1, not version 1.2 in = their versions of openssl.  The openssl libraries cannot be = replaced in Red Hat/Centos – the 1.1.0 version has to be installed = in addition to the existing openssl libraries.

 

Libcoap = assumes that all IP addresses are IPv4 (see coap_address_t), even though = there are some references to IPv6 elsewhere in the = library.

 

Default Values

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

There is a = list of configurable parameters, but no suggested = defaults.

 

Signal Port – UDP

----------------------

 

COAP using = DTLS default port is 5684 (RFC 7252), nttdots port is 4646.  Should = DOTS be going for / defining the same port as COAP?

(htt= ps://tools.ietf.org/html/draft-mortensen-dots-over-udp-00 refers to = 4646)

 

Signal Port – TCP

---------------------

 

This does = not have to be the same as the UDP port, but looks like it is going to = be 5684 as per draft-ietf-core-coap-tcp-tls.  Should DOTS be going = for / defining the same default port as COAP?

 

Data = Port

-------------

 

RFC8040 – “2.2 HTTPS with = X.509v3 Certificates” defines RESTCONF = implementations MUST support the "https" URI scheme, which = has the = IANA-assigned default port 443 for = “/.wellknown/host-meta”.

 

Data Port cannot = easily be the same as the Signal Port (TCP) as new incoming connections = are either COAP or RESTCONF and it may be difficult to = differentiate.

 

Port 443 may clash = with other GUIs or applications running on port 443 on the same host as = the DOTS server.  However, the other GUI/applications may have to = add in “/.wellknown/host-meta” to support replying that = RESTCONF is running on another port.  Is the Link = ‘restconf’ definition sufficient, or de we need a link = definition something like ‘restconf-dots’ = added?

 

What should the = suggested default RESTCONF port be?

 

Mitigation = Lifetime

------------------------

 

This will be = DOTS Server provider specific, but should be the order of days.  Do = we need to suggest a default lifetime?

 

DOTS Client = Restarts

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

The DOTS Client will need to re-synchronize with the = DOTS Server to get the DOTS Server’s current shared state = (mitigation / filters etc) when it gets restarted or reconnected.  = Should this be stated?

 

DOTS Server = Restarts

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

The DOTS Server needs some way to signal to the DOTS = client that it has restarted and that shared state needs to be = re-synchronized.  Should this be stated?

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

 

Regards

 

Jon

------=_NextPart_000_0707_01D328C3.6181D9F0-- From nobody Fri Sep 8 12:47:52 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37F9124205 for ; Fri, 8 Sep 2017 12:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzQYhGDuEHdy for ; Fri, 8 Sep 2017 12:47:48 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395201204DA for ; Fri, 8 Sep 2017 12:47:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 9034C62290 for ; Fri, 8 Sep 2017 15:47:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gNY-4is8n-Lo for ; Fri, 8 Sep 2017 15:47:38 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 616E76228F for ; Fri, 8 Sep 2017 15:47:38 -0400 (EDT) To: "dots@ietf.org" References: From: Robert Moskowitz Message-ID: Date: Fri, 8 Sep 2017 15:47:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------09344F2AE3666EDB2E2841F5" Content-Language: en-US Archived-At: Subject: Re: [Dots] New draft - guide to creating an ECDSA pki X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 08 Sep 2017 19:47:50 -0000 This is a multi-part message in MIME format. --------------09344F2AE3666EDB2E2841F5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I have pushed out a new version. CRL and OCSP support added and some cleanup. I am interested in working with the hackathon participants on what we might have for PKI. For example, two PKIs for the interorganizational testing. -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-ecdsa-pki-01.txt Date: Fri, 08 Sep 2017 12:26:36 -0700 From: internet-drafts@ietf.org To: Robert Moskowitz , Liang Xia , Henk Birkholz , Liang Xia A new version of I-D, draft-moskowitz-ecdsa-pki-01.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-ecdsa-pki Revision: 01 Title: Guide for building an ECC pki Document date: 2017-09-07 Group: Individual Submission Pages: 31 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-ecdsa-pki-01.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-ecdsa-pki-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-ecdsa-pki-01 Abstract: This memo provides a guide for building a PKI (Public Key Infrastructure) using openSSL. All certificates in this guide are ECDSA, P-256, with SHA256 certificates. Along with common End Entity certificates, this guide provides instructions for creating IEEE 802.1AR iDevID Secure Device certificates. 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 On 08/30/2017 10:00 AM, Robert Moskowitz wrote: > I have spoken to the need for Identities in DOTS agents. This implies > using X.509 certificates and making sure they work in your product. > But getting decent certificates for PoC and testing has been challenging. > > To this end, I have created a guide and put it together in an ID. I am > interested in working with those participating in the Hackathon to put > together the DOTS Hackaton PKI. > > Bob > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-moskowitz-ecdsa-pki-00.txt > Date: Wed, 30 Aug 2017 06:53:03 -0700 > From: internet-drafts@ietf.org > To: Robert Moskowitz , Liang Xia > , Henk Birkholz > , Liang Xia > > > A new version of I-D, draft-moskowitz-ecdsa-pki-00.txt > has been successfully submitted by Robert Moskowitz and posted to the > IETF repository. > > Name: draft-moskowitz-ecdsa-pki > Revision: 00 > Title: Guide for building an ECC pki > Document date: 2017-08-30 > Group: Individual Submission > Pages: 26 > URL: > https://www.ietf.org/internet-drafts/draft-moskowitz-ecdsa-pki-00.txt > Status: https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/ > Htmlized: https://tools.ietf.org/html/draft-moskowitz-ecdsa-pki-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-00 > > > Abstract: > This memo provides a guide for building a PKI (Public Key > Infrastructure) using openSSL. All certificates in this guide are > ECDSA, P-256, with SHA256 certificates. Along with common End Entity > certificates, this guide provides instructions for creating IEEE > 802.1AR [IEEE.802.1AR_2009] iDevID Secure Device certificates. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > --------------09344F2AE3666EDB2E2841F5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I have pushed out a new version.  CRL and OCSP support added and some cleanup.

I am interested in working with the hackathon participants on what we might have for PKI. For example, two PKIs for the interorganizational testing.




-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-ecdsa-pki-01.txt
Date: Fri, 08 Sep 2017 12:26:36 -0700
From: internet-drafts@ietf.org
To: Robert Moskowitz <rgm@labs.htt-consult.com>, Liang Xia <frank.xialiang@huawei.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Liang Xia <Frank.xialiang@huawei.com> 


A new version of I-D, draft-moskowitz-ecdsa-pki-01.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name:		draft-moskowitz-ecdsa-pki
Revision:	01
Title:		Guide for building an ECC pki
Document date:	2017-09-07
Group:		Individual Submission
Pages:		31
URL:            https://www.ietf.org/internet-drafts/draft-moskowitz-ecdsa-pki-01.txt
Status:         https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/
Htmlized:       https://tools.ietf.org/html/draft-moskowitz-ecdsa-pki-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-moskowitz-ecdsa-pki-01

Abstract:
   This memo provides a guide for building a PKI (Public Key
   Infrastructure) using openSSL.  All certificates in this guide are
   ECDSA, P-256, with SHA256 certificates.  Along with common End Entity
   certificates, this guide provides instructions for creating IEEE
   802.1AR iDevID Secure Device certificates.

                                                                                  


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




On 08/30/2017 10:00 AM, Robert Moskowitz wrote:
I have spoken to the need for Identities in DOTS agents.  This implies using X.509 certificates and making sure they work in your product.  But getting decent certificates for PoC and testing has been challenging.

To this end, I have created a guide and put it together in an ID.  I am interested in working with those participating in the Hackathon to put together the DOTS Hackaton PKI.

Bob




-------- Forwarded Message --------
Subject:     New Version Notification for draft-moskowitz-ecdsa-pki-00.txt
Date:     Wed, 30 Aug 2017 06:53:03 -0700
From:     internet-drafts@ietf.org
To:     Robert Moskowitz <rgm@labs.htt-consult.com>, Liang Xia <frank.xialiang@huawei.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Liang Xia <Frank.xialiang@huawei.com>


A new version of I-D, draft-moskowitz-ecdsa-pki-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name:        draft-moskowitz-ecdsa-pki
Revision:    00
Title:        Guide for building an ECC pki
Document date:    2017-08-30
Group:        Individual Submission
Pages:        26
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-ecdsa-pki-00.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-ecdsa-pki-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-00


Abstract:
   This memo provides a guide for building a PKI (Public Key
   Infrastructure) using openSSL.  All certificates in this guide are
   ECDSA, P-256, with SHA256 certificates.  Along with common End Entity
   certificates, this guide provides instructions for creating IEEE
   802.1AR [IEEE.802.1AR_2009] iDevID Secure Device certificates.




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

The IETF Secretariat


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


--------------09344F2AE3666EDB2E2841F5-- From nobody Sun Sep 10 20:48:38 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001B21329C8 for ; Sun, 10 Sep 2017 20:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwNciLR9ZeqG for ; Sun, 10 Sep 2017 20:48:33 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 BC5B813295C for ; Sun, 10 Sep 2017 20:48:32 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id m199so15344629lfe.3 for ; Sun, 10 Sep 2017 20:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HZ1CvbI6Xoq2B+E3dCosCAEofsQ5nveF9XiW6StFG8o=; b=TO3n2jRsaRKkkbbalQ5iMm/Bj8OmcMEii5DmGy5OF/AYQk4gqGXwuUNmqLVLG18sO6 XUNBQqd8Xf+qoUNxQUyMm9vwp0R07RrMf9EC3/P2Dkw68FTX4R0MnDQodPYZLrEyGJsv ykofw6wxQu0yy6F25L75gSPP0LWmOe3RZ4/7Gob1AC2M8Fx3hlGiRsQ+7hOBUxMZ+Php tU3YMLby/MDviRh6K/52ltm8eDXlm6L3XqNqISjOEN55x4Xhitn/k4w8YkhwJY7eYQkS 6inokN3BvLQG8WKx6X6wJRZXnNCtEP3Xr0whWMe8vOm71ra1KeG/N0E5WdqQU7KYe5Bc 1hzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HZ1CvbI6Xoq2B+E3dCosCAEofsQ5nveF9XiW6StFG8o=; b=RgzoGhMHpQizWOUV351UDpmmP5JpNPQj90Wp6pJo5ReyA4hWEyJXLebBg+tqoGJEDO CvyvG+mx1i4+s0EVzLtu9KLld/gmAKaQ7HrRIcEgArxGAVzBBOvUAESoafMTZFeQ/hdZ dqGJTh6r3VP8Asv9jqC5dT2LyD+p4kA9UvLRPs9VtbJ1qeGIqGbvDAOeetC/ZlfxA2Ok loA87QWrE8mneFT04462+65xTcRptLyBcx/f3tjR7YaCIArn+Za1EeKy8IXFDIA+Qq6y FFk0fqtFeG30ZdveN7+eI+ftqHdyoiL4ADKjSrpifQmVgkC3MrxOmhO3pWwgP7HaiEKv /O6w== X-Gm-Message-State: AHPjjUirbV5aaklGxO1bNNVm9B2IL4/tMgg62fzJgaWaTLF0rTxh5rxt GpPWiX18MCPtfTo5pD7WkbB4rmNZeQuLzNU= X-Google-Smtp-Source: AOwi7QBYdIxV/RWqW6Rq1l3cUNzmXu4rDoDLqTpMfIXnczhuljJYJ8/wftAB7xrJvoNHi56wklSGnbAAfTKfwHuiKvc= X-Received: by 10.46.41.133 with SMTP id p5mr1191376ljp.173.1505101710979; Sun, 10 Sep 2017 20:48:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.198.209 with HTTP; Sun, 10 Sep 2017 20:48:30 -0700 (PDT) In-Reply-To: References: From: Mayank Bhatnagar Date: Mon, 11 Sep 2017 09:18:30 +0530 Message-ID: To: "Teague, Nik" Cc: "dots@ietf.org" Content-Type: multipart/alternative; boundary="001a114b02f6d575b60558e1cc3c" Archived-At: Subject: Re: [Dots] Some queries and comments on DOTS requirements draft "draft-ietf-dots-requirements-06" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 11 Sep 2017 03:48:36 -0000 --001a114b02f6d575b60558e1cc3c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable thanks Nik for your time and reading my queries and replying on to it. 1. As yu mentioned *"however, if the inbound links are congested then maintaining tcp may be an issue and therefore udp is preferable."* Beacon signals will certainly help as you mentioned. Also, is there a mechanism to convey congestion and slip to UDP, while maintaining TCP as a default signalling mechanism 2. *#2 preconditions, thresholds or triggers will depend upon the client and the assets being protected. * So, do we plan to make a draft of possible conditions faced and beest practices of thresholds maintined as a guideline...may be we can get this as an additional section or annexure. Just a guideline and best preferable values, however dynamic conditions can determine the right metrics at that time.. Thanks again for your answers.. I am continuing reading on other areas and will provide my views and queries here... thanks again, regards, Mayank On Fri, Sep 8, 2017 at 12:57 PM, Teague, Nik wrote: > Hi, > > Thanks for the review and questions! > > Briefly addressing some of these: > > #8 and #1 - the signal channel is transport agnostic and could be over tc= p > or udp. In certain conditions tcp will be fine where reliable OOB > connections are available, however, if the inbound links are congested th= en > maintaining tcp may be an issue and therefore udp is preferable. > > The signal channel works on the idea that a client will keep sending > requests for help like a beacon until it sees a suitable ack from the > server. > > #2 preconditions, thresholds or triggers will depend upon the client and > the assets being protected. E.g volumes exceeds n% of available link, > sessions exceed n% of web server capacity or it could be that the operato= r > has a policy to swing everything regardless to a path of greater scrutiny > as soon as it shows up as suspicious. > > #3 falls into telemetry and later work but there's scope to include this. > > #4 it will be implementation specific and should follow best practices. > > #6 the server can advise but the client is assumed to own or have suitabl= e > authority over their assets to control the mitigation. The client may > have triggered a mitigation for a low level annoyance attack but once > swung traffic is messed up badly or there's some collateral damage or > w/e... not allowing the client to recover their traffic could be nasty. > > #7!I think most parameters should be negotiable where it makes sense. > > Thanks, > > -Nik > > On 8 Sep 2017, at 05:05, Mayank Bhatnagar > wrote: > > Hi group, > > Completed study on requirements document draft. > > Some of my views and notes are provided below. Request your time to > provide your remarks and clarifications, if those considerations may have > already been discussed, adv/disadv if any. > > *Signal Channel TCP or UDP* > 1. I think we should make a signal channel also MANDATORY using a reliabl= e > channel. What if a signal to start DOTS mitigationis itself lost? > > On Page 6, 3rd pra we see > *"Operators of peer DOTS-enabled domains may enable quality- or classof-* > *service traffic tagging to increase the probability of successful* > *DOTS signal delivery, but DOTS requires no such policies be in place."* > > If thats the reqirement from a DOTS enabled domain, then how will DOTS > honor it, unless we have a reliable transport in place. So its mandatory = to > have transport protocol to be used for signal channel. > > 2. What are the *preconditions/thresholds* over which a DOTS client need > to start communicating with DOTS server? Can we define some examples of > attacks and pre-conditions exisiting. This will serve as a guideline for > new attacks and way we need to classify and handle. > > Or if we can define different stages of a possibe DDOS attack and then > identify metrics for these, it will be beneficial to both DOTS client and > server to understand the state of the network. > > *3. DOTS Dictionary of attack types* > Can we define a dictionary or classification of types of DDOS which is > arrived at and which is currently being handled. > Since DOTS client and servers are inteligent DDOS agents, they can share > after some considerations and after arriving at observing the kind of > traffic, that this DDOS attack is a particular kind and the manner to be > mitigated decided is so and so. > In effect, the DOTS communicatin logs can also be looked at by a DOTS > admin, so it will be helpful if any manual intervention may be needed. > > 3. *DOTS Logs*. What kind of logging will a DOTS server and client be > doing? > > > 5.* SIG-004 Channel Redirection:* > What if the load mitigation effectiveness of a DOTS server begins to > reduce during an ongoing attack. In that case shouldnt a mltihomed DOTS > client can be asked to also share the load of attack with another DOTS > server? > > As I study in DOTS architecture, this has been taken care by a recursive > signalling mechanism hidden from client. Then is client TRUSTING the new > server? > Are we modelling it in same way as recursive DNS and recursive certificat= e > chain of trust. > > > > 6.* Page 9, while discussing DOTS metrics* > "Once a DOTS client requests mitigation, the client MAY withdraw > that request at any time, regardless of whether mitigation is > currently active. The DOTS server MUST immediately acknowledge a > DOTS client=E2=80=99s request to stop mitigation." > > I beleive DOTS server should be intelligent enough. Based on the > conditions existing, server can advice DOTS client not to stop mitigation > as of now. > > > *7. Default values* > The active-but-terminating period is initially 30 seconds and mximum valu= e > as 240 seconds > Is it a proposed default or can it be negotiated? > > > *8. Section 3 : Congestion Control Considerations* > "Signal channel implementations using TCP may rely on built-in TCP > congestion control support." > > So are we open to signal channel imlementations over TCP. Is it left upto > the software developers to use TCP or UDP for signal channel. > > > > > thanks & regards, > Mayank > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > > --001a114b02f6d575b60558e1cc3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
thanks Nik for your time and reading my queries and replyi= ng on to it.

1. As yu mentioned=C2=A0"however, i= f the inbound links are congested then maintaining tcp may be an issue and = therefore udp is preferable."

Beacon sign= als will certainly help as you mentioned.

Also, is= there a mechanism to convey congestion and slip to UDP, while maintaining = TCP as a default signalling mechanism



2. =C2=A0#2 preconditions, thresholds or triggers will= depend upon the client and the assets being protected. =C2=A0
So, do we plan to make a draft of possible conditions faced and beest pra= ctices of thresholds maintined as a guideline...may be we can get this as a= n additional section or annexure. Just a guideline and best preferable valu= es, however dynamic conditions can determine the right metrics at that time= ..

Thanks again for your answers..

<= /div>
I am continuing reading on other areas and will provide my views = and queries here...

thanks again,
regard= s,
Mayank


On Fri, Sep 8, 2017 at 12:57 PM, Teague, Nik <nt= eague@verisign.com> wrote:
Hi,

Thanks for the re= view and questions!

Briefly addressin= g some of these:

#8 and #1 - the s= ignal channel is transport agnostic and could be over tcp or udp.=C2=A0 In = certain conditions tcp will be fine where reliable OOB connections are avai= lable, however, if the inbound links are congested then maintaining tcp may be an issue and therefore udp is preferable.

The signal channe= l works on the idea that a client will keep sending requests for help like = a beacon until it sees a suitable ack from the server.

#2 preconditions, thresholds or triggers will depend upon the client a= nd the assets being protected.=C2=A0 E.g volumes exceeds n% of available li= nk, sessions exceed n% of web server capacity or it could be that the opera= tor has a policy to swing everything regardless to a path of greater scrutiny as soon as it shows up as suspici= ous.

#3 falls into telemetry and later work but there's scope to includ= e this.

#4 it will be implementation specific and should follow best practices= .

#6 the server can advise but the client is assumed to own or have suit= able authority over their assets to control the mitigation.=C2=A0 The clien= t may =C2=A0have triggered a mitigation for a low level annoyance attack bu= t once swung traffic is messed up badly or there's some collateral damage or w/e... not allowing the client to re= cover their traffic could be nasty.

#7!I think most parameters should be negotiable where it makes sense.<= /div>

Thanks,

-Nik

On 8 Sep 2017, at 05:05, Mayank Bhatnagar <mayankbhatnagar1178@gmail.com> wrote:

Hi group,

Completed study on requirements document draft.

Some of my views and notes are provided below. Request your time to pr= ovide your remarks and clarifications, if those considerations may have alr= eady been discussed, adv/disadv if any.

Signal Channel TCP or UDP
1. I think we should make a signal channel also MANDATORY using a reli= able channel. What if a signal to start DOTS mitigationis itself lost?

On Page 6, 3rd pra we see
"Operators of peer DOTS-enabled domains may enable quality- or= classof-
service traffic tagging to increase the probability of successful
DOTS signal delivery, but DOTS requires no such policies be in plac= e."

If thats the reqirement from a DOTS enabled domain, then how will DOTS= honor it, unless we have a reliable transport in place. So its mandatory t= o have transport protocol to be used for signal channel.

2. What are the preconditions/thresholds over which a DO= TS client need to start communicating with DOTS server? Can we define some = examples of attacks and pre-conditions exisiting. This will serve as a guid= eline for new attacks and way we need to classify and handle.

Or if we can define different stages of a possibe DDOS attack and then= identify metrics for these, it will be beneficial to both DOTS client and = server to understand the state of the network.

3. DOTS Dictionary of attack types
Can we define a dictionary or classification of types of DDOS which is= arrived at =C2=A0and which is currently being handled.=C2=A0
Since DOTS client and servers are inteligent DDOS agents, they can sha= re after some considerations and after arriving at observing the kind of tr= affic, that this DDOS attack is a particular kind and the manner to be miti= gated decided is so and so.=C2=A0
In effect, the DOTS communicatin logs can also be looked at by a DOTS = admin, so it will be helpful if any manual intervention may be needed.

3. DOTS Logs. What kind of logging will a DOTS server an= d client be doing?


5. SIG-004 Channel Redirection:
What if the load mitigation effectiveness of a DOTS server begins to r= educe during an ongoing attack. In that case shouldnt a mltihomed DOTS clie= nt can be asked to also share the load of attack with another DOTS server?<= /div>

As I study in DOTS architecture, this has been taken care by a recursi= ve signalling mechanism hidden from client. Then is client TRUSTING the new= server?
Are we modelling it in same way as recursive DNS and recursive certifi= cate chain of trust.



6. Page 9, while discussing DOTS metrics
"Once a DOTS client requests mitigation, the client MAY withdraw<= /div>
that request at any time, regardless of whether mitigation is
currently active. The DOTS server MUST immediately acknowledge a
DOTS client=E2=80=99s request to stop mitigation."

I beleive DOTS server should be intelligent enough. Based on the condi= tions existing, server can advice DOTS client not to stop mitigation as of = now.


7. Default values
The active-but-terminating period is initially 30 seconds and mximum v= alue as 240 seconds
Is it a proposed default or can it be negotiated?


8. Section 3 : Congestion Control Considerations
"Signal channel implementations using TCP may rely on built-in TC= P
congestion control support."

So are we open to signal channel imlementations over TCP. Is it left u= pto the software developers to use TCP or UDP for signal channel.


=C2=A0

thanks & regards,
Mayank
_______________________________________________
Dots mailing list
Dots@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/dots



--001a114b02f6d575b60558e1cc3c-- From nobody Sun Sep 10 23:17:34 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB34132139 for ; Sun, 10 Sep 2017 23:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkzQdRJJbbGw for ; Sun, 10 Sep 2017 23:17:31 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0130.outbound.protection.outlook.com [104.47.42.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54467126BF3 for ; Sun, 10 Sep 2017 23:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yqVKU+CoA5MclwRu6BF6Dhx7vDYDvu5DmQdW0iJ1b1E=; b=egjza924m2hi8rg5mYUVBGZPU/QtXQrINgYrTQwBPPV8HbxheAv4Hdnt+jLgpJcoC2VRTwv9GoWR1KjwKBu1nVN6m9cqvAZ2dAAsGBBmIFqA57lFYAZPsIRIFc2h/CvXKj51nvm+ouolKsCLwMaTZoU6FnLQzAG9Ahg4ZaiugfM= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1165.prod.exchangelabs.com (10.160.135.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.12; Mon, 11 Sep 2017 06:17:29 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::f4d3:7c95:465c:e5b]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::f4d3:7c95:465c:e5b%15]) with mapi id 15.20.0035.020; Mon, 11 Sep 2017 06:17:29 +0000 From: "Dobbins, Roland" To: Mayank Bhatnagar CC: EXT-Teague Nik , "dots@ietf.org" Thread-Topic: [Dots] Some queries and comments on DOTS requirements draft "draft-ietf-dots-requirements-06" Thread-Index: AQHTKFfDklfEHNHJf0GX5D6ceDOVLqKqlwgAgAR58gCAACmgZQ== Date: Mon, 11 Sep 2017 06:17:28 +0000 Message-ID: <78FBE739-A041-4B8B-8127-3D65EE0698ED@arbor.net> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; x-originating-ip: [2405:9800:bc00:7dfb:8824:2117:b1b5:904] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1165; 6:p1csrDV3yATys9atUrwGQtRZa93PcgGfXyQpOuKt26Y+Mm4Q6HFWlgpXBxAbL9PMN3Pp8Tt8dCRo+guE8pwH2SdIu+1PXrcf2yhRpU5Try/lA0jtpIv/c5MfWD5EdIHY9tc9uyk9879F/eU3PD+uJ2MgSSWyAsdDpxrurwqtzbJ0FGrOOAcJr9jUwSkhnger/bPzOs2urmKVyeDiHUAVFwYJI6TXBWqosK6qRK9lvddgXHBzRupXUPdvmkMYwFPrfOfQkiXlcZ7S57B1UTA3mgJ6ZCEXMAKSwowX1w30hmb52VNl0QrGE2DHprlNXNZMFUKFtMVuphE88+PqgX7dIA==; 5:GEkoYYcubK6fYQdwzsoiDcCM5KJpgDrTEL585Qc1T9WmoX3lCXkH19BwFvnTrR4QLOk6WaFw1FCVVjbhyof/f5rnOHaXaoVGwa/XCFYIDRafwYGU5lUz350Tfx0QXLpy12Ck+s4NccwnWDlX1hs9aA==; 24:34GoPWYmvEd1+zEA/psRCzesxpkerUSz7Ly/n3j1iYdBQ5Tvgl3JYmosdQ9M2N5bzIwRndfh8UeBwp5kwR9CiTucTW7PDNag1W0xgFBZh5Q=; 7:4jxIRkAj23V80mgr8wO9lTaBuqOXr6YurHMv3UV+Krx10ua0quDCipFQnK+4vfrwljr8bWTy5/mEIJI60nE9eVuW8HeiQSU/RnHPkt5J4e8HiyjEnHQnr07ppU9XMqKG0t+u4n/9q2VicG4jeflAT1gFJt2KQ+PSqDWiEzbvD+yMJoYsxpVRAUztivVIFWedB5Ck3cCa0/GRH3Vxxd0v3mIR13gqEU73T2Ejbypxixk= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ld-processed: 54f11205-d4aa-4809-bd36-0b542199c5b2,ExtAddr x-ms-office365-filtering-correlation-id: c3dd024d-25ec-4397-3505-08d4f8dcc7a1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1165; x-ms-traffictypediagnostic: DM2PR0101MB1165: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1165; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1165; x-forefront-prvs: 04270EF89C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39830400002)(24454002)(189002)(199003)(229853002)(82746002)(102836003)(6436002)(305945005)(8936002)(7736002)(8676002)(81166006)(5660300001)(68736007)(76176999)(5250100002)(54356999)(6916009)(36756003)(83716003)(86362001)(97736004)(53936002)(230783001)(81156014)(2900100001)(6486002)(6506006)(50986999)(101416001)(2950100002)(54906002)(99286003)(1411001)(6512007)(106356001)(33656002)(105586002)(110136004)(189998001)(6116002)(39060400002)(6246003)(478600001)(25786009)(14454004)(53546010)(2906002)(3660700001)(3280700002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1165; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2017 06:17:28.7432 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1165 Archived-At: Subject: Re: [Dots] Some queries and comments on DOTS requirements draft "draft-ietf-dots-requirements-06" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 11 Sep 2017 06:17:33 -0000 > On Sep 11, 2017, at 10:48, Mayank Bhatnagar wrote: >=20 > So, do we plan to make a draft of possible conditions faced and beest pra= ctices of thresholds maintined as a guideline. No, because this is both obvious & at the same time entirely situationally-= dependent. There is no generalizable advice which can be given. ----------------------------------- Roland Dobbins = From nobody Mon Sep 11 06:13:42 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE7A133077 for ; Mon, 11 Sep 2017 06:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0e7b4mwhq8a for ; Mon, 11 Sep 2017 06:13:38 -0700 (PDT) Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6DCA132199 for ; Mon, 11 Sep 2017 06:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=11291; q=dns/txt; s=VRSN; t=1505135525; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=60qu8D1/jX3aVtnj4ihR/W5a79ln+gK2Vc2UeLvZ6Yo=; b=Vt9hgDt5poLlkN0PwTjdzZScQHtKwli0ola1W3Wu9kry3Eyp4cHHn4aw jAIOmOnbDRNnlQjNijZiZTnKIzN9jaqdb0SbwWqLT6tmcUK/IrCVwUjOB K0CDfOrvESlDIMiMW401Jsd485hLYRFTb8eF34hX/AzGTRZGNU8467RzR TtiUCZ/fcOdFgnkKgxuOHvrxT8vw2WVqaGlfcfExwHXtVk4MQEtuEE9Kc Z8aXDi7IzebPtzQInZkZgZsfaZn42xBG14sSpgm8qFZwsXnGxh3WumwcA Wev9SNxQbQanyYH+n6AS+en+Xwjgvt4g1iYYKowy31DuVtgB4SPomcisO w==; X-IronPort-AV: E=Sophos;i="5.42,377,1500940800"; d="scan'208,217";a="4563086" IronPort-PHdr: =?us-ascii?q?9a23=3AERje7h9T8GaVcv9uRHKM819IXTAuvvDOBiVQ1KB3?= =?us-ascii?q?2uwcTK2v8tzYMVDF4r011RmSDNWds6oMotGVmpioYXYH75eFvSJKW713fDhBt/?= =?us-ascii?q?8rmRc9CtWOE0zxIa2iRSU7GMNfSA0tpCnjYgBaF8nkelLdvGC54yIMFRXjLwp1?= =?us-ascii?q?Ifn+FpLPg8it2e2//57ebx9UiDahfLh/MAi4oQLNu8cMnIBsMLwxyhzHontJf+?= =?us-ascii?q?RZ22ZlLk+Nkhj/+8m94odt/zxftPw9+cFAV776f7kjQrxDEDsmKWE169b1uhTF?= =?us-ascii?q?UACC+2ETUmQSkhpPHgjF8BT3VYr/vyfmquZw3jSRMNboRr4oRzut86ZrSAfpiC?= =?us-ascii?q?gZMT457HrXgdF0gK5CvR6tuwBzz4vSbYqINvRxY7ndcMsaS2RfQ8hRSyJPDICy?= =?us-ascii?q?b4QNAeUBPPpXoIbmqlQUsRe+ABOhCP/1xzJKgHL9wK000/4mEQHDxAEsEcwAv2?= =?us-ascii?q?rOo9X6KacdT/i5x7TQwzXCbPNa1yr25Y/OchA9v/6DR71wcdfPxkQ0CQPKkE+Q?= =?us-ascii?q?qY3+PzOU2eQNtXKX4PZnVeKqkmMqrRx6rDu3xso0l4XFmpgZxk3G+Ch32oo5ON?= =?us-ascii?q?21RUBhbdK6H5ZdtzmWO5ZqTs84Xm1lujo2xqcbtZO0fyUG0okryh3ZZveaaYaH?= =?us-ascii?q?+AjjW/yUITpggXJlf6+wiAiq/Ei7z+38StG00FFXripZitXMtm4C1xjU6sWfUf?= =?us-ascii?q?R95EGh1SuL1wHc7+FLO0E0la7cK5483r48ioQfvV7dHiDogkX2jbSWdkQr+uiu?= =?us-ascii?q?8ejofrLmppqEO491jAHxLLgul9SiDegkKAQCQmqW9Oqm2LH+/UD0Tq9GguM5n6?= =?us-ascii?q?TZqJzaIN4Upq+9Aw9byIYj7BO/Ai+g0NQEg3YINl1FeA+ZgIXyJVHBPur4Dfak?= =?us-ascii?q?g1StnzdrwerKMaHmApXINnTDiqvufa5h605Azwo+1c1Q55VICrEaO//zW1H+tM?= =?us-ascii?q?DWDhMjNAy02ennAs1n1owCQWKPHrOZMKTKvF+N/O0uI/ODZIkWuDnmK/gq/eLu?= =?us-ascii?q?jXkjll8SZ6apx4YbZG26E/llOEiZbn/sjc0AEWcOpAYxUOvqiFjRGQJUMlO7Tq?= =?us-ascii?q?s65XkRCIu6C47MT5rl1LmIzS69HZdWb3xAA1+FCy6xKNWsVPIFaSbUKchkxG8q?= =?us-ascii?q?T7+kHsUd2BihqQK+g5xmLaCcrisEuJvsydVd+eDJlAoz+joyBMOYhTLeB1pol3?= =?us-ascii?q?8FEmdllJt0plZwnxLaifB1?= X-IPAS-Result: =?us-ascii?q?A2GMCAB6i7ZZ//WZrQpcGwEBAQMBAQEJAQEBFQEBAQECAQE?= =?us-ascii?q?BAQgBAQEBgkWBT4EVB2aDCpwShHWDZ41vOwSBUwoTJIUHAhqESBYBAQEBAQEBA?= =?us-ascii?q?QEBAQKBEIIzJAGCQQYjVhACAQgNLgQDAgICHxEUEQIEDgWJTUwDrDGCJyeHBQ2?= =?us-ascii?q?DfAEBAQEBAQEBAQEBAQEBAQEBAQEfgyuDU4INC4JygliCNoJ8MIIxBaA4PAKPW?= =?us-ascii?q?YcJhWeKd4xTiCsCBAsCGQGBOSYMgTN3FVwBhQUcGYFOdogwgQ8BAQE?= Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id v8BDDaxf006160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Sep 2017 09:13:36 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Mon, 11 Sep 2017 09:13:35 -0400 From: "Teague, Nik" To: Mayank Bhatnagar CC: "dots@ietf.org" Thread-Topic: [EXTERNAL] Re: [Dots] Some queries and comments on DOTS requirements draft "draft-ietf-dots-requirements-06" Thread-Index: AQHTKHPcCyYUihuqpEqK/5tO9fJsxKKvU9AAgACupAA= Date: Mon, 11 Sep 2017 13:13:34 +0000 Message-ID: <38329242-F7E9-4D68-B9CF-460AE7D6CE07@verisign.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-originating-ip: [10.170.148.18] Content-Type: multipart/alternative; boundary="_000_38329242F7E94D68B9CF460AE7D6CE07verisigncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Some queries and comments on DOTS requirements draft "draft-ietf-dots-requirements-06" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 11 Sep 2017 13:13:40 -0000 --_000_38329242F7E94D68B9CF460AE7D6CE07verisigncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWF5YW5rIGhpLA0KDQpQbGVhc2Ugc2VlIGlubGluZSAtDQoNCk9uIDExLzA5LzIwMTcsIDA0OjQ4 LCAiTWF5YW5rIEJoYXRuYWdhciIgPG1heWFua2JoYXRuYWdhcjExNzhAZ21haWwuY29tPG1haWx0 bzptYXlhbmtiaGF0bmFnYXIxMTc4QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQp0aGFua3MgTmlrIGZv ciB5b3VyIHRpbWUgYW5kIHJlYWRpbmcgbXkgcXVlcmllcyBhbmQgcmVwbHlpbmcgb24gdG8gaXQu DQoNCjEuIEFzIHl1IG1lbnRpb25lZCAiaG93ZXZlciwgaWYgdGhlIGluYm91bmQgbGlua3MgYXJl IGNvbmdlc3RlZCB0aGVuIG1haW50YWluaW5nIHRjcCBtYXkgYmUgYW4gaXNzdWUgYW5kIHRoZXJl Zm9yZSB1ZHAgaXMgcHJlZmVyYWJsZS4iDQoNCkJlYWNvbiBzaWduYWxzIHdpbGwgY2VydGFpbmx5 IGhlbHAgYXMgeW91IG1lbnRpb25lZC4NCg0KQWxzbywgaXMgdGhlcmUgYSBtZWNoYW5pc20gdG8g Y29udmV5IGNvbmdlc3Rpb24gYW5kIHNsaXAgdG8gVURQLCB3aGlsZSBtYWludGFpbmluZyBUQ1Ag YXMgYSBkZWZhdWx0IHNpZ25hbGxpbmcgbWVjaGFuaXNtDQoNCllvdSBjb3VsZCBlbXBsb3kgYSDi gJxoYXBweSBleWViYWxsc+KAnSBsaWtlIG1lY2hhbmlzbSBpZiB5b3UgcHJlZmVyLiAgVGhpcyBo YXMgYmVlbiBjYWxsZWQgb3V0IGEgZmV3IHRpbWVzIOKAkyBhcyBmYXIgYXMgZG9pbmcgc28gZHlu YW1pY2FsbHkgYXMgaW4gZmxpcHBpbmcgZnJvbSBvbmUgdG8gdGhlIG90aGVyIG1pZCBzdHJlYW0g 4oCTIHRoYXQgc2VlbXMgZXhjZXNzaXZlbHkgY29tcGxleC4NCg0KDQoyLiAgIzIgcHJlY29uZGl0 aW9ucywgdGhyZXNob2xkcyBvciB0cmlnZ2VycyB3aWxsIGRlcGVuZCB1cG9uIHRoZSBjbGllbnQg YW5kIHRoZSBhc3NldHMgYmVpbmcgcHJvdGVjdGVkLg0KU28sIGRvIHdlIHBsYW4gdG8gbWFrZSBh IGRyYWZ0IG9mIHBvc3NpYmxlIGNvbmRpdGlvbnMgZmFjZWQgYW5kIGJlZXN0IHByYWN0aWNlcyBv ZiB0aHJlc2hvbGRzIG1haW50aW5lZCBhcyBhIGd1aWRlbGluZS4uLm1heSBiZSB3ZSBjYW4gZ2V0 IHRoaXMgYXMgYW4gYWRkaXRpb25hbCBzZWN0aW9uIG9yIGFubmV4dXJlLiBKdXN0IGEgZ3VpZGVs aW5lIGFuZCBiZXN0IHByZWZlcmFibGUgdmFsdWVzLCBob3dldmVyIGR5bmFtaWMgY29uZGl0aW9u cyBjYW4gZGV0ZXJtaW5lIHRoZSByaWdodCBtZXRyaWNzIGF0IHRoYXQgdGltZS4uDQoNCkkgd291 bGQgYWdyZWUgd2l0aCBSb2xhbmTigJlzIGNvbW1lbnRzIHRoYXQgdGhlIGJyZWFkdGggb2YgdGhl IHN1YmplY3QgaXMgc2l0dWF0aW9uYWxseSBkZXBlbmRlbnQgdXBvbiBhIG51bWJlciBvZiBmYWN0 b3JzIHNvbWUgb2YgdGhlbSByZWxhdGVkIHRvIG91dCBvZiBiYW5kIHRvcGljcyBzdWNoIGFzIGJ1 c2luZXNzIGxvZ2ljLiAgVGhlIHVzZSBjYXNlcyBkcmFmdCBhbGx1ZGVzIHRvIHRoZXNlIGF0IGEg aGlnaCBsZXZlbC4gIElmIHlvdSB3b3VsZCBsaWtlIHRvIHNlZSB0aGlzIGtpbmQgc3ViamVjdCBk b2N1bWVudGVkIG1vcmUgZGVlcGx5IHRoZW4geW91IGNvdWxkIGNlcnRhaW5seSBjcmVhdGUgYSBk cmFmdCBhbmQgc3VibWl0IGl0IHRvIHRoZSB3b3JraW5nIGdyb3VwLg0KDQpUaGFua3MsDQoNCi1O aWsNCg== --_000_38329242F7E94D68B9CF460AE7D6CE07verisigncom_ Content-Type: text/html; charset="utf-8" Content-ID: <4CB76D296975BC4DB4ED0D3CC1D1F564@verisign.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5 NS4wcHQgODQyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVh ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+TWF5YW5rIGhpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2Ugc2VlIGlubGluZSAt IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPk9uIDExLzA5LzIwMTcsIDA0OjQ4LCAmcXVvdDtNYXlhbmsgQmhhdG5hZ2FyJnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWF5YW5rYmhhdG5hZ2FyMTE3OEBnbWFpbC5jb20iPm1h eWFua2JoYXRuYWdhcjExNzhAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlm O2NvbG9yOmJsYWNrIj50aGFua3MgTmlrIGZvciB5b3VyIHRpbWUgYW5kIHJlYWRpbmcgbXkgcXVl cmllcyBhbmQgcmVwbHlpbmcgb24gdG8gaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFj ayI+MS4gQXMgeXUgbWVudGlvbmVkJm5ic3A7PGk+JnF1b3Q7aG93ZXZlciwgaWYgdGhlIGluYm91 bmQgbGlua3MgYXJlIGNvbmdlc3RlZCB0aGVuIG1haW50YWluaW5nIHRjcCBtYXkgYmUgYW4gaXNz dWUgYW5kIHRoZXJlZm9yZSB1ZHAgaXMgcHJlZmVyYWJsZS4mcXVvdDs8L2k+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQt c3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5k YXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5CZWFjb24gc2lnbmFscyB3aWxsIGNlcnRhaW5s eSBoZWxwIGFzIHlvdSBtZW50aW9uZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9y OmJsYWNrIj5BbHNvLCBpcyB0aGVyZSBhIG1lY2hhbmlzbSB0byBjb252ZXkgY29uZ2VzdGlvbiBh bmQgc2xpcCB0byBVRFAsIHdoaWxlIG1haW50YWluaW5nIFRDUCBhcyBhIGRlZmF1bHQgc2lnbmFs bGluZyBtZWNoYW5pc208bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1z dGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPllvdSBjb3VsZCBlbXBs b3kgYSDigJxoYXBweSBleWViYWxsc+KAnSBsaWtlIG1lY2hhbmlzbSBpZiB5b3UgcHJlZmVyLiZu YnNwOyBUaGlzIGhhcyBiZWVuIGNhbGxlZCBvdXQgYSBmZXcgdGltZXMg4oCTIGFzIGZhciBhcyBk b2luZyBzbyBkeW5hbWljYWxseSBhcyBpbiBmbGlwcGluZyBmcm9tIG9uZSB0byB0aGUgb3RoZXIN CiBtaWQgc3RyZWFtIOKAkyB0aGF0IHNlZW1zIGV4Y2Vzc2l2ZWx5IGNvbXBsZXguPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJr aXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0 YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFy ZCZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+Mi4gJm5ic3A7PGk+IzIgcHJlY29uZGl0aW9ucywg dGhyZXNob2xkcyBvciB0cmlnZ2VycyB3aWxsIGRlcGVuZCB1cG9uIHRoZSBjbGllbnQgYW5kIHRo ZSBhc3NldHMgYmVpbmcgcHJvdGVjdGVkLiAmbmJzcDs8L2k+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPlNvLCBkbyB3ZSBwbGFuIHRvIG1ha2UgYSBkcmFmdCBv ZiBwb3NzaWJsZSBjb25kaXRpb25zIGZhY2VkIGFuZCBiZWVzdCBwcmFjdGljZXMgb2YgdGhyZXNo b2xkcyBtYWludGluZWQgYXMgYSBndWlkZWxpbmUuLi5tYXkgYmUgd2UgY2FuIGdldCB0aGlzIGFz DQogYW4gYWRkaXRpb25hbCBzZWN0aW9uIG9yIGFubmV4dXJlLiBKdXN0IGEgZ3VpZGVsaW5lIGFu ZCBiZXN0IHByZWZlcmFibGUgdmFsdWVzLCBob3dldmVyIGR5bmFtaWMgY29uZGl0aW9ucyBjYW4g ZGV0ZXJtaW5lIHRoZSByaWdodCBtZXRyaWNzIGF0IHRoYXQgdGltZS4uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5J IHdvdWxkIGFncmVlIHdpdGggUm9sYW5k4oCZcyBjb21tZW50cyB0aGF0IHRoZSBicmVhZHRoIG9m IHRoZSBzdWJqZWN0IGlzIHNpdHVhdGlvbmFsbHkgZGVwZW5kZW50IHVwb24gYSBudW1iZXIgb2Yg ZmFjdG9ycyBzb21lIG9mIHRoZW0gcmVsYXRlZCB0byBvdXQgb2YgYmFuZCB0b3BpY3Mgc3VjaCBh cyBidXNpbmVzcw0KIGxvZ2ljLiZuYnNwOyBUaGUgdXNlIGNhc2VzIGRyYWZ0IGFsbHVkZXMgdG8g dGhlc2UgYXQgYSBoaWdoIGxldmVsLiZuYnNwOyBJZiB5b3Ugd291bGQgbGlrZSB0byBzZWUgdGhp cyBraW5kIHN1YmplY3QgZG9jdW1lbnRlZCBtb3JlIGRlZXBseSB0aGVuIHlvdSBjb3VsZCBjZXJ0 YWlubHkgY3JlYXRlIGEgZHJhZnQgYW5kIHN1Ym1pdCBpdCB0byB0aGUgd29ya2luZyBncm91cC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7 Y29sb3I6YmxhY2siPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZx dW90OyxzZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQt c3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPi1OaWs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_38329242F7E94D68B9CF460AE7D6CE07verisigncom_-- From nobody Mon Sep 11 21:13:26 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E8A128D0F for ; Mon, 11 Sep 2017 21:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3MY_6OulYaQ for ; Mon, 11 Sep 2017 21:13:24 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64C5128D0D for ; Mon, 11 Sep 2017 21:13:23 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id m199so23191260lfe.3 for ; Mon, 11 Sep 2017 21:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OZRo/qCj74RkXtWT3RyYJ0Q40vSN86HdRziWlSVeKGI=; b=Q/4lX8Mn5p/6nH96M2q0fkJ9O2MWTj7P7zWxG5SoBhoYiD75ytpyvTx+U37cIU0KLG EAk1gvTfC0nk57j6Hs8cd63JsjMiLa90twtiC0Pejp6apKtrgQom5T6n2mB0UaraGu4m 4Qc4emExHjDd+vW0Z2AtnYo8gnHx/cXDNiAfzVh3TAy8vwDu0acBumNcilCHXWntpwCH QM+A6ZkQO71KUV2gQPn5481EwQerCUsYWfak3gzS707VkaWkzM2Oq5KMNaqT7xO7yW6S R6XC5BuskKjsoXhPYdtLOjGv8TA+bej34IcZqbbB9SytOzv7IkBggm5e0UPmfGtyffM6 gwvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OZRo/qCj74RkXtWT3RyYJ0Q40vSN86HdRziWlSVeKGI=; b=k+OGeUVjAxIOhR/BOxEf+tWf++nRLEfxBlyJ7+a5VNOjR/0UKBoXeDkrZu7MG9V5NW aZjhgVa4glC9wD0zSJkwSEoY7/PUWkBFsA2/asMp8InFucpM/v0uT5Cb8YSyGD6zGCPd L1ejXznR5I5OO3ZdD5VhrtsQcEruhXZOJ4g1hDp6p7VgpQs+BbIRhAotF+MehRQvp5tJ RizvbO3J3+XF4GcXREsg4MedZ/OaSRG0yn0BcVM44noAztPprVLcymR/gCpHJcdrdtiQ V6jOX5D2FCyikI9uYfXVSZokgW9pWrV4sfRahOje3TtqA9xUezAeDd8OMk128uKsSosN Y42Q== X-Gm-Message-State: AHPjjUhqpqbQn3OseZDAC/LGBH1XHLbUcnCKIzXm12ZXn2zuXdGsekTX 6WzBzvOhXo5oBqOHquW1rhJH0yzAgE4O X-Google-Smtp-Source: AOwi7QDUZOiRtZBT+iDvEwMFbxOuWFj9fOjwkrzGNnmXL+JB7kzelVkg+3YCSUCa/ym150CYc1b8w4319bmta/m//OM= X-Received: by 10.46.83.5 with SMTP id h5mr5302220ljb.181.1505189601986; Mon, 11 Sep 2017 21:13:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.198.209 with HTTP; Mon, 11 Sep 2017 21:13:20 -0700 (PDT) In-Reply-To: <78FBE739-A041-4B8B-8127-3D65EE0698ED@arbor.net> References: <78FBE739-A041-4B8B-8127-3D65EE0698ED@arbor.net> From: Mayank Bhatnagar Date: Tue, 12 Sep 2017 09:43:20 +0530 Message-ID: To: "Dobbins, Roland" Cc: EXT-Teague Nik , "dots@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1cee588bcf990558f64334" Archived-At: Subject: Re: [Dots] Some queries and comments on DOTS requirements draft "draft-ietf-dots-requirements-06" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 12 Sep 2017 04:13:25 -0000 --94eb2c1cee588bcf990558f64334 Content-Type: text/plain; charset="UTF-8" thanks Roland. regards, Mayank On Mon, Sep 11, 2017 at 11:47 AM, Dobbins, Roland wrote: > > > > On Sep 11, 2017, at 10:48, Mayank Bhatnagar < > mayankbhatnagar1178@gmail.com> wrote: > > > > So, do we plan to make a draft of possible conditions faced and beest > practices of thresholds maintined as a guideline. > > No, because this is both obvious & at the same time entirely > situationally-dependent. There is no generalizable advice which can be > given. > > ----------------------------------- > Roland Dobbins --94eb2c1cee588bcf990558f64334 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
thanks Roland.

regards,
Mayan= k

On M= on, Sep 11, 2017 at 11:47 AM, Dobbins, Roland <rdobbins@arbor.net>= wrote:


> On Sep 11, 2017, at 10:48, Mayank Bhatnagar <mayankbhatnagar1178@gmail.com> wrote= :
>
> So, do we plan to make a draft of possible conditions faced and beest = practices of thresholds maintined as a guideline.

No, because this is both obvious & at the same time entirely sit= uationally-dependent.=C2=A0 There is no generalizable advice which can be g= iven.

-----------------------------------
Roland Dobbins <rdobbins@arbor.net= >

--94eb2c1cee588bcf990558f64334-- From nobody Mon Sep 11 21:16:55 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE280128D0D for ; Mon, 11 Sep 2017 21:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SW_GcgPXPi4z for ; Mon, 11 Sep 2017 21:16:53 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8EB112421A for ; Mon, 11 Sep 2017 21:16:52 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id 80so23206788lfy.4 for ; Mon, 11 Sep 2017 21:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=moeA3c2q9vK0jxX4FlTjO/aI6S2Do0erxDF2o+Luae0=; b=YXyueQL62q2qXg0NmT0e2tLqPoz+I7E2W34BrOpeK4ErpMWDRIdNM4Mj27usrrgi5k w+6X9ZrR07k1cbjSzqpuAoZdKv/bYF70wUIdbSc1UCa2kQ8emlWq7tLsYc81wJsD/1ya 9dfZMaAd6n1ywrF+iTxDMb4hOwMnjVngLWtiWFgY92RBxcdloBVAnxazKcfOIxLlxuMd SHlLyLWI7meT4DSYxcjguHN6gCIuz1aTeUUSTivgEYf/ksuzWuesxZnuQQW0CZ77aTiV 0VYLRFOkcctjlc+xXUoPyq1pWx/FT6ZRgmho0PV3rO7Hc2w0rKiGcP3XKFWNhrbgEP0G s5wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=moeA3c2q9vK0jxX4FlTjO/aI6S2Do0erxDF2o+Luae0=; b=YVBcnSwNjUtZY85r6RKn6/Hbi7ibpZPLP0Gei7+gzFhhbtout9FeaswI+jNTb6tnwx 3iP6PCUBEyNFd8Vh16aKjjwWSVB0kA7ScPshjrXYZEyLPreQP8+2PQNloqqYEha/JaDg Gs/oqWJwFHSjNkAQAQX26dFkGIr40hB4qb3W9+mrR+zzV7MoY11DSD+gY973V/d8O1+V mz7OnkZ7W3d9tBMLCTGqIPmwrIFV5s7rhyeaMIe+qTbsrEEWfPCmm3qIJEa2GLp/+ECR Bm9jz1+OVOrQww0B/RmQSWlI6UV9C8mSZkmVEx//ZTsuORKd0C+lvFRSKSGkPdnt1r8Z 3AAA== X-Gm-Message-State: AHPjjUinZfnC3OtA6kZpZSjMTp7CFCrBXqpz9cC7kAMaVZiJSehwBwcX SRrGr4IixIBdlpGePCXIiGgwmcfzPPMH4o0= X-Google-Smtp-Source: AOwi7QAq1jN6+kq5Ux8pGygHOagFs+DnzcSFjx1zMAcTKTjoFFvoMc6R35/ZXLIAOvUI87Jb3h9B5C3mT2/k/2G9cI0= X-Received: by 10.46.87.93 with SMTP id r29mr5631988ljd.44.1505189811010; Mon, 11 Sep 2017 21:16:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.198.209 with HTTP; Mon, 11 Sep 2017 21:16:50 -0700 (PDT) In-Reply-To: <38329242-F7E9-4D68-B9CF-460AE7D6CE07@verisign.com> References: <38329242-F7E9-4D68-B9CF-460AE7D6CE07@verisign.com> From: Mayank Bhatnagar Date: Tue, 12 Sep 2017 09:46:50 +0530 Message-ID: To: "Teague, Nik" Cc: dots@ietf.org Content-Type: multipart/alternative; boundary="f403045f864c01415e0558f650cb" Archived-At: Subject: Re: [Dots] Some queries and comments on DOTS requirements draft "draft-ietf-dots-requirements-06" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 12 Sep 2017 04:16:55 -0000 --f403045f864c01415e0558f650cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable hi Nik, thanks...I understand as you and Roland mentioned, "*preconditions, thresholds or triggers" is *dependent on many factors. thanks for your suggestion on the draft.... regards, Mayank On Sep 11, 2017 6:43 PM, "Teague, Nik" wrote: > Mayank hi, > > > > Please see inline - > > > > On 11/09/2017, 04:48, "Mayank Bhatnagar" > wrote: > > > > thanks Nik for your time and reading my queries and replying on to it. > > > > 1. As yu mentioned *"however, if the inbound links are congested then > maintaining tcp may be an issue and therefore udp is preferable."* > > > > Beacon signals will certainly help as you mentioned. > > > > Also, is there a mechanism to convey congestion and slip to UDP, while > maintaining TCP as a default signalling mechanism > > > > You could employ a =E2=80=9Chappy eyeballs=E2=80=9D like mechanism if you= prefer. This > has been called out a few times =E2=80=93 as far as doing so dynamically = as in > flipping from one to the other mid stream =E2=80=93 that seems excessivel= y complex. > > > > > > 2. *#2 preconditions, thresholds or triggers will depend upon the client > and the assets being protected. * > > So, do we plan to make a draft of possible conditions faced and beest > practices of thresholds maintined as a guideline...may be we can get this > as an additional section or annexure. Just a guideline and best preferabl= e > values, however dynamic conditions can determine the right metrics at tha= t > time.. > > > > I would agree with Roland=E2=80=99s comments that the breadth of the subj= ect is > situationally dependent upon a number of factors some of them related to > out of band topics such as business logic. The use cases draft alludes t= o > these at a high level. If you would like to see this kind subject > documented more deeply then you could certainly create a draft and submit > it to the working group. > > > > Thanks, > > > > -Nik > --f403045f864c01415e0558f650cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hi Nik,=
thanks...I understand as you and Roland me= ntioned, "preconditions, thresholds or triggers" =C2=A0is= =C2=A0dependent on many factors.
thanks= for your suggestion on the draft....

<= /div>
regards,
Ma= yank

<= br>
On Sep 11, 2017 6:43 PM, "Teague, Nik&qu= ot; <nteague@v= erisign.com> wrote:

Mayank hi,

=C2=A0

Please see inline -

=C2=A0

On 11/09/2017, 04:48, &qu= ot;Mayank Bhatnagar" <mayankbhatnagar1178@gmail.com> wrote:<= /u>

=C2=A0

thanks Nik for your = time and reading my queries and replying on to it.

=C2=A0

1. As yu mentioned=C2=A0"howe= ver, if the inbound links are congested then maintaining tcp may be an issu= e and therefore udp is preferable."

=C2=A0

Beacon signals will certainly help as= you mentioned.

=C2=A0

Also, is there a mechanism to convey = congestion and slip to UDP, while maintaining TCP as a default signalling m= echanism

=C2=A0

You could employ a =E2=80=9Chappy eyeballs=E2=80=9D like mechani= sm if you prefer.=C2=A0 This has been called out a few times =E2=80=93 as f= ar as doing so dynamically as in flipping from one to the other mid stream =E2=80=93 that seems excessively complex.<= /p>

=C2=A0

=C2=A0

2. =C2=A0#2 preconditions, thresho= lds or triggers will depend upon the client and the assets being protected.= =C2=A0

So, do we plan to make a draft of pos= sible conditions faced and beest practices of thresholds maintined as a gui= deline...may be we can get this as an additional section or annexure. Just a guideline and best preferable va= lues, however dynamic conditions can determine the right metrics at that ti= me..

=C2=A0

I would agree with Roland=E2=80=99s comments that the breadth of= the subject is situationally dependent upon a number of factors some of th= em related to out of band topics such as business logic.=C2=A0 The use cases draft alludes to these at a high level.=C2=A0 I= f you would like to see this kind subject documented more deeply then you c= ould certainly create a draft and submit it to the working group.=

=C2=A0

Thanks,

=C2=A0

-Nik

--f403045f864c01415e0558f650cb-- From nobody Thu Sep 14 03:46:26 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B8813292E for ; Thu, 14 Sep 2017 03:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiCvQ3Of0nSx for ; Thu, 14 Sep 2017 03:46:21 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB9F1321A7 for ; Thu, 14 Sep 2017 03:46:21 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dsRf0-0003Da-Fx for ietf-supjps-dots@ietf.org; Thu, 14 Sep 2017 11:46:18 +0100 From: "Jon Shallow" To: References: <070601d328ba$ffbbc440$ff334cc0$@jpshallow.com> In-Reply-To: <070601d328ba$ffbbc440$ff334cc0$@jpshallow.com> Date: Thu, 14 Sep 2017 11:46:19 +0100 Message-ID: <00a101d32d46$b2f30cf0$18d926d0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A2_01D32D4F.14B970C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJWDLbdGWgIliMeta88DlSb7Xyh66GuZ6CA Content-Language: en-gb Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 14 Sep 2017 10:46:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A2_01D32D4F.14B970C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, No responses to date. I have subsequently found that libcoap does properly support IPv6 - and have updated my previous questions / comments. I however have further signal channel questions / discrepancies from https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel Usage of PUT signal ================= Usage of "attack-status" ------------------------------- 5.3.1. PUT definition does not include '"attack-status": integer' 5.3.4. PUT definition is initially identical to 5.3.2, but includes '"attack-status": integer' and states that it is mandatory. If this parameter is mandatory, then it should be included in the 5.3.1 definition, or is it mandatory only if this is defining an Efficacy update? With the 5.3.4 version, would not just sending the "mitigation-id" and "attack-status" be sufficient? When refreshing with a 5.3.4 PUT, does this reset the lifetime expiry counter? PUT refresh --------------- When the PUT is refreshed by the client at some point before the lifetime expires, if the signal mitigate content (e.g. target-protocol is changed) is sent by the client, should this be allowed, ignored or rejected? COAP Response information ------------------------------------ There is reference to the server having the ability to update the lifetime in its response to the PUT (5.3.1). "The server MUST always indicate the actual lifetime in the response and the remaining lifetime in status messages sent to the client. This is an optional attribute in the request." However, nowhere else does it state what should be in the body of the response (if anything) for a PUT or DELETE. There are hints in the COAP RFC that suitable diagnostics can be added for failure response codes. Do we just echo back the request (with update lifetime possibly) for PUT? What body responses do we send back for a DELETE? Do the body responses need to be in CBOR (including diagnostic messages) ? CBOR Key Values mapping ====================== If a request comes into the server that does not use the CBOR mapping parameters (section 6), is this to be rejected? If the request is to be accepted, is the server response to always use CBOR mapping, or does the server have to reply without using the CBOR mapping? Scope ===== Scope has been defined as an array - presumably to allow multiple mitigation-ids to be returned in a response. However, if two or more mitigation-ids are used in a PUT - is this allowed? If there are 2 or more mitigation-ids, what does the response code refer to - especially if it would be different for the individual request mitigation-ids? -- I'm sure that more questions will come up as we continue to try to do an implementation of the signal channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 08 September 2017 16:56 To: dots@ietf.org Subject: [Dots] Coding and Interoperability Challenges Hi there, We are in the process of trying to code up a DOTS Client / Server implementation based on the draft standards so far and have come up with the following list of issues / questions. Nttdots ======= An excellent starting point, but CBOR ------- The nttdots server only accepts strings for the various parameters. It does not (yet) accept CBOR that uses the CBOR mapping parameters (draft-ietf-dots-signal-channel Section 6). Signal Channel ------------------- Nttdots is expecting an additional path parameter in the POST/PUT etc path (.wellknown), so instead of /v1/dots-signal/signal, it requires /.wellknown/v1/dots-signal/signal which is not stated anywhere in the draft-ietf-dots-signal-channel draft. If not present, it returns a 4.05 code. RFC6690 refers to "/.wellknown/core" as a default entry point for discovering what resources are available. RESTCONF rfc8040 refers to "/.wellknown/host-meta" to determine the RESTCONF root resource. Data channel ----------------- Data channel support uses CBOR / COAP, not RESTCONF (well actually it goes over the signal channel), but that is documented as a current limitation, but does need to be fixed. Libcoap ======= The currently available c libcoap library (develop branch) from https://github.com/obgm/libcoap only supports DTLS with PreSharedKeys, not Certificates. Work needs to be done with this library to support PKI as well as COAP over TLS (not yet an IETF standard) to support the signal channel requirements. Doing a hack to libcoap to force known PKI keys works when used against Nttdots, so there is potential here to use a fixed version of this library. RawPublicKey has not been tried out. Libcoap requires openssl 1.1.0 or TinyDTLS - GnuTLS support is not currently available. Red Hat/Centos distributions do not have openssl 1.1.0 - DTLS support is only version 1, not version 1.2 in their versions of openssl. The openssl libraries cannot be replaced in Red Hat/Centos - the 1.1.0 version has to be installed in addition to the existing openssl libraries. > Libcoap assumes that all IP addresses are IPv4 (see coap_address_t), even though there are some references to IPv6 elsewhere in the library. Not the case - Ipv6 is fully supported Default Values ============ There is a list of configurable parameters, but no suggested defaults. Signal Port - UDP ---------------------- COAP using DTLS default port is 5684 (RFC 7252), nttdots port is 4646. Should DOTS be going for / defining the same port as COAP? (https://tools.ietf.org/html/draft-mortensen-dots-over-udp-00 refers to 4646) Signal Port - TCP --------------------- This does not have to be the same as the UDP port, but looks like it is going to be 5684 as per draft-ietf-core-coap-tcp-tls. Should DOTS be going for / defining the same default port as COAP? Data Port ------------- RFC8040 - "2.2 HTTPS with X.509v3 Certificates" defines RESTCONF implementations MUST support the "https" URI scheme, which has the IANA-assigned default port 443 for "/.wellknown/host-meta". Data Port cannot easily be the same as the Signal Port (TCP) as new incoming connections are either COAP or RESTCONF and it may be difficult to differentiate. Port 443 may clash with other GUIs or applications running on port 443 on the same host as the DOTS server. However, the other GUI/applications may have to add in "/.wellknown/host-meta" to support replying that RESTCONF is running on another port. Is the Link 'restconf' definition sufficient, or de we need a link definition something like 'restconf-dots' added? What should the suggested default RESTCONF port be? >Mitigation Lifetime Global Mitigation Lifetime ------------------------ >This will be DOTS Server provider specific, but should be the order of days. Do we need to suggest a default lifetime? This is different to the lifetime refresh - I was thinking of a total mitigation lifetime slot as a chargeable unit when I wrote this, but this is really a DOTS Server domain controller decision. DOTS Client Restarts ================= The DOTS Client will need to re-synchronize with the DOTS Server to get the DOTS Server's current shared state (mitigation / filters etc) when it gets restarted or reconnected. Should this be stated? DOTS Server Restarts ================= The DOTS Server needs some way to signal to the DOTS client that it has restarted and that shared state needs to be re-synchronized. Should this be stated? ========================= Regards Jon ------=_NextPart_000_00A2_01D32D4F.14B970C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there,

 

No responses to = date.

 

I have subsequently = found that libcoap does properly support IPv6 – and have updated = my previous questions / comments.

 

I however have further = signal channel questions / discrepancies from = https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel

 

Usage of PUT = signal

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

 

Usage of = “attack-status”

-------------------------------=

5.3.1. PUT = definition does not include ‘“attack-status”: = integer’

5.3.4. PUT definition is initially identical to = 5.3.2, but includes ‘“attack-status”: integer’ = and states that it is mandatory.

 

If this parameter is = mandatory, then it should be included in the 5.3.1 definition, or is it = mandatory only if this is defining an Efficacy = update?

With the 5.3.4 version, would not just sending = the “mitigation-id” and “attack-status” be = sufficient?

 

When refreshing with a = 5.3.4 PUT, does this reset the lifetime expiry = counter?

 

PUT = refresh

---------------

When the PUT is = refreshed by the client at some point before the lifetime expires, if = the signal mitigate content (e.g. target-protocol is changed) is sent by = the client, should this be allowed, ignored or = rejected?

 

COAP Response = information

------------------------------------

There is = reference to the server having the ability to update the lifetime in its = response to the PUT (5.3.1).

 

“The server MUST = always indicate the actual lifetime in

      the response and = the remaining lifetime in status messages sent = to

      the client.  = This is an optional attribute in the = request.”

 

However, nowhere else = does it state what should be in the body of the  response (if = anything) for a PUT or DELETE.  There are hints in the COAP RFC = that suitable diagnostics can be added for failure response = codes.

Do we just echo back the request (with update = lifetime possibly) for PUT?

What body responses do = we send back for a DELETE?

 

Do the body responses = need to be in CBOR (including diagnostic messages) = ?

 

CBOR Key Values = mapping

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

If a request comes into = the server that does not use the CBOR mapping parameters (section 6), is = this to be rejected?

If the request is to be accepted, is the server = response to always use CBOR mapping, or does the server have  to = reply without using the CBOR mapping?

 

Scope

=3D=3D=3D=3D=3D

 

Scope has been defined = as an array – presumably to allow multiple mitigation-ids to be = returned in a response.

 

However, if two or more = mitigation-ids are used in a PUT - is this = allowed?

If there are 2 or more mitigation-ids, what does = the response code refer to – especially if it would be different = for the individual request mitigation-ids?

 

--

I’m sure that more = questions will come up as we continue to try to do an implementation of = the signal channel.

 

Regards

 

Jon

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Jon Shallow
Sent: 08 September 2017 16:56
To: = dots@ietf.org
Subject: [Dots] Coding and Interoperability = Challenges

 

Hi = there,

 

We are in the process of trying to code up a DOTS = Client / Server implementation based on the draft standards so far and = have come up with the following list of issues / = questions.

 

Nttdots

=3D=3D=3D=3D=3D=3D=3D

 

An excellent = starting point, but

 

CBOR

-------

 

The nttdots = server only accepts strings for the various parameters.  It does = not (yet) accept CBOR that uses the CBOR mapping parameters = (draft-ietf-dots-signal-channel Section 6).

 

Signal = Channel

-------------------

 

Nttdots is = expecting an additional path parameter in the POST/PUT etc path = (.wellknown), so instead of /v1/dots-signal/signal, it requires = /.wellknown/v1/dots-signal/signal which is not stated anywhere in the = draft-ietf-dots-signal-channel draft.  If not present, it returns a = 4.05 code.

RFC6690 refers to =  “/.wellknown/core” as a default entry point for = discovering what resources are available.

RESTCONF rfc8040 refers to = “/.wellknown/host-meta” to determine the RESTCONF root = resource.

 

Data channel

-----------------

 

Data channel = support uses CBOR / COAP, not RESTCONF (well actually it goes over the = signal channel), but that is documented as a current limitation, but = does need to be fixed.

 

Libcoap

=3D=3D=3D=3D=3D=3D=3D

 

The = currently available c libcoap library (develop branch) from https://github.com/obgm/libcoap<= /a> only supports DTLS with PreSharedKeys, not Certificates.  Work = needs to be done with this library to support PKI as well as COAP over = TLS (not yet an IETF standard) to support the signal channel = requirements.

 

Doing a hack to libcoap to force known PKI keys works = when used against Nttdots, so there is potential here to use a fixed = version of this library.

 

RawPublicKey = has not been tried out.

 

Libcoap = requires openssl 1.1.0 or TinyDTLS – GnuTLS support is not = currently available.  Red Hat/Centos distributions do not have = openssl 1.1.0 – DTLS support is only version 1, not version 1.2 in = their versions of openssl.  The openssl libraries cannot be = replaced in Red Hat/Centos – the 1.1.0 version has to be installed = in addition to the existing openssl libraries.

 

> Libcoap assumes that all IP = addresses are IPv4 (see coap_address_t), even though there are some = references to IPv6 elsewhere in the library.

Not the case – Ipv6 is fully = supported

 

Default = Values

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

There is a = list of configurable parameters, but no suggested = defaults.

 

Signal Port – UDP

----------------------

 

COAP using = DTLS default port is 5684 (RFC 7252), nttdots port is 4646.  Should = DOTS be going for / defining the same port as COAP?

(htt= ps://tools.ietf.org/html/draft-mortensen-dots-over-udp-00 refers to = 4646)

 

Signal Port – TCP

---------------------

 

This does = not have to be the same as the UDP port, but looks like it is going to = be 5684 as per draft-ietf-core-coap-tcp-tls.  Should DOTS be going = for / defining the same default port as COAP?

 

Data = Port

-------------

 

RFC8040 – “2.2 HTTPS with = X.509v3 Certificates” defines RESTCONF = implementations MUST support the "https" URI scheme, which = has the = IANA-assigned default port 443 for = “/.wellknown/host-meta”.

 

Data Port cannot = easily be the same as the Signal Port (TCP) as new incoming connections = are either COAP or RESTCONF and it may be difficult to = differentiate.

 

Port 443 may clash = with other GUIs or applications running on port 443 on the same host as = the DOTS server.  However, the other GUI/applications may have to = add in “/.wellknown/host-meta” to support replying that = RESTCONF is running on another port.  Is the Link = ‘restconf’ definition sufficient, or de we need a link = definition something like ‘restconf-dots’ = added?

 

What should the = suggested default RESTCONF port be?

 

>Mitigation Lifetime

Global Mitigation = Lifetime

------------------------

 

>This will be DOTS Server provider = specific, but should be the order of days.  Do we need to suggest a = default lifetime?

This is different to the = lifetime refresh – I was thinking of a total mitigation lifetime = slot as a chargeable unit when I wrote this, but this is really a DOTS = Server domain controller decision.

 

DOTS Client = Restarts

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

The DOTS Client will need to re-synchronize with the = DOTS Server to get the DOTS Server’s current shared state = (mitigation / filters etc) when it gets restarted or reconnected.  = Should this be stated?

 

DOTS Server = Restarts

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

The DOTS Server needs some way to signal to the DOTS = client that it has restarted and that shared state needs to be = re-synchronized.  Should this be stated?

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

 

Regards

 

Jon

------=_NextPart_000_00A2_01D32D4F.14B970C0-- From nobody Thu Sep 14 05:22:23 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6175B132355 for ; Thu, 14 Sep 2017 05:22:21 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09lXfrKJQKuM for ; Thu, 14 Sep 2017 05:22:15 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F31F3120720 for ; Thu, 14 Sep 2017 05:22:14 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v8ECMDxW000502 for ; Thu, 14 Sep 2017 08:22:13 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu v8ECMDxW000502 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1505391733; bh=hjJD7b2zPG6U/ihb6ju5UjGlDMeNgfAmubizd9rMh88=; h=From:To:Subject:Date:From; b=VZ7pdJX4y3A1zuJR/NSiVDPCZSBti79o2OxtDz/Rh8DIAYs9aEE7kJ188LwAe6SdP XLDR/SF+SA4fTQmdMuNGVL1wWdrwYw4v9m5MjREm+dCYfpOK0XB4egZQ0TiegXH8+I RXDnsgmIFOETuGoomXbzWfxJKdP7rNXFtq8Etnw8= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v8ECM6Sr013302 for ; Thu, 14 Sep 2017 08:22:06 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0351.000; Thu, 14 Sep 2017 08:22:05 -0400 From: Roman Danyliw To: "'dots@ietf.org'" Thread-Topic: Reminder -- October 2017 Virtual Interim Meeting Scheduling Poll Thread-Index: AdMtU/7oDX0cF1VtQ0Clm3/6EA70sg== Date: Thu, 14 Sep 2017 12:22:05 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104FC92A1@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Reminder -- October 2017 Virtual Interim Meeting Scheduling Poll X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 14 Sep 2017 12:22:21 -0000 -----Original Message----- From: Roman Danyliw=20 Sent: Thursday, September 07, 2017 1:36 PM To: 'dots@ietf.org' Subject: October 2017 Virtual Interim Meeting Scheduling Poll Hello WG! We're approaching the half-way point between the Prague and upcoming Singap= ore meeting and would benefit from synchronizing with a virtual interim mee= ting. The proposed agenda would be a subset of the following: ** Hackathon participation ** Use Cases, Requirements and Architecture drafts ** Signal and Data channel drafts Help suggest the best day to virtual meet during the week of October 2nd by= completing a Doodle poll -- https://doodle.com/poll/65anbcr64ny95cm3. Your input would be appreciated by Thursday, September 14, 2017 and results= will be announced on Friday, September 15, 2017. Regards, Roman From nobody Mon Sep 18 05:48:58 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7A4129A89 for ; Mon, 18 Sep 2017 05:48:57 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3Pv69Dgrqyu for ; Mon, 18 Sep 2017 05:48:55 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B867124F57 for ; Mon, 18 Sep 2017 05:48:55 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v8ICms8g013355 for ; Mon, 18 Sep 2017 08:48:54 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu v8ICms8g013355 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1505738934; bh=CW0SK6uKJ+VeZPPfIYj0656BxFBQ1esVYwdQHjW1giU=; h=From:To:Subject:Date:From; b=O1db97lr8+Za7LlhVuY35zejJi38059cJukusl4Jc9XqARo7GnMHunXu6nRyozVwt iK1sFDvEuBQd/L060ldovJHhSOhAIGfIib+k73lShYxJ4+Mjju1Irk7EDYyXnxJGAZ uL4bsh+c7kiMoLRb04LKAAHqMyz1/KPqheaUGpvw= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v8ICmqx4003568 for ; Mon, 18 Sep 2017 08:48:52 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0351.000; Mon, 18 Sep 2017 08:48:51 -0400 From: Roman Danyliw To: "'dots@ietf.org'" Thread-Topic: Virtual Interim Meeting: Monday, October 2, 2017 Thread-Index: AdMwerk8ahPnbEM3TVGSgheIqAT+/g== Date: Mon, 18 Sep 2017 12:48:51 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104FCB773@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/mixed; boundary="_002_359EC4B99E040048A7131E0F4E113AFC0104FCB773marathon_" MIME-Version: 1.0 Archived-At: Subject: [Dots] Virtual Interim Meeting: Monday, October 2, 2017 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 18 Sep 2017 12:48:57 -0000 --_002_359EC4B99E040048A7131E0F4E113AFC0104FCB773marathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello WG! Based on the scheduling poll, a DOTS virtual interim meeting has been sched= uled for Monday, October 2, 2017 from 14:00 - 15:30 UTC Please send any requests for time on the agenda to the chairs. =3D=3D[ Date/Time ]=3D=3D Monday, October 2, 2017 14:00 - 15:30 UTC Start time in select local time zones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D San Francisco, USA -- June 8, 2017 at 7:00:00 am=20 New York, USA -- June 8, 2017 at 10:00:00 am=20 UTC (GMT) -- June 8, 2017 at 2:00:00 pm =20 London, UK -- June 8, 2017 at 3:00:00 pm =20 Berlin, Germany -- June 8, 2017 at 4:00:00 pm=20 New Delhi, India -- June 8, 2017 at 7:30:00 pm=20 Bangkok, Thailand -- June 8, 2017 at 9:00:00 pm=20 Beijing, China -- June 8, 2017 at 10:00:00 pm =3D=3D[ Working Agenda ]=3D=3D (Please send any requests for time on the agenda to the chairs) 1. Note well, logistics and introduction=20 2. Use Cases=20 3. Requirements=20 4. Architecture=20 5. Implementation Experience 6. Protocols=20 7. Closing =3D=3D[ WebEx Information ]=3D=3D Meeting URL: https://ietf.webex.com/ietf/j.php?MTID=3Dm41f6db21f48c1e8462aecfcc768b02f9 Meeting number: 640 514 336 Meeting password: P9m9Ba8M =20 Dial-in Numbers: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 640 514 336 =3D=3D=3D=3D Roman --_002_359EC4B99E040048A7131E0F4E113AFC0104FCB773marathon_ Content-Type: text/calendar; name="DOTS-2017-10-Virtual-Interim-WebEx_Meeting.ics" Content-Description: DOTS-2017-10-Virtual-Interim-WebEx_Meeting.ics Content-Disposition: attachment; filename="DOTS-2017-10-Virtual-Interim-WebEx_Meeting.ics"; size=3726; creation-date="Mon, 18 Sep 2017 12:45:04 GMT"; modification-date="Mon, 18 Sep 2017 12:45:06 GMT" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDE1MTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE1MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSJERG9TIE9wZW4gVGhy ZWF0IFNpZ25hbGluZyBXb3JraW5nIEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPUZB TFNFOk1BSUxUTzpkb3RzLWNoYWlyc0BpZXRmLm9yZwpPUkdBTklaRVI7Q049IndlYmV4IjpNQUlM VE86bWVzc2VuZ2VyQHdlYmV4LmNvbQpEVFNUQVJUO1RaSUQ9IkVhc3Rlcm4gVGltZSI6MjAxNzEw MDJUMTAwMDAwCkRURU5EO1RaSUQ9IkVhc3Rlcm4gVGltZSI6MjAxNzEwMDJUMTEzMDAwCkxPQ0FU SU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0ZgpUUkFOU1A6T1BBUVVFClNFUVVFTkNFOjE1 MDU3Mzg3MDMKVUlEOjkyMGE4YWUwLWUzOTYtNDkwOC1iM2Y2LTE5MWE5YjMxY2M3ZQpEVFNUQU1Q OjIwMTcxMDAyVDE0MDAwMFoKREVTQ1JJUFRJT046XG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWM3MTc0MDE1MDcyNzQ3NmJmZTEz YjViYjdhZTNlNDVhXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDAgNTE0IDMzNlxu SG9zdCBrZXk6IDUxMTczMFxuTWVldGluZyBwYXNzd29yZDogUDltOUJhOE1cblxuXG5cbkpPSU4g QlkgUEhPTkVcbjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2Fu YWRhKSBcbjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblxu VG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiBcbmh0dHBzOi8vd3d3LndlYmV4LmNvbS9w ZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGlu Zz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWNc blxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2Vydmlj ZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNz aW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwg bWF0dGVyLiBZb3Ugc2hvdWxkIGluZm9ybSBhbGwgbWVldGluZyBhdHRlbmRlZXMgcHJpb3IgdG8g cmVjb3JkaW5nIGlmIHlvdSBpbnRlbmQgdG8gcmVjb3JkIHRoZSBtZWV0aW5nLlxuClgtQUxULURF U0M7Rk1UVFlQRT10ZXh0L2h0bWw6CTxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj48Rk9OVCBT SVpFPSI0IiBGQUNFPSJBUklBTCI+CQk8YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2ll dGYvai5waHA/TVRJRD1tYzcxNzQwMTUwNzI3NDc2YmZlMTNiNWJiN2FlM2U0NWEiPjxGT05UIFNJ WkU9IjMiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlhbCI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9G T05UPjwvYT4JCQk8dGFibGU+CQkJCTx0cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6 IDY0MCA1MTQgMzM2PC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxlPgkJCTx0YWJs ZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+SG9zdCBrZXk6IDUxMTczMDwvRk9OVD4JCQkJCTwvdGQ+CQkJCTwvdHI+CQkJ PC90YWJsZT4JCQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9 IjIiICBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPlA5bTlCYThNPC9GT05UPjwvdGQ+PC90 cj48L3RhYmxlPgkJPC9GT05UPjxicj48Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCI+PC9G T05UPjxicj48Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48 L0ZPTlQ+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4mbmJzcDsgPEJSPjxGT05U IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4xLTg3Ny02Njgt NDQ5Mzwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwv Rk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlh bCI+PHN0cm9uZz4xLTY1MC00NzktMzIwODwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48YSBocmVmPSJodHRwczovL3d3dy53ZWJl eC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYiPjxGT05UIFNJWkU9IjEiIENPTE9S PSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9G T05UPjwvYT4gJm5ic3A7IDxCUj48L0ZPTlQ+PEJSPjxCUj4JJm5ic3A7PEJSPgk8Rk9OVCBTSVpF PSIxIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPgkJCQlDYW4ndCBqb2luIHRoZSBtZWV0 aW5nPzwvRk9OVD4JPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jIj4JPEZP TlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Db250YWN0IHN1cHBvcnQu PC9GT05UPjwvYT4JJm5ic3A7PEJSPiZuYnNwOzxCUj48Rk9OVCBDT0xPUj0iI0EwQTBBMCIgc2l6 ZT0iMSIgRkFDRT0iYXJpYWwiPklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhp cyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBk dXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFi bGUgaW4gYSBsZWdhbCBtYXR0ZXIuIFlvdSBzaG91bGQgaW5mb3JtIGFsbCBtZWV0aW5nIGF0dGVu ZGVlcyBwcmlvciB0byByZWNvcmRpbmcgaWYgeW91IGludGVuZCB0byByZWNvcmQgdGhlIG1lZXRp bmcuPC9GT05UPjwvRk9OVD4KU1VNTUFSWTpET1RTIFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nLCBP Y3RvYmVyIDIwMTcKUFJJT1JJVFk6NQpDTEFTUzpQVUJMSUMKQkVHSU46VkFMQVJNClRSSUdHRVI6 LVBUNU0KQUNUSU9OOkRJU1BMQVkKREVTQ1JJUFRJT046UmVtaW5kZXIKRU5EOlZBTEFSTQpFTkQ6 VkVWRU5UCkVORDpWQ0FMRU5EQVIK --_002_359EC4B99E040048A7131E0F4E113AFC0104FCB773marathon_-- From nobody Mon Sep 18 07:17:36 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AE3132D18; Mon, 18 Sep 2017 07:17:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150574424991.15603.1715428960065662830@ietfa.amsl.com> Date: Mon, 18 Sep 2017 07:17:30 -0700 Archived-At: Subject: [Dots] DDoS Open Threat Signaling (dots) WG Virtual Meeting: 2017-10-02 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 18 Sep 2017 14:17:30 -0000 The DDoS Open Threat Signaling (dots) Working Group will hold a virtual interim meeting on 2017-10-02 from 10:00 to 11:30 America/New_York. Agenda: 1. Note well, logistics and introduction 2. Use Cases 3. Requirements 4. Architecture 5. Implementation Experience 6. Protocols 7. Closing Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m8a8ec14680d776a1d4a1c8cf7272ab75 https://www.ietf.org/mail-archive/web/dots/current/msg01409.html From nobody Tue Sep 26 04:07:14 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59857133023 for ; Tue, 26 Sep 2017 04:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se2B4307L8he for ; Tue, 26 Sep 2017 04:07:06 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9EE1133020 for ; Tue, 26 Sep 2017 04:07:05 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dwnhe-0003Wz-Vb for ietf-supjps-dots@ietf.org; Tue, 26 Sep 2017 12:07:03 +0100 From: "Jon Shallow" To: Date: Tue, 26 Sep 2017 12:07:05 +0100 Message-ID: <062f01d336b7$966e9160$c34bb420$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQJWDLbdGWgIliMeta88DlSb7Xyh6wERxjbqobjAfoCAAAa5EA== Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 26 Sep 2017 11:07:10 -0000 Hi there, I now have implemented a working DOTS Server supporting the signal channel over UDP and is CoAP TCP ready. The data channel work has still to be done. The DOTS Client is still a work in progress, but was used to test the DOTS server. This however has highlighted some vague, open to interpretation, definitions in the signal spec draft-ietf-dots-signal-channel-03, several of which I have previously raised. If there is insufficient time to address the issues before the virtual meeting on 2nd October, then it may make sense to discuss them at that meeting. Given the interrelation of the draft IETF dots documents, other RFCs, there is a reasonable chance that I may have misinterpreted something, or not realised as consequence of what needs to be done. The following is not in order of importance - it is following the signal specification order. Instead of getting bogged down in a section, skip it and read the other sections and come back to the one you are having trouble with - the wider context may help you. In particular, Sections covering 5.1 may need to be initially skipped. draft-ietf-dots-signal-channel-03 ================================= 5.1 Overview (1) ============= In general, what should be in, or could be expected in the response is not that clear. This should be tightened up - this section 5.1 with a new penultimate paragraph at the end of this section may be a good place. The following comments / descriptions in this section highlight some areas that have raised concerns. Original: (End of section 5.3.1) "For responses indicating a client or server error, the payload explains the error situation of the result of the requested action (Section 5.5 in [RFC7252])." [RFC 7572 5.5 Payloads and Representations Both requests and responses may include a payload, depending on the Method or Response Code, respectively. If a Method or Response Code is not defined to have a payload, then a sender MUST NOT include one, and a recipient MUST ignore it.] If the response is not 2.xx, is the diagnostic message that is sent back a CoAp Diagnostic Message with no content format and a simple plain-text message (RFC 5.5.2 Diagnostic Payload)? If so, what happens with the 4.22 (Unprocessable Entity) response in 5.4.1 which states the acceptable values - which are encoded in CBOR? - I think this should be a Diagnostic Payload response (perhaps with the bad value), thus inviting the DOTS Client to (re-)do a GET Request to discover the valid values. - It is also not possible to determine which is the value that has failed with just the current defined payload response - whereas a Diagnostic message can give a hint as to the failing value. In 5.3.1, the only thing mentioned for a successful PUT response is the "lifetime" parameter is required. It is unclear whether the rest of the parameter/values that were part of the PUT request should also be in the response. What should be returned? Suggested update to 5.1 to handle "RFC 7572 5.5 Payloads and Representations" sandwiched between 2 Originals to set the context:- Original: ". Mitigation remains active until the DOTS client explicitly terminates mitigation, or the mitigation lifetime expires." New Addition: "The following CoAP requests and responses MUST be supported by the DOTS agents. +------------+-------------+ |Method Code |Usage | +------------+-------------+ |0.00 |Heartbeat | |0.01 |GET | |0.03 |PUT | |0.04 |DELETE | +------------+-------------+ Figure XXX: Supported CoAP Method Codes" All CoAP responses with codes that are 2.xx MUST have a CoAP payload, content type "application/cbor" that is a "resource representation" [RFC7252 5.5.1 Representation]. All CoAP responses with codes that are not 2.xx MUST be a Diagnostic Payload [RFC7252 5.5.2 Diagnostic Payload] with no content type. The Diagnostic Payload can contain additional information to aid troubleshooting. +-------------+---------------------+----------+-------+ |Response Code|Usage |Diagnostic|Payload| +-------------+---------------------+----------+-------+ |2.01 |Created |No |Yes | |2.02 |Deleted |No |Yes | |2.04 |Changed |No |Yes | |2.05 |Content |No |Yes | |3.00 |Alternative Server |No |Yes | |4.00 |Bad Request |Yes |No | |4.01 |Unauthorized |Yes |No | |4.02 |Invalid Query |Yes |No | |4.04 |Not Found |Yes |No | |4.22 |Unprocessable Entity |Yes |No | |5.00 |Internal Server Error|Yes |No | |5.02 |Bad Gateway |Yes |No | |5.03 |Service Unavailable |Yes |No | |5.04 |Gateway Timeout |Yes |No | +-------------+---------------------+----------+-------+ Figure XXX: Supported CoAP response Codes " Original: "Messages exchanged between DOTS client and server are serialized ..." 5.1 Overview (2) ============= Nowhere is mentioned what ports should be used. RFC7252 suggest a default of 5684/udp for CoAP DTLS. draft-ietf-core-coap-tcp-tls suggests 5684/tcp. Should this be stated? 5.1 Overview (3) ============= No mention is made of doing any signal channel recovery if a DOTS agent restarts for any reason. Things potentially could get out of sync unless there is some functionality to make sure that information held by each DOTS agent is properly synchronized (even if it a simple "flush out all that you know"). 5.3.1 Requesting Mitigation =========================== Original: ". The relative order of two mitigation requests from a DOTS client is determined by comparing their respective mitigation-id values. If two mitigation requests have overlapping mitigation scopes the mitigation request with higher numeric mitigation-id value will override the mitigation request with a lower numeric mitigation-id value." This raises several implementation questions. Question 1 ---------- Say a PUT mitigation-id with a value of #99 is followed by a PUT mitigation-id of #100 which overlaps, so #99 is ignored/overridden. Then there is a DELETE #100. Do we revert back to #99? If yes, then do we need to remember #1 through #98 to revert back to them if needed - the logical extension of this is remembering all 2^31 entries - which probably is a DOS attack. My suggestion would be that #99 is dropped/deleted if #100 overlaps, and the subsequent deleting #100 withdraws that particular mitigation and so mitigation stops. The new wording could be:- Replacement: "The relative order of two mitigation requests from a DOTS client is determined by comparing their respective mitigation-id values. If two mitigation requests have overlapping mitigation scopes the mitigation request with higher numeric mitigation-id value will override the mitigation request with a lower numeric mitigation-id value. The overlapped lower numeric mitigation-id is automatically deleted and no longer available for querying against." Question 2 ---------- It is unclear as to how this overlapping works, say with #99 target-ip [1.1.1.1,1.1.1.2] and #100 target-ip [1.1.1.2,1.1.1.3]. Is it correct that 1.1.1.1 should no longer be mitigated, but 1.1.1.3 should start? What about overlapping protocols, but not overlapping target-ips etc? Question 3 ---------- If there is an overlap, why cannot both mitigation scopes (both lower and higher mitigation-ids) still continue? Question 4 ---------- Handling mitigation request refreshes. When the lifetime expires with the active mitigation-id, the mitigation stops unless there is a refreshed mitigation request of some sort. Does the refresh mitigation request to keep the mitigation going use the same mitigation-id, or must it be a new (incremented?) mitigation-id? If the refresh requires a new incremented id, then this will wrap at some point and the "mitigation request with higher numeric mitigation-id value will override" test will fail. Original: "If the DOTS server finds the mitigation-id parameter value conveyed in the PUT request in its configuration data then the server MAY update the mitigation request, and a 2.04 (Changed) response is returned to indicate a successful update of the mitigation request." This implies the same mitigation-id is used for doing the refresh. My suggestion is to add in a new paragraph at the end of section 5.3.1 for clarity. New: "For mitigation to continue beyond the initial negotiated "lifetime", the DOTS client will need to refresh the current mitigation request by sending a new PUT request. The PUT request SHOULD use the same "mitigation-id", and SHOULD repeat all the other parameters as sent in the original mitigation request apart from a possible change to the "lifetime" parameter. The DOTS server MAY refuse the refresh request if any of the request parameters (apart from "lifetime") have changed." Question 5 ---------- When the PUT is refreshed with the same mitigation-id by the client at some point before the lifetime expires, if the signal mitigate content (e.g. target-protocol is changed) is sent by the client, should this be allowed, ignored or rejected? My suggestion is in the "New:" update under Question 4 just above. Question 6 ---------- As Scope has been defined as an array, are multiple mitigation-ids allowed with a single PUT request? - I think only one should be allowed. The replacement is for the mitigation-id definition - the addition is at the end. Replacement: "mitigation-id: Identifier for the mitigation request represented using an integer. This identifier MUST be unique for each mitigation request bound to the DOTS client, i.e., the mitigation-id parameter value in the mitigation request needs to be unique relative to the mitigation-id parameter values of active mitigation requests conveyed from the DOTS client to the DOTS server. This identifier MUST be generated by the DOTS client. This document does not make any assumption about how this identifier is generated. This is a mandatory attribute. There can only be one mitigation-id request per Scope per single PUT request." 5.3.2 Withdraw a DOTS Signal ============================ Can multiple mitigation-ids be sent in a single DELETE request (scope is an array)? What gets sent back in the payload? If the mitigation-id found, then that can easily be the mitigation-id information. If not found, is there no payload, or should there be an empty scope array something like { "mitigation-scope": { "scope": [ ] } } We need to define what the client will expect (especially if it is going to make a decision on a 2.02 response for a non-existent mitigation-id). My suggestion is to add in a new paragraph at the end of this section. New: "Multiple mitigation-ids MAY be included in the DELETE "scope". The "resource representation" response payload always includes "mitigation-scope" and "scope" with zero or more mitigation-ids that were found and deleted. If the DELETE is repeated for one or more mitigation-ids during the active-but-terminating period, then the matching mitigation-ids continue to get returned." 5.3.3 Retrieving a DOTS Signal (1) ============================== When/what to send back an unsolicited response when running with an Observe. Some questions that need to be answered. When "observe" is set to 0, should the DOTS server send back an unsolicited information / status update a) whenever there is a "status" parameter change b) when there is a change to one of the "*-dropped" parameters c) send a response at some regular time interval? - Figure 10 implies it is just on a "status" parameter change. If at a regular interval (c), should this be a configurable value (as per configuration under 5.4?) or a defined fixed value? What should the recommended frequency of update be (1 per n seconds")? If Observe is not used to set up a regular frequency update, and therefore it is the responsibility of the DOTS client to poll as required (perhaps for graphing the data), should the DOTS Client set the Observe option (which will set up/cancel either (a) or (b) above) when polling? -If Observe is set to 1 during the polling, then it will cancel any notifications set up. Is Observe a MUST with a signal GET? - All examples have this Observe option included in Figure 10 I think that adding in an extra parameter "refresh-rate" would help here if there is to be a continuous refresh of information. However, this would only work for the explicit "mitigation-id" request. Alternatively, the generic request (no payload) could be replaced with one where the mitigation-id is -1 (following the same usage as the challenges over using the GET configuration signal-id in 5.4.1). Thoughts? 5.3.3 Retrieving a DOTS Signal (2) ============================== There is inconsistency in the definition of the "mitigation-scope" parameter - it is either an object/map or an array (for the responses back from the GET with no payload). The usage needs to be consistent throughout the specification to avoid errors creeping in. As "scope" is an array, then the multiple responses should be:- Replacement: " { "mitigation-scope":{ "scope": [ { "mitigation-id": 12332, "target-protocol": [ 17 ], "lifetime":1801, "status":2, "bytes-dropped": 134334555, "bps-dropped": 43344, "pkts-dropped": 333334444, "pps-dropped": 432432 }, { "mitigation-id": 12333, "target-protocol": [ 6 ], "lifetime":1749, "status":3, "bytes-dropped": 0, "bps-dropped": 0, "pkts-dropped": 0, "pps-dropped": 0 } ] } } " 5.3.3 Retrieving a DOTS Signal (3) ============================== "bytes-dropped" and "pkts-dropped". Are these counters from the start of the original initial PUT mitigate requests, or are these reset to 0 whenever there is a PUT mitigate refresh? My inclination is to go with the count from the initial PUT mitigate request (with a potential wrap around for long mitigations). It is possible that a DOTS client may have been restarted, but the mitigation request continues for the remainder of the lifetime Replacement: "bytes-dropped: The total dropped byte count for the mitigation request since the mitigation was initially requested. This is an optional attribute. bps-dropped: The average dropped bytes per second for the mitigation request. This is an optional attribute. pkts-dropped: The total dropped packet count for the mitigation request since the mitigation was initially requested. This is an optional attribute. pps-dropped: The average dropped packets per second for the mitigation request. This is an optional attribute." 5.3.3 Retrieving a DOTS Signal (4) ============================== The "lifetime" returned value is not defined in the mitigation status parameters. Is this the remaining time (in seconds?) of the current mitigation request? Replacement: "The mitigation status parameters are described below. lifetime: The remaining lifetime in seconds of the current mitigation-id request. bytes-dropped: The total dropped byte count.." 5.3.4 Efficacy Update from DOTS Client (1) -------------------------------------- Original: "The PUT request MUST include all the parameters used in the PUT request to convey the DOTS signal (Section 5.3.1)." This also implicitly implies that this must be done in 5.3.1 as well. What is the DOTS server supposed to do if any of the parameters (apart from perhaps "lifetime") are different - does this invoke a 4.02? The same question is true for 5.3.1. Replacement: "While DDoS mitigation is active, a DOTS client MAY frequently transmit DOTS mitigation efficacy updates to the relevant DOTS server. An PUT request (Figure 11) is used to convey the mitigation efficacy update to the DOTS server. The PUT request MUST include all the parameters used in the PUT request to convey the DOTS signal (Section 5.3.1) unchanged apart from "lifetime". The DOTS server MUST reject the request with a 4.02 code if this is not the case. The If-Match Option (Section 5.10.8.1 of [RFC7252]) with an empty value is used to make the PUT request conditional on the current existence of a mitigation request with the same mitigation-id. If UDP is used as ... 5.3.4 Efficacy Update from DOTS Client (2) -------------------------------------- Original:" The 5.xx response codes are returned if the DOTS server has erred or is incapable of performing the mitigation." Should there be any definitions of what 5.xx code should be used where? 5.3.4 Efficacy Update from DOTS Client (3) -------------------------------------- Does a PUT with "attack-status" refresh the outstanding lifetime on the current mitigation request? Or is the "lifetime" parameter optional, despite the MUST statement at the beginning of this session "The PUT request MUST include all the parameters used in the PUT request to convey the DOTS signal (Section 5.3.1)."? For clarity, I think the following should be added in as a paragraph at the end of this section:- New: "The current mitigation does not have the lifetime refreshed when using a Efficacy Update PUT as per section 5.3.4, but does have the lifetime refreshed when using a Mitigation Request PUT as per section 5.3.1." 5.4 DOTS Signal Channel Session Configuration --------------------------------------------- Original:" a. Heartbeat timeout: DOTS agents regularly send heartbeats (Ping/ Pong) to each other after mutual authentication in order to keep the DOTS signal channel open, heartbeat timeout is the time to wait for a Pong in milliseconds." Nowhere is the frequency defined for "regular send" and should this also be configurable in 5.4.1? 5.4.1 Discover Acceptable Configuration Parameters (1) -------------------------------------------------- Original: "A GET request is used to obtain acceptable configuration parameters on the DOTS server for DOTS signal channel session configuration." So, when making a configuration change, is this specific to the Signal Channel between the DOTS Server and DOTS client, or is it specific to each CoAP session where potentially there could be multiple sessions for the same signal channel? Replacement: ""A GET request is used to obtain acceptable configuration parameters on the DOTS server for current session using the DOTS signal channel." 5.4.1 Discover Acceptable Configuration Parameters (2) -------------------------------------------------- Figure 13. Does it also make sense to return Default values as well? - It may make sense for these to be Current as opposed to Default values. Replacement: "Content-Format: "application/cbor" { "heartbeat-timeout": {"MinValue": integer, "MaxValue" : integer,"DefaultValue":integer}, "max-retransmit": {"MinValue": integer, "MaxValue" : integer,"DefaultValue":integer }, "ack-timeout": {"MinValue": integer, "MaxValue" : integer,"DefaultValue":integer }, "ack-random-factor": {"MinValue": number, "MaxValue" : number,"DefaultValue":integer } } 5.4.2. Convey DOTS Signal Channel Session Configuration (1) -------------------------------------------------- Original: "The RECOMMENDED values of transmission parameter values are ack_timeout (2 seconds), max-retransmit (7), ack-random-factor (1.5) and heartbeat-timeout (371 seconds)." RFC7252 has max-retransmit set to 4, not 7. (RFC 7252 4.8 Transmission Parameters). With the exponential back off for retries of CON messages, using 4 gives an expiration of the request after about 1.5 minutes, with a value of 7 this is almost 10 minutes. The 10 minutes does seem excessively long to me - especially when it is for a CON Heartbeat. Unless there is a good reason for 7, I suggest we go with the RFC7572 recommendations of 4. Replacement: "The RECOMMENDED values of transmission parameter values are ack_timeout (2 seconds), max-retransmit (4), ack-random-factor (1.5) and heartbeat-timeout (371 seconds)." Replacement: " Header: PUT (Code=0.03) Uri-Host: "www.example.com" Uri-Path: "v1" Uri-Path: "dots-signal" Uri-Path: "config" Content-Format: "application/cbor" { "signal-config": { "session-id": 1234534333242, "heartbeat-timeout": 30000, "max-retransmit": 4, "ack-timeout": 5, "ack-random-factor": 1.5, "trigger-mitigation": false } } " 5.4.2. Convey DOTS Signal Channel Session Configuration (2) -------------------------------------------------- Original: The PUT request with higher numeric session-id value over-rides the DOTS signal channel session configuration data installed by a PUT request with a lower numeric session-id value." Say a PUT session-id with a value of #99 is followed by a PUT session-id of #100 which overlaps, so #99 is ignored. Then there is a DELETE #100. Do we revert back to #99? If yes, then do we need to remember #1 through #98 to revert back to them if needed - the logical extension of this is remembering all 2^31 entries - which probably is a DOS attack. My suggestion would be that #99 is dropped if #100 overlaps, and deleting #100 deletes that particular session-id. The new wording would be:- Replacement:" The PUT request with higher numeric session-id value over-rides the DOTS signal channel session configuration data installed by a PUT request with a lower numeric session-id value. The overlapped lower numeric session-id is automatically deleted and no longer available for querying against.". Footnote: I cannot think of any reason why there is a need to support (incrementing) session-ids for configuring a CoAP session - am I missing something? 5.4.2. Convey DOTS Signal Channel Session Configuration (3) -------------------------------------------------- Original:"heartbeat-timeout: Heartbeat timeout is the time to wait for a response in milliseconds to check the DOTS peer health. This is an optional attribute." So, heartbeat-timeout is configured in milliseconds. However, Figure 15 example below only has a value of 30. This example value of 30 in milliseconds is small. Original: " Header: PUT (Code=0.03) Uri-Host: www.example.com Uri-Path: "v1" Uri-Path: "dots-signal" Uri-Path: "config" Content-Format: "application/cbor" { "signal-config": { "session-id": 1234534333242, "heartbeat-timeout": 30, "max-retransmit": 7, " This needs to be updated to, say, 30000 instead of 30. Replacement: " Header: PUT (Code=0.03) Uri-Host: www.example.com Uri-Path: "v1" Uri-Path: "dots-signal" Uri-Path: "config" Content-Format: "application/cbor" { "signal-config": { "session-id": 1234534333242, "heartbeat-timeout": 30000, "max-retransmit": 4, " 5.4.2. Convey DOTS Signal Channel Session Configuration (4) -------------------------------------------------- Original: "Response code 4.22 (Unprocessable Entity) will be returned in the response if any of the heartbeat-timeout, max-retransmit, target-protocol, ack-timeout and ack-random-factor attribute values is not acceptable to the DOTS server. The DOTS server in the error response conveys the minimum and maximum attribute values acceptable by the DOTS server. The DOTS client can re-try and send the PUT request with updated attribute values acceptable to the DOTS server. Content-Format: "application/cbor" { "heartbeat-timeout": {"MinValue": 15, "MaxValue" : 60}, "max-retransmit": {"MinValue": 3, "MaxValue" : 15}, "ack-timeout": {"MinValue": 1, "MaxValue" : 30}, "ack-random-factor": {"MinValue": 1.0, "MaxValue" : 4.0} } Figure 16: Error response body " The 4.22 response should, I believe for consistency, only be generating a CoAP Diagnostic response, which does not contain payload data. I think this paragraph should be re-worded to be consistent in the CoAP responses: Replacement:"Response code 4.22 (Unprocessable Entity) will be returned in the response if any of the heartbeat-timeout, max-retransmit, target-protocol, ack-timeout and ack-random-factor attribute values are not acceptable to the DOTS server. On receipt of the 4.22 response, the DOTS client should re-request the maximum and minimum parameters acceptable by the DOTS server as described in 5.4.1. The DOTS client can re-try and send the PUT request with updated attribute values acceptable to the DOTS server. If the DOTS client receives 3 responses of 4.22 in a row on the same session, the DOTS client MUST stop trying to configure the session to prevent a continuous retry loop." 5.4.2. Convey DOTS Signal Channel Session Configuration (5) -------------------------------------------------- If a DOTS client wants to re-alter the session configuration with a subsequent PUT, should this use the same session-id? 5.4.4. Retrieving DOTS Signal Channel Session Configuration ----------------------------------------------------------- Unlike the signal GET, it is not possible to get the current configuration unless the session-id is known, but the session-id can only be created by a PUT, at which point the configuration is already known and can be confirmed by the GET. As signal-id cannot easily be guessed unless hard coded in the DOTS client, a suggestion is that a session-id of -1 allows you to determine the current configuration. As "signal-config" is not an array, it is not be possible to return multiple session-ids, but possibly the session-id of the current configuration could be returned in the payload response to a session-id of -1. A new paragraph at the end of this section. New: "If "session-id" is set to -1, then the current signal configuration is returned. If the session has previously been configured, then the appropriate session-id is returned with the current configuration parameters, otherwise -1 is returned for the session-id along with all the default configuration parameters." 5.6 Heartbeat Mechanism ----------------------- The frequency of the heartbeats is not mentioned. This should be configurable in 5.14.2 and have a default value / max-min boundaries discoverable in 5.4.1 or 5.4.4 or have a recommended fixed value. My preference is that it should be configurable as one of the signal channel session configuration parameters, with a default value of 10 seconds. e.g. to be inserted in the appropriate places. "heartbeat-refresh": {"MinValue": 2, "MaxValue" : 60}, heartbeat-refresh: Heartbeat refresh rate in seconds. This is an optional attribute. 6 Mapping parameters to CBOR (1) ---------------------------- It is possible additional parameters may need to be added to this table - e.g. DefaultValue and heartbeat-refresh. 6 Mapping parameters to CBOR (2) ---------------------------- If a client does not use the mapping parameters in a request, how should the DOTS server send back any responses - CBOR mapping encoded or just encoded as strings? Should an endpoint refuse to access non CBOR mapping encoded strings? Replacement: "All parameters in the payload in the DOTS signal channel MUST be mapped to CBOR types as follows and are given an integer key to save space. The recipient of the data MAY reject the information if it is not suitably mapped." 6 Mapping parameters to CBOR (3) ---------------------------- What happens if a sender uses CBOR mapping that are not defined in the signal channel specification? - If additional ones are needed in the future, then there will need to be a protocol version increase (from v1 to v2). New: "A DOTS agent MUST not use any additional Mapping parameters that are not defined in Figure 21." 10.2.2 Initial Registry Contents -------------------------------- It is possible additional parameters may need to be added to this table - e.g. DefaultValue and keepalive-refresh. 11.1 nttdots ------------ When testing against the nttdots server / client, the following issues were found:- CBOR mapping is not in use - it is using the original strings. COAP path requires /.wellknown/ in the UriPath. Data Channel uses CBOR/COAP, not RESTCONF (already documented in DOTS signal draft) ==================================== Regards Jon From nobody Thu Sep 28 11:36:55 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308E41347AD for ; Thu, 28 Sep 2017 11:36: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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bq8kDT4Kaiov for ; Thu, 28 Sep 2017 11:36:52 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4C013479A for ; Thu, 28 Sep 2017 11:36:52 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v8SIapeW020921 for ; Thu, 28 Sep 2017 14:36:51 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu v8SIapeW020921 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1506623811; bh=5Zb3pjkRccP9MxFoWi1OIKPUkiITJ/hUhUmD+7vqJDc=; h=From:To:Subject:Date:From; b=Iza40i0XVNCNeEuejasjD0Xeuc1eoL4SKk6QGRBeXeMWKozrdRpVW1irUwPlosSBo LdmBeISuDFv+LaDJc3NnecOxRgrooaXEC8jTWvZjJ3NZSlGV2RGZ/1nHWZakAKZkam 4wq0K7cuLXL0pmO45MzXeWgT6MwhzP8rWPYjS3ME= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v8SIanVL004045 for ; Thu, 28 Sep 2017 14:36:49 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0361.001; Thu, 28 Sep 2017 14:36:49 -0400 From: Roman Danyliw To: "'dots@ietf.org'" Thread-Topic: Agenda for Oct-2-2017 Virtual Interim Meeting Thread-Index: AdM4iKXo9/nhXUeoQVahyE4p11GLZA== Date: Thu, 28 Sep 2017 18:36:49 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104FE08C0@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Agenda for Oct-2-2017 Virtual Interim Meeting X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 28 Sep 2017 18:36:54 -0000 Hello WG! A revised agenda for the October 2, 2017 virtual interim meeting can be fou= nd at: https://datatracker.ietf.org/doc/agenda-interim-2017-dots-03-dots-01/ Roman From nobody Thu Sep 28 17:32:05 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49A71344B8 for ; Thu, 28 Sep 2017 17:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNCrpWfi7Y5L for ; Thu, 28 Sep 2017 17:32:02 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id E4391126B71 for ; Thu, 28 Sep 2017 17:31:58 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 7677C25F68D; Fri, 29 Sep 2017 09:31:57 +0900 (JST) Received: from [IPv6:::1] (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 150A875900F; Fri, 29 Sep 2017 09:31:57 +0900 (JST) To: "Konda, Tirumaleswar Reddy" , "Xialiang (Frank)" , "Dots@ietf.org" References: From: kaname nishizuka Message-ID: <2acd7300-6684-1491-4f98-7029d0b7c1b0@nttv6.jp> Date: Fri, 29 Sep 2017 09:31:55 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D004E21E09396FAA20DAD3D1" Content-Language: en-US Archived-At: Subject: Re: [Dots] =?utf-8?b?YW5vdGhlciBvcHRpb246Ly/nrZTlpI06IENhbiBET1RT?= =?utf-8?q?_protocol_support_IP_whitelist_for_DOTS_client=27s_AA=3F?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 29 Sep 2017 00:32:05 -0000 This is a multi-part message in MIME format. --------------D004E21E09396FAA20DAD3D1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Tiru, in section 9 of signal-channel draft, AAA server exists. Let me clarify the text. Mutual authentication between a DOTS client and a DOTS gateway MUST use (client) certificates? Between them (in the same domain), a mutual authentication without certificates (i.e. choices other than EAP-TLS) would be a good option, if it meets the mutual authentication and encryption requirement. TLS-PSK mode and Subject Public Key Info (SPKI)  looks good to me. I hope those options would be discussed in WGmeeting. On 2017/08/07 19:19, Konda, Tirumaleswar Reddy wrote: > > You may want to look into https://tools.ietf.org/html/rfc6959#section-7 > > > >    Even if every Internet-connected network implements source address > > validation at the ultimate network ingress, and assurances exist that > > intermediate devices are to never modify datagram source addresses, > >    source addresses cannot be used as an authentication mechanism. > > -Tiru > > *From:*Xialiang (Frank) [mailto:frank.xialiang@huawei.com] > *Sent:* Monday, August 7, 2017 3:28 PM > *To:* Konda, Tirumaleswar Reddy ; Dots@ietf.org > *Subject:* 答复: another option://答复: Can DOTS protocol support IP whitelist for DOTS client's AA? > > Hi Tiru, > > Thanks for your analysis. It makes sense to me~~ > > To be accurate, IP whitelist does not relax the mutual authentication requirement, but indeed lose the encryption benefits. > > B.R. > > Frank > > *发件人**:*Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > *发送时间:* 2017年8月7日 17:51 > *收件人:* Xialiang (Frank); Dots@ietf.org > *主题:* RE: another option://答复: Can DOTS protocol support IP whitelist for DOTS client's AA? > > TLS supports pre-shared key based authentication. The other mechanisms are Subject Public Key Info (SPKI) Fingerprint pin set for mutual authentication (self-signed certificates or raw public keys) without having to deal with CA. > > I don’t think DOTS should relax the mutual authentication and encryption requirements. > > -TIru > > *From:*Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Xialiang (Frank) > *Sent:* Monday, August 7, 2017 6:25 AM > *To:* Dots@ietf.org > *Subject:* [Dots] another option://答复: Can DOTS protocol support IP whitelist for DOTS client's AA? > > In addition to IP whitelist and certificate, pre-share key can also be an option. > > Right? > > *发件人**:*Dots [mailto:dots-bounces@ietf.org] *代表 *Xialiang (Frank) > *发送时间:* 2017年8月7日 8:52 > *收件人:* Dots@ietf.org > *主题:* [Dots] Can DOTS protocol support IP whitelist for DOTS client's AA? > > Hi, > > I think the direct use of IP whitelist on the DOTS server to authenticate and authorize the DOTS client is a simple and effect method, at least in some special use cases, like: DOTS client does not support certificate, an ISP which detects the spoofed source address, etc. > > So, should we support this as an optional way for the DOTS client’s AA and add it into the DOTS protocol drafts? > > B.R. > > Frank > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------D004E21E09396FAA20DAD3D1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Tiru,

in section 9 of signal-channel draft, AAA server exists.
Let me clarify the text.

Mutual authentication between a DOTS client and a DOTS gateway MUST use (client) certificates?
Between them (in the same domain), a mutual authentication without certificates (i.e. choices other than EAP-TLS) would be a good option, if it meets the mutual authentication and encryption requirement.

TLS-PSK mode and Subject Public Key Info (SPKI)  looks good to me.

I hope those options would be discussed in WGmeeting.



On 2017/08/07 19:19, Konda, Tirumaleswar Reddy wrote:

You may want to look into https://tools.ietf.org/html/rfc6959#section-7

<snip>

   Even if every Internet-connected network implements source address

   validation at the ultimate network ingress, and assurances exist that

   intermediate devices are to never modify datagram source addresses,

   source addresses cannot be used as an authentication mechanism.

 

-Tiru

 

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Monday, August 7, 2017 3:28 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Dots@ietf.org
Subject: 答复: another option://答复: Can DOTS protocol support IP whitelist for DOTS client's AA?

 

Hi Tiru,

Thanks for your analysis. It makes sense to me~~

 

To be accurate, IP whitelist does not relax the mutual authentication requirement, but indeed lose the encryption benefits.

 

B.R.

Frank

 

发件人: Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
发送时间: 2017年8月7日 17:51
收件人: Xialiang (Frank); Dots@ietf.org
主题: RE: another option://答复: Can DOTS protocol support IP whitelist for DOTS client's AA?

 

TLS supports pre-shared key based authentication. The other mechanisms are Subject Public Key Info (SPKI) Fingerprint pin set for mutual authentication (self-signed certificates or raw public keys) without having to deal with CA.  

 

I don’t think DOTS should relax the mutual authentication and encryption requirements.

 

-TIru

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Xialiang (Frank)
Sent: Monday, August 7, 2017 6:25 AM
To: Dots@ietf.org
Subject: [Dots] another option://答复: Can DOTS protocol support IP whitelist for DOTS client's AA?

 

In addition to IP whitelist and certificate, pre-share key can also be an option.

Right?

 

发件人: Dots [mailto:dots-bounces@ietf.org] 代表 Xialiang (Frank)
发送时间: 2017年8月7日 8:52
收件人: Dots@ietf.org
主题: [Dots] Can DOTS protocol support IP whitelist for DOTS client's AA?

 

Hi,

I think the direct use of IP whitelist on the DOTS server to authenticate and authorize the DOTS client is a simple and effect method, at least in some special use cases, like: DOTS client does not support certificate, an ISP which detects the spoofed source address, etc.

 

So, should we support this as an optional way for the DOTS client’s AA and add it into the DOTS protocol drafts?

 

B.R.

Frank



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

--------------D004E21E09396FAA20DAD3D1-- From nobody Thu Sep 28 20:47:57 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1FE1344DF for ; Thu, 28 Sep 2017 20:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ubyQyadtvpI for ; Thu, 28 Sep 2017 20:47:52 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id B959F132331 for ; Thu, 28 Sep 2017 20:47:51 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 2390B25F691; Fri, 29 Sep 2017 12:47:50 +0900 (JST) Received: from [IPv6:::1] (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 4A9D875900F; Fri, 29 Sep 2017 12:47:43 +0900 (JST) To: Jon Shallow , dots@ietf.org References: <062f01d336b7$966e9160$c34bb420$@jpshallow.com> From: kaname nishizuka Message-ID: <546b1c08-eb9e-7d61-f3bf-2c2f3d8b0750@nttv6.jp> Date: Fri, 29 Sep 2017 12:47:42 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <062f01d336b7$966e9160$c34bb420$@jpshallow.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 29 Sep 2017 03:47:56 -0000 Hi Jon, Sorry for taking time to respond to your post due to my vacation. As an implementer of DOTS protocol, I'm very glad to hear that you implemented your DOTS Server. I feel we are on the same page especially about the clarification of the signal-channel spec . Your comments help us a lot on improvement of our software. I added a few comments inline. On 2017/09/26 20:07, Jon Shallow wrote: > Hi there, > > I now have implemented a working DOTS Server supporting the signal channel > over UDP and is CoAP TCP ready. The data channel work has still to be done. > The DOTS Client is still a work in progress, but was used to test the DOTS > server. This however has highlighted some vague, open to interpretation, > definitions in the signal spec draft-ietf-dots-signal-channel-03, several of > which I have previously raised. > > If there is insufficient time to address the issues before the virtual > meeting on 2nd October, then it may make sense to discuss them at that > meeting. > > Given the interrelation of the draft IETF dots documents, other RFCs, there > is a reasonable chance that I may have misinterpreted something, or not > realised as consequence of what needs to be done. > > The following is not in order of importance - it is following the signal > specification order. Instead of getting bogged down in a section, skip it > and read the other sections and come back to the one you are having trouble > with - the wider context may help you. In particular, Sections covering 5.1 > may need to be initially skipped. > > > draft-ietf-dots-signal-channel-03 > ================================= > > > 5.1 Overview (1) > ============= > In general, what should be in, or could be expected in the response is not > that clear. This should be tightened up - this section 5.1 with a new > penultimate paragraph at the end of this section may be a good place. The > following comments / descriptions in this section highlight some areas that > have raised concerns. > > Original: (End of section 5.3.1) "For responses indicating a client or > server error, the payload explains the error situation of the result of the > requested action (Section 5.5 in [RFC7252])." > > [RFC 7572 5.5 Payloads and Representations > Both requests and responses may include a payload, depending on the Method > or Response Code, respectively. If a Method or Response Code is not defined > to have a payload, then a sender MUST NOT include one, and a recipient MUST > ignore it.] > > If the response is not 2.xx, is the diagnostic message that is sent back a > CoAp Diagnostic Message with no content format and a simple plain-text > message (RFC 5.5.2 Diagnostic Payload)? > > If so, what happens with the 4.22 (Unprocessable Entity) response in 5.4.1 > which states the acceptable values - which are encoded in CBOR? > - I think this should be a Diagnostic Payload response (perhaps with the bad > value), thus inviting the DOTS Client to (re-)do a GET Request to discover > the valid values. > - It is also not possible to determine which is the value that has failed > with just the current defined payload response - whereas a Diagnostic > message can give a hint as to the failing value. > > In 5.3.1, the only thing mentioned for a successful PUT response is the > "lifetime" parameter is required. It is unclear whether the rest of the > parameter/values that were part of the PUT request should also be in the > response. What should be returned? > > Suggested update to 5.1 to handle "RFC 7572 5.5 Payloads and > Representations" sandwiched between 2 Originals to set the context:- > > Original: ". Mitigation remains active until the DOTS client explicitly > terminates mitigation, or the mitigation lifetime expires." > > New Addition: "The following CoAP requests and responses MUST be supported > by the DOTS agents. > > +------------+-------------+ > |Method Code |Usage | > +------------+-------------+ > |0.00 |Heartbeat | > |0.01 |GET | > |0.03 |PUT | > |0.04 |DELETE | > +------------+-------------+ > Figure XXX: Supported CoAP Method Codes" > > All CoAP responses with codes that are 2.xx MUST have a CoAP payload, > content type "application/cbor" that is a "resource representation" [RFC7252 > 5.5.1 Representation]. > > All CoAP responses with codes that are not 2.xx MUST be a Diagnostic Payload > [RFC7252 5.5.2 Diagnostic Payload] with no content type. The Diagnostic > Payload can contain additional information to aid troubleshooting. > > +-------------+---------------------+----------+-------+ > |Response Code|Usage |Diagnostic|Payload| > +-------------+---------------------+----------+-------+ > |2.01 |Created |No |Yes | > |2.02 |Deleted |No |Yes | > |2.04 |Changed |No |Yes | > |2.05 |Content |No |Yes | > |3.00 |Alternative Server |No |Yes | > |4.00 |Bad Request |Yes |No | > |4.01 |Unauthorized |Yes |No | > |4.02 |Invalid Query |Yes |No | > |4.04 |Not Found |Yes |No | > |4.22 |Unprocessable Entity |Yes |No | > |5.00 |Internal Server Error|Yes |No | > |5.02 |Bad Gateway |Yes |No | > |5.03 |Service Unavailable |Yes |No | > |5.04 |Gateway Timeout |Yes |No | > +-------------+---------------------+----------+-------+ > Figure XXX: Supported CoAP response Codes > " > > Original: "Messages exchanged between DOTS client and server are serialized > ..." > Response to 5.1 will be replied later. > 5.1 Overview (2) > ============= > Nowhere is mentioned what ports should be used. RFC7252 suggest a default > of 5684/udp for CoAP DTLS. draft-ietf-core-coap-tcp-tls suggests 5684/tcp. > > Should this be stated? We just used 4646/udp as a default port for signal-channel but leave it configurable in our implementation. DOTS WG should determine the port number for signal-channel and data-channel, and request it to IANA if required. > > 5.1 Overview (3) > ============= > No mention is made of doing any signal channel recovery if a DOTS agent > restarts for any reason. Things potentially could get out of sync unless > there is some functionality to make sure that information held by each DOTS > agent is properly synchronized (even if it a simple "flush out all that you > know"). In our implementation, a DOTS server keeps its information, so duplicated request will be rejected by DOTS server after restart of DOTS client. > > 5.3.1 Requesting Mitigation > =========================== > Original: ". The relative order of two mitigation requests from a DOTS > client is determined by comparing their respective mitigation-id values. If > two mitigation requests have overlapping mitigation scopes the mitigation > request with higher numeric mitigation-id value will override the mitigation > request with a lower numeric mitigation-id value." > > This raises several implementation questions. > > Question 1 > ---------- > Say a PUT mitigation-id with a value of #99 is followed by a PUT > mitigation-id of #100 which overlaps, so #99 is ignored/overridden. Then > there is a DELETE #100. Do we revert back to #99? > > If yes, then do we need to remember #1 through #98 to revert back to them if > needed - the logical extension of this is remembering all 2^31 entries - > which probably is a DOS attack. > > My suggestion would be that #99 is dropped/deleted if #100 overlaps, and the > subsequent deleting #100 withdraws that particular mitigation and so > mitigation stops. The new wording could be:- > > Replacement: "The relative order of two mitigation requests from a DOTS > client is determined by comparing their respective mitigation-id values. If > two mitigation requests have overlapping mitigation scopes the mitigation > request with higher numeric mitigation-id value will override the mitigation > request with a lower numeric mitigation-id value. The overlapped lower > numeric mitigation-id is automatically deleted and no longer available for > querying against." In our service (DOTS has not been used yet though), we are keeping old mitigation request and revert back if new mitigation was withdrawn. Our implementation has not been caring about the case, but reverting back would be an operational requirement. > Question 2 > ---------- > It is unclear as to how this overlapping works, say with #99 target-ip > [1.1.1.1,1.1.1.2] and #100 target-ip [1.1.1.2,1.1.1.3]. Is it correct that > 1.1.1.1 should no longer be mitigated, but 1.1.1.3 should start? > > What about overlapping protocols, but not overlapping target-ips etc? > > Question 3 > ---------- > If there is an overlap, why cannot both mitigation scopes (both lower and > higher mitigation-ids) still continue? > > Question 4 > ---------- > Handling mitigation request refreshes. > When the lifetime expires with the active mitigation-id, the mitigation > stops unless there is a refreshed mitigation request of some sort. Does the > refresh mitigation request to keep the mitigation going use the same > mitigation-id, or must it be a new (incremented?) mitigation-id? > > If the refresh requires a new incremented id, then this will wrap at some > point and the "mitigation request with higher numeric mitigation-id value > will override" test will fail. > > Original: "If the DOTS server finds the mitigation-id parameter value > conveyed in the PUT request in its configuration data then the server MAY > update the mitigation request, and a 2.04 (Changed) response is returned to > indicate a successful update of the mitigation request." > > This implies the same mitigation-id is used for doing the refresh. > My suggestion is to add in a new paragraph at the end of section 5.3.1 for > clarity. > > New: "For mitigation to continue beyond the initial negotiated "lifetime", > the DOTS client will need to refresh the current mitigation request by > sending a new PUT request. The PUT request SHOULD use the same > "mitigation-id", and SHOULD repeat all the other parameters as sent in the > original mitigation request apart from a possible change to the "lifetime" > parameter. The DOTS server MAY refuse the refresh request if any of the > request parameters (apart from "lifetime") have changed." I support this change. > Question 5 > ---------- > When the PUT is refreshed with the same mitigation-id by the client at some > point before the lifetime expires, if the signal mitigate content (e.g. > target-protocol is changed) is sent by the client, should this be allowed, > ignored or rejected? > > My suggestion is in the "New:" update under Question 4 just above. > > Question 6 > ---------- > As Scope has been defined as an array, are multiple mitigation-ids allowed > with a single PUT request? > - I think only one should be allowed. The replacement is for the > mitigation-id definition - the addition is at the end. > > Replacement: "mitigation-id: Identifier for the mitigation request > represented using an integer. This identifier MUST be unique for each > mitigation request bound to the DOTS client, i.e., the mitigation-id > parameter value in the mitigation request needs to be unique relative to the > mitigation-id parameter values of active mitigation requests conveyed from > the DOTS client to the DOTS server. This identifier MUST be generated by > the DOTS client. This document does not make any assumption about how this > identifier is generated. This is a mandatory attribute. There can only be > one mitigation-id request per Scope per single PUT request." > I support this change. > 5.3.2 Withdraw a DOTS Signal > ============================ > Can multiple mitigation-ids be sent in a single DELETE request (scope is an > array)? > > What gets sent back in the payload? > > If the mitigation-id found, then that can easily be the mitigation-id > information. > > If not found, is there no payload, or should there be an empty scope array > something like > { > "mitigation-scope": { > "scope": [ > ] > } > } > > We need to define what the client will expect (especially if it is going to > make a decision on a 2.02 response for a non-existent mitigation-id). > > My suggestion is to add in a new paragraph at the end of this section. > > New: "Multiple mitigation-ids MAY be included in the DELETE "scope". The > "resource representation" response payload always includes > "mitigation-scope" and "scope" with zero or more mitigation-ids that were > found and deleted. If the DELETE is repeated for one or more mitigation-ids > during the active-but-terminating period, then the matching mitigation-ids > continue to get returned." > It looks good to me, we will check the implementation. > 5.3.3 Retrieving a DOTS Signal (1) > ============================== > When/what to send back an unsolicited response when running with an Observe. > Some questions that need to be answered. > > When "observe" is set to 0, should the DOTS server send back an unsolicited > information / status update > a) whenever there is a "status" parameter change > b) when there is a change to one of the "*-dropped" parameters > c) send a response at some regular time interval? > - Figure 10 implies it is just on a "status" parameter change. > > If at a regular interval (c), should this be a configurable value (as per > configuration under 5.4?) or a defined fixed value? > > What should the recommended frequency of update be (1 per n seconds")? > > If Observe is not used to set up a regular frequency update, and therefore > it is the responsibility of the DOTS client to poll as required (perhaps for > graphing the data), should the DOTS Client set the Observe option (which > will set up/cancel either (a) or (b) above) when polling? > -If Observe is set to 1 during the polling, then it will cancel any > notifications set up. > > Is Observe a MUST with a signal GET? > - All examples have this Observe option included in Figure 10 > > I think that adding in an extra parameter "refresh-rate" would help here if > there is to be a continuous refresh of information. However, this would > only work for the explicit "mitigation-id" request. Alternatively, the > generic request (no payload) could be replaced with one where the > mitigation-id is -1 (following the same usage as the challenges over using > the GET configuration signal-id in 5.4.1). Thoughts? > will be replied later. > 5.3.3 Retrieving a DOTS Signal (2) > ============================== > There is inconsistency in the definition of the "mitigation-scope" parameter > - it is either an object/map or an array (for the responses back from the > GET with no payload). The usage needs to be consistent throughout the > specification to avoid errors creeping in. > > As "scope" is an array, then the multiple responses should be:- > > Replacement: " > { > "mitigation-scope":{ > "scope": [ > { > "mitigation-id": 12332, > "target-protocol": [ > 17 > ], > "lifetime":1801, > "status":2, > "bytes-dropped": 134334555, > "bps-dropped": 43344, > "pkts-dropped": 333334444, > "pps-dropped": 432432 > }, > { > "mitigation-id": 12333, > "target-protocol": [ > 6 > ], > "lifetime":1749, > "status":3, > "bytes-dropped": 0, > "bps-dropped": 0, > "pkts-dropped": 0, > "pps-dropped": 0 > } > ] > } > } > " > > > 5.3.3 Retrieving a DOTS Signal (3) > ============================== > "bytes-dropped" and "pkts-dropped". Are these counters from the start of the > original initial PUT mitigate requests, or are these reset to 0 whenever > there is a PUT mitigate refresh? > > My inclination is to go with the count from the initial PUT mitigate request > (with a potential wrap around for long mitigations). > > It is possible that a DOTS client may have been restarted, but the > mitigation request continues for the remainder of the lifetime > Replacement: "bytes-dropped: The total dropped byte count for the > mitigation request since the mitigation was initially requested. This is an > optional attribute. > > bps-dropped: The average dropped bytes per second for the mitigation > request. This is an optional attribute. > > pkts-dropped: The total dropped packet count for the mitigation request > since the mitigation was initially requested. This is an optional > attribute. > > pps-dropped: The average dropped packets per second for the mitigation > request. This is an optional attribute." How to count the dropped packet depends on mitigation methods. Adding bps-dropped and pps-dropped as an optional attribute will make a room for reporting capability of various mitigation methods like ACL on routers. > > 5.3.3 Retrieving a DOTS Signal (4) > ============================== > The "lifetime" returned value is not defined in the mitigation status > parameters. Is this the remaining time (in seconds?) of the current > mitigation request? > > Replacement: "The mitigation status parameters are described below. > > lifetime: The remaining lifetime in seconds of the current mitigation-id > request. > > bytes-dropped: The total dropped byte count.." > > > 5.3.4 Efficacy Update from DOTS Client (1) > -------------------------------------- > Original: "The PUT request MUST include all the parameters used in the PUT > request to convey the DOTS signal (Section 5.3.1)." > This also implicitly implies that this must be done in 5.3.1 as well. > > What is the DOTS server supposed to do if any of the parameters (apart from > perhaps "lifetime") are different - does this invoke a 4.02? > > The same question is true for 5.3.1. > > Replacement: "While DDoS mitigation is active, a DOTS client MAY frequently > transmit DOTS mitigation efficacy updates to the relevant DOTS server. An > PUT request (Figure 11) is used to convey the mitigation efficacy update to > the DOTS server. The PUT request MUST include all the parameters used in > the PUT request to convey the DOTS signal (Section 5.3.1) unchanged apart > from "lifetime". The DOTS server MUST reject the request with a 4.02 code > if this is not the case. The If-Match Option (Section 5.10.8.1 of > [RFC7252]) with an empty value is used to make the PUT request conditional > on the current existence of a mitigation request with the same > mitigation-id. If UDP is used as ... > > > 5.3.4 Efficacy Update from DOTS Client (2) > -------------------------------------- > Original:" The 5.xx response codes are returned if the DOTS server has erred > or is incapable of performing the mitigation." > > Should there be any definitions of what 5.xx code should be used where? > > > 5.3.4 Efficacy Update from DOTS Client (3) > -------------------------------------- > Does a PUT with "attack-status" refresh the outstanding lifetime on the > current mitigation request? > > Or is the "lifetime" parameter optional, despite the MUST statement at the > beginning of this session "The PUT request MUST include all the parameters > used in the PUT request to convey the DOTS signal (Section 5.3.1)."? > > For clarity, I think the following should be added in as a paragraph at the > end of this section:- > > New: "The current mitigation does not have the lifetime refreshed when using > a Efficacy Update PUT as per section 5.3.4, but does have the lifetime > refreshed when using a Mitigation Request PUT as per section 5.3.1." We haven't implemented efficacy update features, but your proposing texts looks good to us. Please give us time to look into them. Also we'd like to reply later about signal channel session configuration topics(5.4) below. > > 5.4 DOTS Signal Channel Session Configuration > --------------------------------------------- > Original:" a. Heartbeat timeout: DOTS agents regularly send heartbeats > (Ping/ Pong) to each other after mutual authentication in order to keep the > DOTS signal channel open, heartbeat timeout is the time to wait for a Pong > in milliseconds." > > Nowhere is the frequency defined for "regular send" and should this also be > configurable in 5.4.1? > > > 5.4.1 Discover Acceptable Configuration Parameters (1) > -------------------------------------------------- > Original: "A GET request is used to obtain acceptable configuration > parameters on the DOTS server for DOTS signal channel session > configuration." > > So, when making a configuration change, is this specific to the Signal > Channel between the DOTS Server and DOTS client, or is it specific to each > CoAP session where potentially there could be multiple sessions for the same > signal channel? > > Replacement: ""A GET request is used to obtain acceptable configuration > parameters on the DOTS server for current session using the DOTS signal > channel." > > > 5.4.1 Discover Acceptable Configuration Parameters (2) > -------------------------------------------------- > Figure 13. Does it also make sense to return Default values as well? > - It may make sense for these to be Current as opposed to Default values. > > Replacement: "Content-Format: "application/cbor" > { > "heartbeat-timeout": {"MinValue": integer, "MaxValue" : > integer,"DefaultValue":integer}, > "max-retransmit": {"MinValue": integer, "MaxValue" : > integer,"DefaultValue":integer }, > "ack-timeout": {"MinValue": integer, "MaxValue" : > integer,"DefaultValue":integer }, > "ack-random-factor": {"MinValue": number, "MaxValue" : > number,"DefaultValue":integer } > } > > > 5.4.2. Convey DOTS Signal Channel Session Configuration (1) > -------------------------------------------------- > Original: "The RECOMMENDED values of transmission parameter values are > ack_timeout (2 seconds), max-retransmit (7), ack-random-factor (1.5) and > heartbeat-timeout (371 seconds)." > > RFC7252 has max-retransmit set to 4, not 7. (RFC 7252 4.8 Transmission > Parameters). > > With the exponential back off for retries of CON messages, using 4 gives an > expiration of the request after about 1.5 minutes, with a value of 7 this is > almost 10 minutes. The 10 minutes does seem excessively long to me - > especially when it is for a CON Heartbeat. > Unless there is a good reason for 7, I suggest we go with the RFC7572 > recommendations of 4. > > Replacement: "The RECOMMENDED values of transmission parameter values are > ack_timeout (2 seconds), max-retransmit (4), ack-random-factor (1.5) and > heartbeat-timeout (371 seconds)." > > Replacement: " > Header: PUT (Code=0.03) > Uri-Host: "www.example.com" > Uri-Path: "v1" > Uri-Path: "dots-signal" > Uri-Path: "config" > Content-Format: "application/cbor" > { > "signal-config": { > "session-id": 1234534333242, > "heartbeat-timeout": 30000, > "max-retransmit": 4, > "ack-timeout": 5, > "ack-random-factor": 1.5, > "trigger-mitigation": false > } > } > " > > > 5.4.2. Convey DOTS Signal Channel Session Configuration (2) > -------------------------------------------------- > Original: The PUT request with higher numeric session-id value over-rides > the DOTS signal channel session configuration data installed by a PUT > request with a lower numeric session-id value." > > Say a PUT session-id with a value of #99 is followed by a PUT session-id of > #100 which overlaps, so #99 is ignored. Then there is a DELETE #100. Do we > revert back to #99? > > If yes, then do we need to remember #1 through #98 to revert back to them if > needed - the logical extension of this is remembering all 2^31 entries - > which probably is a DOS attack. > > My suggestion would be that #99 is dropped if #100 overlaps, and deleting > #100 deletes that particular session-id. The new wording would be:- > > Replacement:" The PUT request with higher numeric session-id value > over-rides the DOTS signal channel session configuration data installed by a > PUT request with a lower numeric session-id value. The overlapped lower > numeric session-id is automatically deleted and no longer available for > querying against.". > > Footnote: I cannot think of any reason why there is a need to support > (incrementing) session-ids for configuring a CoAP session - am I missing > something? > > > 5.4.2. Convey DOTS Signal Channel Session Configuration (3) > -------------------------------------------------- > Original:"heartbeat-timeout: Heartbeat timeout is the time to wait for a > response in milliseconds to check the DOTS peer health. This is an optional > attribute." > > So, heartbeat-timeout is configured in milliseconds. However, Figure 15 > example below only has a value of 30. This example value of 30 in > milliseconds is small. > > Original: " > Header: PUT (Code=0.03) > Uri-Host: www.example.com > Uri-Path: "v1" > Uri-Path: "dots-signal" > Uri-Path: "config" > Content-Format: "application/cbor" > { > "signal-config": { > "session-id": 1234534333242, > "heartbeat-timeout": 30, > "max-retransmit": 7, > " > > This needs to be updated to, say, 30000 instead of 30. > > Replacement: " > Header: PUT (Code=0.03) > Uri-Host: www.example.com > Uri-Path: "v1" > Uri-Path: "dots-signal" > Uri-Path: "config" > Content-Format: "application/cbor" > { > "signal-config": { > "session-id": 1234534333242, > "heartbeat-timeout": 30000, > "max-retransmit": 4, > " > > > 5.4.2. Convey DOTS Signal Channel Session Configuration (4) > -------------------------------------------------- > Original: "Response code 4.22 (Unprocessable Entity) will be returned in the > response if any of the heartbeat-timeout, max-retransmit, target-protocol, > ack-timeout and ack-random-factor attribute values is not acceptable to the > DOTS server. The DOTS server in the error response conveys the minimum and > maximum attribute values acceptable by the DOTS server. The DOTS client can > re-try and send the PUT request with updated attribute values acceptable to > the DOTS server. > > Content-Format: "application/cbor" > { > "heartbeat-timeout": {"MinValue": 15, "MaxValue" : 60}, > "max-retransmit": {"MinValue": 3, "MaxValue" : 15}, > "ack-timeout": {"MinValue": 1, "MaxValue" : 30}, > "ack-random-factor": {"MinValue": 1.0, "MaxValue" : 4.0} > } > Figure 16: Error response body > " > > The 4.22 response should, I believe for consistency, only be generating a > CoAP Diagnostic response, which does not contain payload data. I think this > paragraph should be re-worded to be consistent in the CoAP responses: > > Replacement:"Response code 4.22 (Unprocessable Entity) will be returned in > the response if any of the heartbeat-timeout, max-retransmit, > target-protocol, ack-timeout and ack-random-factor attribute values are not > acceptable to the DOTS server. On receipt of the 4.22 response, the DOTS > client should re-request the maximum and minimum parameters acceptable by > the DOTS server as described in 5.4.1. The DOTS client can re-try and send > the PUT request with updated attribute values acceptable to the DOTS server. > If the DOTS client receives 3 responses of 4.22 in a row on the same > session, the DOTS client MUST stop trying to configure the session to > prevent a continuous retry loop." > > > 5.4.2. Convey DOTS Signal Channel Session Configuration (5) > -------------------------------------------------- > If a DOTS client wants to re-alter the session configuration with a > subsequent PUT, should this use the same session-id? > > > 5.4.4. Retrieving DOTS Signal Channel Session Configuration > ----------------------------------------------------------- > Unlike the signal GET, it is not possible to get the current configuration > unless the session-id is known, but the session-id can only be created by a > PUT, at which point the configuration is already known and can be confirmed > by the GET. > > As signal-id cannot easily be guessed unless hard coded in the DOTS client, > a suggestion is that a session-id of -1 allows you to determine the current > configuration. As "signal-config" is not an array, it is not be possible to > return multiple session-ids, but possibly the session-id of the current > configuration could be returned in the payload response to a session-id of > -1. A new paragraph at the end of this section. > > New: "If "session-id" is set to -1, then the current signal configuration is > returned. If the session has previously been configured, then the > appropriate session-id is returned with the current configuration > parameters, otherwise -1 is returned for the session-id along with all the > default configuration parameters." > > > 5.6 Heartbeat Mechanism > ----------------------- > The frequency of the heartbeats is not mentioned. This should be > configurable in 5.14.2 and have a default value / max-min boundaries > discoverable in 5.4.1 or 5.4.4 or have a recommended fixed value. > > My preference is that it should be configurable as one of the signal channel > session configuration parameters, with a default value of 10 seconds. > > e.g. to be inserted in the appropriate places. > > "heartbeat-refresh": {"MinValue": 2, "MaxValue" : 60}, > heartbeat-refresh: Heartbeat refresh rate in seconds. This is an optional > attribute. > > > 6 Mapping parameters to CBOR (1) > ---------------------------- > It is possible additional parameters may need to be added to this table - > e.g. DefaultValue and heartbeat-refresh. > > > 6 Mapping parameters to CBOR (2) > ---------------------------- > If a client does not use the mapping parameters in a request, how should the > DOTS server send back any responses - CBOR mapping encoded or just encoded > as strings? > > Should an endpoint refuse to access non CBOR mapping encoded strings? > > Replacement: "All parameters in the payload in the DOTS signal channel MUST > be mapped to CBOR types as follows and are given an integer key to save > space. The recipient of the data MAY reject the information if it is not > suitably mapped." > > > 6 Mapping parameters to CBOR (3) > ---------------------------- > What happens if a sender uses CBOR mapping that are not defined in the > signal channel specification? > - If additional ones are needed in the future, then there will need to be a > protocol version increase (from v1 to v2). > > New: "A DOTS agent MUST not use any additional Mapping parameters that are > not defined in Figure 21." > > > 10.2.2 Initial Registry Contents > -------------------------------- > It is possible additional parameters may need to be added to this table - > e.g. DefaultValue and keepalive-refresh. > > > 11.1 nttdots > ------------ > When testing against the nttdots server / client, the following issues were > found:- > > CBOR mapping is not in use - it is using the original strings. > > COAP path requires /.wellknown/ in the UriPath. > > Data Channel uses CBOR/COAP, not RESTCONF (already documented in DOTS signal > draft) I've realized issues you found. We(our dev members) are more than happy to hear from you that we can test interoperability each other at some time. Before that, we'd like to look into your proposals and reply to you(and WG) in detail later, and we are willing to discuss those implementation details. Thank you! regards, kaname > ==================================== > > Regards > > Jon > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Sep 28 21:22:42 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C97A13292A for ; Thu, 28 Sep 2017 21:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zX7JxsoXc-O for ; Thu, 28 Sep 2017 21:22:37 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 968E1132331 for ; Thu, 28 Sep 2017 21:22:36 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1506658947; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=n1gTrVFxFHepk3/5k9HR/nnzP41y+916esvV7v E/sFY=; b=NEDYpI4tZxA/TxFN469L767+EtH+79vwCWOfAfsD RZvPZbP+GJU+c6IcuK/+TXcFbQEGU+SQcG8u6rlaNYwmGOsXEN JQXQtGp/YomKqct3q+j9bPGRGXdgJjVyldTEZZQA6R3wEKx+HN OoDpoKHB3hmNTJiCc4oQHxlA8ysqypE= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 2212_025a_b67ce648_1e7b_445d_9a39_8211b3721873; Thu, 28 Sep 2017 23:22:26 -0500 Received: from MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 29 Sep 2017 00:22:24 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Fri, 29 Sep 2017 00:22:19 -0400 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 29 Sep 2017 00:22:01 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 29 Sep 2017 04:22:18 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.011; Fri, 29 Sep 2017 04:22:18 +0000 From: "Konda, Tirumaleswar Reddy" To: kaname nishizuka , "Xialiang (Frank)" , "Dots@ietf.org" Thread-Topic: =?utf-8?B?W0RvdHNdIGFub3RoZXIgb3B0aW9uOi8v562U5aSNOiBDYW4gRE9UUyBwcm90?= =?utf-8?B?b2NvbCBzdXBwb3J0IElQIHdoaXRlbGlzdCBmb3IgRE9UUyBjbGllbnQncyBB?= =?utf-8?Q?A=3F?= Thread-Index: AdMPF2QONmutCNOvSwe0CfD0yMkBTgAACUnwAA6poPAABEOgkAAAs7nQClUTPoAAB3H3QA== Date: Fri, 29 Sep 2017 04:22:17 +0000 Message-ID: References: <2acd7300-6684-1491-4f98-7029d0b7c1b0@nttv6.jp> In-Reply-To: <2acd7300-6684-1491-4f98-7029d0b7c1b0@nttv6.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.220.42] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:FspSkJ/kgq30NmujmNHZfOtIrQCG0FtBYWuLvq6kOAyYwZdlr8QRbuDQULsmx8rDXsxTe495W4aEHuBdLt7XpqxpMBXGTBObG1oxZay1gVb46Ea2ctZnpJNZk2nGxAjetAavnurykKR1W7ltAYU8cOtQC68GKooNfULJVs30SgUi20SZd1kiluEFW2/XYbLEJqwz5/ZJ2U8wJTNR870DUMPkJ/Cl4pmjLwK6fh3KRA+Xt965cMQiq8wHQKu7iobavtlzrxMfiRPshw5abOMPe8psqPARt/LclkMOWGMB4H0rllHdr55FSG+0ldzu71o0zc9RaDG/7TnE2lxkR4MGBw==; 5:A8E9gpOm+jlqnU+GdywM6ShClaTjGgHKqxfbw98/rB6VDkDTLbNIpvw/rnBM8/KXOxpchieo0btGBhGtZotATiDQNdhYr1LwUaAXowLTAlhDF331UkvSTVzKLcooAKtzCum/N0ug3bSHiGfjBUVhww==; 24:Np5nQv6IWM5Qjg8z9Yrr8qFWZFabNYTH9mLuxIbEMuDFCK0Xq5/V5fsRiGWQNbhoTe5Sy7EXhhSrWekjRUXV3lopKvoIpEQZ9tokOGtVwwQ=; 7:hSec7bZJZryBAPRrp6nKYJbooqJXffz34SirfP82dEluw5ZQM0B/FpxusTU29WIN/KAPbKi38bxk0tkG6obrmwO3Uh9Zc0rmpjuSwZSxZ6puJedcdRPXRdA7js22b/QH5PL0Q6vDx/FNu6OzFUim5KSYkniPbFZAape5qN/UOM84G6wo4tlyCgbEfCv7CqN4kAbLBTytSq30lQBYkJV7NvilekHb51VPW7E5oNH1Fgo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 648126ea-222c-41d9-2d6d-08d506f1abbf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-exchange-antispam-report-test: UriScan:(158342451672863)(50582790962513)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0445A82F82 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(377454003)(199003)(189002)(24454002)(32952001)(81166006)(5660300001)(93886005)(55016002)(53936002)(99286003)(6306002)(7696004)(2950100002)(9686003)(54896002)(66066001)(6246003)(14454004)(478600001)(86362001)(6506006)(72206003)(77096006)(25786009)(68736007)(110136005)(2900100001)(236005)(966005)(229853002)(80792005)(97736004)(2501003)(3660700001)(106356001)(224303003)(54356999)(76176999)(50986999)(74316002)(33656002)(7736002)(105586002)(790700001)(6116002)(102836003)(3846002)(53546010)(189998001)(101416001)(2906002)(606006)(8936002)(316002)(81156014)(3280700002)(6436002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17880DA8BDE932F1A758E27AEA7E0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2017 04:22:17.7829 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.6 X-NAI-Spam-Version: 2.3.0.9418 : core <6126> : inlines <6099> : streams <1765063> : uri <2508315> Archived-At: Subject: Re: [Dots] =?utf-8?b?YW5vdGhlciBvcHRpb246Ly/nrZTlpI06IENhbiBET1RT?= =?utf-8?q?_protocol_support_IP_whitelist_for_DOTS_client=27s_AA=3F?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 29 Sep 2017 04:22:40 -0000 --_000_DM5PR16MB17880DA8BDE932F1A758E27AEA7E0DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHNpZ25hbCBjaGFubmVsIGRyYWZ0IGRvZXMgbm90IG1hbmRhdGUgY2VydGlmaWNhdGVzIGZv ciBtdXR1YWwgYXV0aGVudGljYXRpb24gKFVzaW5nIGFuIEFBQSBzZXJ2ZXIgaXMgb25seSBhbiBl eGFtcGxlIGRlcGxveW1lbnQpLiBET1RTIGFnZW50cyBpbiB0aGUgc2FtZSBkb21haW4gY2FuIHVz ZSBvdGhlciBtZWNoYW5pc21zIGxpa2UgVExTLVBTSyBhbmQgU1BLSS4gQW5kcmV3IGFuZCBJIGFt IHBsYW5uaW5nIHB1dCB1cCBhIGRyYWZ0IG9uIERPVFMgcHJvdmlzaW9uaW5nLg0KDQotVGlydQ0K DQpGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg a2FuYW1lIG5pc2hpenVrYQ0KU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjksIDIwMTcgNjowMiBB TQ0KVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRh QE1jQWZlZS5jb20+OyBYaWFsaWFuZyAoRnJhbmspIDxmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29t PjsgRG90c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEb3RzXSBhbm90aGVyIG9wdGlvbjovL+et lOWkjTogQ2FuIERPVFMgcHJvdG9jb2wgc3VwcG9ydCBJUCB3aGl0ZWxpc3QgZm9yIERPVFMgY2xp ZW50J3MgQUE/DQoNCkhpIFRpcnUsDQoNCmluIHNlY3Rpb24gOSBvZiBzaWduYWwtY2hhbm5lbCBk cmFmdCwgQUFBIHNlcnZlciBleGlzdHMuDQpMZXQgbWUgY2xhcmlmeSB0aGUgdGV4dC4NCg0KTXV0 dWFsIGF1dGhlbnRpY2F0aW9uIGJldHdlZW4gYSBET1RTIGNsaWVudCBhbmQgYSBET1RTIGdhdGV3 YXkgTVVTVCB1c2UgKGNsaWVudCkgY2VydGlmaWNhdGVzPw0KQmV0d2VlbiB0aGVtIChpbiB0aGUg c2FtZSBkb21haW4pLCBhIG11dHVhbCBhdXRoZW50aWNhdGlvbiB3aXRob3V0IGNlcnRpZmljYXRl cyAoaS5lLiBjaG9pY2VzIG90aGVyIHRoYW4gRUFQLVRMUykgd291bGQgYmUgYSBnb29kIG9wdGlv biwgaWYgaXQgbWVldHMgdGhlIG11dHVhbCBhdXRoZW50aWNhdGlvbiBhbmQgZW5jcnlwdGlvbiBy ZXF1aXJlbWVudC4NCg0KVExTLVBTSyBtb2RlIGFuZCBTdWJqZWN0IFB1YmxpYyBLZXkgSW5mbyAo U1BLSSkgIGxvb2tzIGdvb2QgdG8gbWUuDQoNCkkgaG9wZSB0aG9zZSBvcHRpb25zIHdvdWxkIGJl IGRpc2N1c3NlZCBpbiBXR21lZXRpbmcuDQoNCg0KT24gMjAxNy8wOC8wNyAxOToxOSwgS29uZGEs IFRpcnVtYWxlc3dhciBSZWRkeSB3cm90ZToNCllvdSBtYXkgd2FudCB0byBsb29rIGludG8gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY5NTkjc2VjdGlvbi03DQo8c25pcD4NCiAgIEV2 ZW4gaWYgZXZlcnkgSW50ZXJuZXQtY29ubmVjdGVkIG5ldHdvcmsgaW1wbGVtZW50cyBzb3VyY2Ug YWRkcmVzcw0KICAgdmFsaWRhdGlvbiBhdCB0aGUgdWx0aW1hdGUgbmV0d29yayBpbmdyZXNzLCBh bmQgYXNzdXJhbmNlcyBleGlzdCB0aGF0DQogICBpbnRlcm1lZGlhdGUgZGV2aWNlcyBhcmUgdG8g bmV2ZXIgbW9kaWZ5IGRhdGFncmFtIHNvdXJjZSBhZGRyZXNzZXMsDQogICBzb3VyY2UgYWRkcmVz c2VzIGNhbm5vdCBiZSB1c2VkIGFzIGFuIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbS4NCg0KLVRp cnUNCg0KRnJvbTogWGlhbGlhbmcgKEZyYW5rKSBbbWFpbHRvOmZyYW5rLnhpYWxpYW5nQGh1YXdl aS5jb21dDQpTZW50OiBNb25kYXksIEF1Z3VzdCA3LCAyMDE3IDM6MjggUE0NClRvOiBLb25kYSwg VGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjxt YWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47IERvdHNAaWV0Zi5vcmc8 bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiDnrZTlpI06IGFub3RoZXIgb3B0aW9uOi8v 562U5aSNOiBDYW4gRE9UUyBwcm90b2NvbCBzdXBwb3J0IElQIHdoaXRlbGlzdCBmb3IgRE9UUyBj bGllbnQncyBBQT8NCg0KSGkgVGlydSwNClRoYW5rcyBmb3IgeW91ciBhbmFseXNpcy4gSXQgbWFr ZXMgc2Vuc2UgdG8gbWV+fg0KDQpUbyBiZSBhY2N1cmF0ZSwgSVAgd2hpdGVsaXN0IGRvZXMgbm90 IHJlbGF4IHRoZSBtdXR1YWwgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnQsIGJ1dCBpbmRlZWQg bG9zZSB0aGUgZW5jcnlwdGlvbiBiZW5lZml0cy4NCg0KQi5SLg0KRnJhbmsNCg0K5Y+R5Lu25Lq6 OiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IFttYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29u ZGFATWNBZmVlLmNvbV0NCuWPkemAgeaXtumXtDogMjAxN+W5tDjmnIg35pelIDE3OjUxDQrmlLbk u7bkuro6IFhpYWxpYW5nIChGcmFuayk7IERvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5v cmc+DQrkuLvpopg6IFJFOiBhbm90aGVyIG9wdGlvbjovL+etlOWkjTogQ2FuIERPVFMgcHJvdG9j b2wgc3VwcG9ydCBJUCB3aGl0ZWxpc3QgZm9yIERPVFMgY2xpZW50J3MgQUE/DQoNClRMUyBzdXBw b3J0cyBwcmUtc2hhcmVkIGtleSBiYXNlZCBhdXRoZW50aWNhdGlvbi4gVGhlIG90aGVyIG1lY2hh bmlzbXMgYXJlIFN1YmplY3QgUHVibGljIEtleSBJbmZvIChTUEtJKSBGaW5nZXJwcmludCBwaW4g c2V0IGZvciBtdXR1YWwgYXV0aGVudGljYXRpb24gKHNlbGYtc2lnbmVkIGNlcnRpZmljYXRlcyBv ciByYXcgcHVibGljIGtleXMpIHdpdGhvdXQgaGF2aW5nIHRvIGRlYWwgd2l0aCBDQS4NCg0KSSBk b27igJl0IHRoaW5rIERPVFMgc2hvdWxkIHJlbGF4IHRoZSBtdXR1YWwgYXV0aGVudGljYXRpb24g YW5kIGVuY3J5cHRpb24gcmVxdWlyZW1lbnRzLg0KDQotVElydQ0KDQpGcm9tOiBEb3RzIFttYWls dG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWGlhbGlhbmcgKEZyYW5rKQ0K U2VudDogTW9uZGF5LCBBdWd1c3QgNywgMjAxNyA2OjI1IEFNDQpUbzogRG90c0BpZXRmLm9yZzxt YWlsdG86RG90c0BpZXRmLm9yZz4NClN1YmplY3Q6IFtEb3RzXSBhbm90aGVyIG9wdGlvbjovL+et lOWkjTogQ2FuIERPVFMgcHJvdG9jb2wgc3VwcG9ydCBJUCB3aGl0ZWxpc3QgZm9yIERPVFMgY2xp ZW50J3MgQUE/DQoNCkluIGFkZGl0aW9uIHRvIElQIHdoaXRlbGlzdCBhbmQgY2VydGlmaWNhdGUs IHByZS1zaGFyZSBrZXkgY2FuIGFsc28gYmUgYW4gb3B0aW9uLg0KUmlnaHQ/DQoNCuWPkeS7tuS6 ujogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIFhpYWxpYW5nIChG cmFuaykNCuWPkemAgeaXtumXtDogMjAxN+W5tDjmnIg35pelIDg6NTINCuaUtuS7tuS6ujogRG90 c0BpZXRmLm9yZzxtYWlsdG86RG90c0BpZXRmLm9yZz4NCuS4u+mimDogW0RvdHNdIENhbiBET1RT IHByb3RvY29sIHN1cHBvcnQgSVAgd2hpdGVsaXN0IGZvciBET1RTIGNsaWVudCdzIEFBPw0KDQpI aSwNCkkgdGhpbmsgdGhlIGRpcmVjdCB1c2Ugb2YgSVAgd2hpdGVsaXN0IG9uIHRoZSBET1RTIHNl cnZlciB0byBhdXRoZW50aWNhdGUgYW5kIGF1dGhvcml6ZSB0aGUgRE9UUyBjbGllbnQgaXMgYSBz aW1wbGUgYW5kIGVmZmVjdCBtZXRob2QsIGF0IGxlYXN0IGluIHNvbWUgc3BlY2lhbCB1c2UgY2Fz ZXMsIGxpa2U6IERPVFMgY2xpZW50IGRvZXMgbm90IHN1cHBvcnQgY2VydGlmaWNhdGUsIGFuIElT UCB3aGljaCBkZXRlY3RzIHRoZSBzcG9vZmVkIHNvdXJjZSBhZGRyZXNzLCBldGMuDQoNClNvLCBz aG91bGQgd2Ugc3VwcG9ydCB0aGlzIGFzIGFuIG9wdGlvbmFsIHdheSBmb3IgdGhlIERPVFMgY2xp ZW504oCZcyBBQSBhbmQgYWRkIGl0IGludG8gdGhlIERPVFMgcHJvdG9jb2wgZHJhZnRzPw0KDQpC LlIuDQpGcmFuaw0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpEb3RzIG1haWxpbmcgbGlzdA0KDQpEb3RzQGlldGYub3JnPG1haWx0bzpE b3RzQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rv dHMNCg0K --_000_DM5PR16MB17880DA8BDE932F1A758E27AEA7E0DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAxIDYg MCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAy IDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTWljcm9zb2Z0IEpoZW5nSGVpIjsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQE1pY3Jvc29mdCBKaGVuZ0hlaSI7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBT aW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiTWljcm9zb2Z0IEpoZW5nSGVpIFwsc2Fucy1zZXJpZiI7DQoJcGFub3NlLTE6 MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJZm9udC1zaXplOjEwLjVwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJZm9udC1zaXplOjkuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6U2ltU3VuOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4u SFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlNlZ29lIFVJIixzYW5zLXNlcmlmO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFt ZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KcC5hLCBsaS5hLCBkaXYuYQ0KCXttc28tc3R5bGUtbmFtZTrmibnms6jmoYbmlofm nKw7DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJZm9udC1z aXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpi bGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+VGhlIHNpZ25hbCBjaGFubmVsIGRyYWZ0IGRvZXMgbm90 IG1hbmRhdGUgY2VydGlmaWNhdGVzIGZvciBtdXR1YWwgYXV0aGVudGljYXRpb24gKFVzaW5nIGFu IEFBQSBzZXJ2ZXIgaXMgb25seSBhbiBleGFtcGxlIGRlcGxveW1lbnQpLiBET1RTIGFnZW50cyBp biB0aGUgc2FtZSBkb21haW4gY2FuIHVzZSBvdGhlciBtZWNoYW5pc21zDQogbGlrZSBUTFMtUFNL IGFuZCBTUEtJLiBBbmRyZXcgYW5kIEkgYW0gcGxhbm5pbmcgcHV0IHVwIGEgZHJhZnQgb24gRE9U UyBwcm92aXNpb25pbmcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij4tVGlydTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxF bmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBz dHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPmthbmFtZSBuaXNoaXp1a2E8YnI+DQo8Yj5TZW50Ojwv Yj4gRnJpZGF5LCBTZXB0ZW1iZXIgMjksIDIwMTcgNjowMiBBTTxicj4NCjxiPlRvOjwvYj4gS29u ZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVl LmNvbSZndDs7IFhpYWxpYW5nIChGcmFuaykgJmx0O2ZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb20m Z3Q7OyBEb3RzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRG90c10gYW5vdGhl ciBvcHRpb246Ly88L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBKaGVuZ0hlaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndpbmRvd3RleHQiPuetlOWkjTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij46IENhbiBET1RTIHByb3RvY29sIHN1cHBvcnQgSVAgd2hp dGVsaXN0IGZvcg0KIERPVFMgY2xpZW50J3MgQUE/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4 dC1hbGlnbjpsZWZ0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgVGlydSw8YnI+DQo8YnI+DQppbiBzZWN0 aW9uIDkgb2Ygc2lnbmFsLWNoYW5uZWwgZHJhZnQsIEFBQSBzZXJ2ZXIgZXhpc3RzLjxicj4NCkxl dCBtZSBjbGFyaWZ5IHRoZSB0ZXh0Ljxicj4NCjxicj4NCk11dHVhbCBhdXRoZW50aWNhdGlvbiBi ZXR3ZWVuIGEgRE9UUyBjbGllbnQgYW5kIGEgRE9UUyBnYXRld2F5IE1VU1QgdXNlIChjbGllbnQp IGNlcnRpZmljYXRlcz88YnI+DQpCZXR3ZWVuIHRoZW0gKGluIHRoZSBzYW1lIGRvbWFpbiksIGEg bXV0dWFsIGF1dGhlbnRpY2F0aW9uIHdpdGhvdXQgY2VydGlmaWNhdGVzIChpLmUuIGNob2ljZXMg b3RoZXIgdGhhbiBFQVAtVExTKSB3b3VsZCBiZSBhIGdvb2Qgb3B0aW9uLCBpZiBpdCBtZWV0cyB0 aGUgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGFuZCBlbmNyeXB0aW9uIHJlcXVpcmVtZW50Ljxicj4N Cjxicj4NClRMUy1QU0sgbW9kZSBhbmQgU3ViamVjdCBQdWJsaWMgS2V5IEluZm8gKFNQS0kpJm5i c3A7IGxvb2tzIGdvb2QgdG8gbWUuPGJyPg0KPGJyPg0KSSBob3BlIHRob3NlIG9wdGlvbnMgd291 bGQgYmUgZGlzY3Vzc2VkIGluIFdHbWVldGluZy48YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIDIwMTcvMDgvMDcgMTk6MTksIEtvbmRhLCBUaXJ1bWFsZXN3YXIg UmVkZHkgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPllvdSBtYXkgd2FudCB0byBsb29rIGlu dG8gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY5NTkjc2VjdGlvbi03 Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2OTU5I3NlY3Rpb24tNzwvYT48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jmx0O3NuaXAmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNw OyBFdmVuIGlmIGV2ZXJ5IEludGVybmV0LWNvbm5lY3RlZCBuZXR3b3JrIGltcGxlbWVudHMgc291 cmNlIGFkZHJlc3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IHZhbGlkYXRpb24gYXQg dGhlIHVsdGltYXRlIG5ldHdvcmsgaW5ncmVzcywgYW5kIGFzc3VyYW5jZXMgZXhpc3QgdGhhdDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgaW50ZXJtZWRpYXRlIGRldmljZXMgYXJlIHRv IG5ldmVyIG1vZGlmeSBkYXRhZ3JhbSBzb3VyY2UgYWRkcmVzc2VzLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDsmbmJzcDsgc291cmNlIGFkZHJlc3NlcyBjYW5ub3QgYmUgdXNlZCBhcyBhbiBhdXRo ZW50aWNhdGlvbiBtZWNoYW5pc20uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4tVGlydTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGln bjpsZWZ0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4gWGlhbGlhbmcgKEZyYW5rKSBbPGEgaHJl Zj0ibWFpbHRvOmZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb20iPm1haWx0bzpmcmFuay54aWFsaWFu Z0BodWF3ZWkuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEF1Z3VzdCA3LCAy MDE3IDM6MjggUE08YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPGEg aHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20iPg0KJmx0O1Rp cnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20mZ3Q7PC9hPjsgPGEgaHJlZj0ibWFpbHRv OkRvdHNAaWV0Zi5vcmciPkRvdHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IDwv c3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6RGVuZ1hpYW4iPuetlOWkjTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ OiBhbm90aGVyIG9wdGlvbjovLzwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6RGVuZ1hpYW4iPuetlOWkjTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+Og0KIENhbiBET1RTIHByb3RvY29sIHN1cHBvcnQgSVAgd2hp dGVsaXN0IGZvciBET1RTIGNsaWVudCdzIEFBPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQt YWxpZ246bGVmdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgVGlydSw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtz IGZvciB5b3VyIGFuYWx5c2lzLiBJdCBtYWtlcyBzZW5zZSB0byBtZX5+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UbyBiZSBhY2N1cmF0ZSwgSVAgd2hpdGVsaXN0IGRvZXMg bm90IHJlbGF4IHRoZSBtdXR1YWwgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnQsIGJ1dCBpbmRl ZWQgbG9zZSB0aGUgZW5jcnlwdGlvbiBiZW5lZml0cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkIuUi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RnJhbms8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjps ZWZ0Ij48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6U2ltU3VuIj7lj5Hku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4gS29uZGEsDQogVGlydW1hbGVzd2Fy IFJlZGR5IFs8YSBocmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNv bSI+bWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208L2E+XQ0KPGJyPg0K PGI+PHNwYW4gbGFuZz0iWkgtQ04iPuWPkemAgeaXtumXtDwvc3Bhbj46PC9iPiAyMDE3PHNwYW4g bGFuZz0iWkgtQ04iPuW5tDwvc3Bhbj44PHNwYW4gbGFuZz0iWkgtQ04iPuaciDwvc3Bhbj43PHNw YW4gbGFuZz0iWkgtQ04iPuaXpTwvc3Bhbj4gMTc6NTE8YnI+DQo8Yj48c3BhbiBsYW5nPSJaSC1D TiI+5pS25Lu25Lq6PC9zcGFuPjo8L2I+IFhpYWxpYW5nIChGcmFuayk7IDxhIGhyZWY9Im1haWx0 bzpEb3RzQGlldGYub3JnIj4NCkRvdHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+PHNwYW4gbGFuZz0i WkgtQ04iPuS4u+mimDwvc3Bhbj46PC9iPiBSRTogYW5vdGhlciBvcHRpb246Ly88c3BhbiBsYW5n PSJaSC1DTiI+562U5aSNPC9zcGFuPjogQ2FuIERPVFMgcHJvdG9jb2wgc3VwcG9ydCBJUCB3aGl0 ZWxpc3QgZm9yIERPVFMgY2xpZW50J3MgQUE/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1h bGlnbjpsZWZ0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UTFMgc3VwcG9ydHMgcHJlLXNoYXJlZCBrZXkg YmFzZWQgYXV0aGVudGljYXRpb24uIFRoZSBvdGhlciBtZWNoYW5pc21zIGFyZSBTdWJqZWN0IFB1 YmxpYyBLZXkgSW5mbyAoU1BLSSkgRmluZ2VycHJpbnQgcGluIHNldCBmb3IgbXV0dWFsIGF1dGhl bnRpY2F0aW9uIChzZWxmLXNpZ25lZCBjZXJ0aWZpY2F0ZXMgb3IgcmF3IHB1YmxpYyBrZXlzKSB3 aXRob3V0DQogaGF2aW5nIHRvIGRlYWwgd2l0aCBDQS4gJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGRvbuKAmXQgdGhpbmsgRE9UUyBzaG91bGQgcmVs YXggdGhlIG11dHVhbCBhdXRoZW50aWNhdGlvbiBhbmQgZW5jcnlwdGlvbiByZXF1aXJlbWVudHMu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tVElydTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4gRG90cyBbPGEgaHJlZj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZyI+ bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlhp YWxpYW5nIChGcmFuayk8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgNywgMjAxNyA2 OjI1IEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86RG90c0BpZXRmLm9yZyI+RG90 c0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0RvdHNdIGFub3RoZXIgb3B0aW9u Oi8vPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpTaW1TdW4iPuetlOWkjTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+OiBDYW4gRE9UUyBwcm90b2NvbCBzdXBwb3J0IElQIHdoaXRlbGlzdCBmb3IgRE9UUyBjbGll bnQncyBBQT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkluIGFkZGl0aW9uIHRvIElQIHdoaXRlbGlzdCBhbmQgY2VydGlmaWNhdGUsIHByZS1z aGFyZSBrZXkgY2FuIGFsc28gYmUgYW4gb3B0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SaWdodD88L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHls ZT0idGV4dC1hbGlnbjpsZWZ0Ij48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj7lj5Hku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Ojwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4gRG90cw0K IFs8YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZG90cy1ib3Vu Y2VzQGlldGYub3JnPC9hPl0gPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuS7o+ihqA0KPC9zcGFuPjwv Yj5YaWFsaWFuZyAoRnJhbmspPGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuWPkemAgeaXtumX tDwvc3Bhbj46PC9iPiAyMDE3PHNwYW4gbGFuZz0iWkgtQ04iPuW5tDwvc3Bhbj44PHNwYW4gbGFu Zz0iWkgtQ04iPuaciDwvc3Bhbj43PHNwYW4gbGFuZz0iWkgtQ04iPuaXpQ0KPC9zcGFuPjg6NTI8 YnI+DQo8Yj48c3BhbiBsYW5nPSJaSC1DTiI+5pS25Lu25Lq6PC9zcGFuPjo8L2I+IDxhIGhyZWY9 Im1haWx0bzpEb3RzQGlldGYub3JnIj5Eb3RzQGlldGYub3JnPC9hPjxicj4NCjxiPjxzcGFuIGxh bmc9IlpILUNOIj7kuLvpopg8L3NwYW4+OjwvYj4gW0RvdHNdIENhbiBET1RTIHByb3RvY29sIHN1 cHBvcnQgSVAgd2hpdGVsaXN0IGZvciBET1RTIGNsaWVudCdzIEFBPzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIg c3R5bGU9InRleHQtYWxpZ246bGVmdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhp bmsgdGhlIGRpcmVjdCB1c2Ugb2YgSVAgd2hpdGVsaXN0IG9uIHRoZSBET1RTIHNlcnZlciB0byBh dXRoZW50aWNhdGUgYW5kIGF1dGhvcml6ZSB0aGUgRE9UUyBjbGllbnQgaXMgYSBzaW1wbGUgYW5k IGVmZmVjdCBtZXRob2QsIGF0IGxlYXN0IGluIHNvbWUgc3BlY2lhbCB1c2UgY2FzZXMsIGxpa2U6 IERPVFMgY2xpZW50IGRvZXMgbm90IHN1cHBvcnQgY2VydGlmaWNhdGUsIGFuIElTUCB3aGljaCBk ZXRlY3RzDQogdGhlIHNwb29mZWQgc291cmNlIGFkZHJlc3MsIGV0Yy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U28sIHNob3VsZCB3ZSBzdXBwb3J0IHRoaXMgYXMgYW4gb3B0aW9uYWwgd2F5IGZv ciB0aGUgRE9UUyBjbGllbnTigJlzIEFBIGFuZCBhZGQgaXQgaW50byB0aGUgRE9UUyBwcm90b2Nv bCBkcmFmdHM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkIuUi48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkZyYW5rPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZiI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkRvdHMgbWFpbGluZyBsaXN0PG86cD48L286cD48L3By ZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOkRvdHNAaWV0Zi5vcmciPkRvdHNAaWV0Zi5vcmc8L2E+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kb3RzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RvdHM8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_DM5PR16MB17880DA8BDE932F1A758E27AEA7E0DM5PR16MB1788namp_-- From nobody Thu Sep 28 22:05:45 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EC81344F6 for ; Thu, 28 Sep 2017 22:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yedrZnHsG-8G for ; Thu, 28 Sep 2017 22:05:41 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E181344E7 for ; Thu, 28 Sep 2017 22:05:40 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1506661539; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=WZqNdqjQu5NiheGc+iNKoRjSSZt/qMqArZSDVj TWTIc=; b=XSsV3e8tBGA63Yduir/0+nk0poxsH4AZt7fylrN+ BZZmP2FIehXL/0pyF+qXqw/yXACxCJ2+s67U19kWfPJ1/jkNeO 0Z0Xi6ayxMiN2WR7aHdCGRvfB1rOVUA2Z4dUTEPmCnfEWQXKGZ BQUQR4Aqi7ihZPIiNSG1MpIZ7HCus+I= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 2216_35ec_387a67c1_bf7f_42e9_8cfb_fbd54ff990e2; Fri, 29 Sep 2017 00:05:39 -0500 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 28 Sep 2017 23:05:15 -0600 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 28 Sep 2017 23:05:13 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Thu, 28 Sep 2017 23:05:14 -0600 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 28 Sep 2017 23:05:13 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 29 Sep 2017 05:05:11 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.011; Fri, 29 Sep 2017 05:05:11 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Coding and Interoperability Challenges Thread-Index: AQJWDLbdGWgIliMeta88DlSb7Xyh6wERxjbqobjAfoCAAAa5EIAEUaKA Date: Fri, 29 Sep 2017 05:05:11 +0000 Message-ID: References: <062f01d336b7$966e9160$c34bb420$@jpshallow.com> In-Reply-To: <062f01d336b7$966e9160$c34bb420$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.220.42] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:/GdSqB6cUW4LZUZnSaTo2iHbx5+JLFdXBTO98nENjJzjNVeXmHQruG9lzhzk6UWHg8E41O4qxPoneF1LzQQYQ1pXqiTyfsft7PFETKPAESqqgAQV5PyQHFytnpGMRO2VsWKHAPPeyQwl8tL5HBy1unFaugY4ZwrC/jzeD2HF23/FzMigN6L0ZEX7njQkSzHGIAMgyyikz6sqx9oGRR/btsCHbYIr2Esm+vQU8WwlkN1gUsOe7W75WpdQ+2ri7JkffucUTdpJCabFzNf9NytZfaeHC8UZ/DzNMvD9zueRkkM5TYcfpb6xKSVtWOqb4Am98MldJ+Kx96fFi7+aN9do0Q==; 5:9y/pvLfoQkTQdobwkxA11jqQ6NQMnUUH27LNUuESiFpdR5akfqUb+noMyL0VVlif2Ziq993uwuXtj5A7sqXUTfCqtDLyU2oojM/A2QgtglunKVyvRhpYHYGLNbdUxkQP01sHshzpYZ63JwMw2HsZKulneuavAkBbY+gt9bqDYDg=; 24:LvxzPNCadws6UMFZFAlwUHN+SwSQpf29l+JWgmK/BlteLNFnU0wFXOw/OfyTw/P8c3PwDfTpu8xvWalwfq3r6FGHPnx6gLEDM9iry2XZRas=; 7:tzJKjFyQY4j1yR/nKw0szm19/mFA/1SkXOctPZ3PIoWUJYA5zIvsR3lxrHq0sc93or/2UL9Tmb8kIY4fz7gaPLwzhKZk0bL8TjakM1qxftXQdfvyjFyG5ycBjzCXE5Y12Rg2zBy9233My3XCpr0Km182TTqsCB4Tex2eP04FcSf/Ap4yEEWt5UOhlr1xAFw0KA6vpHWJOSQ0tICm5f+4yp6tePfwFgGvnLWIf+xF/zs= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fb3938fb-835e-46ec-feb3-08d506f7a9c9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(79290750141951); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0445A82F82 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(39830400002)(346002)(52084003)(51444003)(57704003)(199003)(377454003)(32952001)(189002)(13464003)(51914003)(189998001)(99286003)(6246003)(53546010)(66066001)(5660300001)(2900100001)(2906002)(6306002)(86362001)(68736007)(81166006)(6506006)(53936002)(7696004)(14454004)(110136005)(101416001)(81156014)(478600001)(9686003)(102836003)(3280700002)(3660700001)(25786009)(72206003)(6116002)(2950100002)(53946003)(55016002)(16200700003)(15974865002)(305945005)(74316002)(2501003)(966005)(8936002)(7736002)(105586002)(77096006)(50986999)(8676002)(3846002)(80792005)(229853002)(33656002)(76176999)(6436002)(54356999)(316002)(106356001)(97736004)(21314002)(85282002)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2017 05:05:11.6506 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.5 X-NAI-Spam-Version: 2.3.0.9418 : core <6126> : inlines <6099> : streams <1765068> : uri <2508332> Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 29 Sep 2017 05:05:44 -0000 Hi Jon, Thanks for the detailed review. We plan to update the draft and respond to = your comments asap. Cheers, -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Tuesday, September 26, 2017 4:37 PM > To: dots@ietf.org > Subject: Re: [Dots] Coding and Interoperability Challenges >=20 > Hi there, >=20 > I now have implemented a working DOTS Server supporting the signal > channel over UDP and is CoAP TCP ready. The data channel work has still = to > be done. > The DOTS Client is still a work in progress, but was used to test the DOT= S > server. This however has highlighted some vague, open to interpretation, > definitions in the signal spec draft-ietf-dots-signal-channel-03, several= of > which I have previously raised. >=20 > If there is insufficient time to address the issues before the virtual me= eting > on 2nd October, then it may make sense to discuss them at that meeting. >=20 > Given the interrelation of the draft IETF dots documents, other RFCs, the= re is > a reasonable chance that I may have misinterpreted something, or not > realised as consequence of what needs to be done. >=20 > The following is not in order of importance - it is following the signal > specification order. Instead of getting bogged down in a section, skip i= t and > read the other sections and come back to the one you are having trouble > with - the wider context may help you. In particular, Sections covering = 5.1 > may need to be initially skipped. >=20 >=20 > draft-ietf-dots-signal-channel-03 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > 5.1 Overview (1) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > In general, what should be in, or could be expected in the response is no= t > that clear. This should be tightened up - this section 5.1 with a new > penultimate paragraph at the end of this section may be a good place. Th= e > following comments / descriptions in this section highlight some areas th= at > have raised concerns. >=20 > Original: (End of section 5.3.1) "For responses indicating a client or se= rver > error, the payload explains the error situation of the result of the requ= ested > action (Section 5.5 in [RFC7252])." >=20 > [RFC 7572 5.5 Payloads and Representations Both requests and responses > may include a payload, depending on the Method or Response Code, > respectively. If a Method or Response Code is not defined to have a payl= oad, > then a sender MUST NOT include one, and a recipient MUST ignore it.] >=20 > If the response is not 2.xx, is the diagnostic message that is sent back = a CoAp > Diagnostic Message with no content format and a simple plain-text message > (RFC 5.5.2 Diagnostic Payload)? >=20 > If so, what happens with the 4.22 (Unprocessable Entity) response in 5.4.= 1 > which states the acceptable values - which are encoded in CBOR? > - I think this should be a Diagnostic Payload response (perhaps with the = bad > value), thus inviting the DOTS Client to (re-)do a GET Request to discove= r the > valid values. > - It is also not possible to determine which is the value that has failed= with > just the current defined payload response - whereas a Diagnostic message > can give a hint as to the failing value. >=20 > In 5.3.1, the only thing mentioned for a successful PUT response is the > "lifetime" parameter is required. It is unclear whether the rest of the > parameter/values that were part of the PUT request should also be in the > response. What should be returned? >=20 > Suggested update to 5.1 to handle "RFC 7572 5.5 Payloads and > Representations" sandwiched between 2 Originals to set the context:- >=20 > Original: ". Mitigation remains active until the DOTS client explicitly > terminates mitigation, or the mitigation lifetime expires." >=20 > New Addition: "The following CoAP requests and responses MUST be > supported by the DOTS agents. >=20 > +------------+-------------+ > |Method Code |Usage | > +------------+-------------+ > |0.00 |Heartbeat | > |0.01 |GET | > |0.03 |PUT | > |0.04 |DELETE | > +------------+-------------+ > Figure XXX: Supported CoAP Method Codes" >=20 > All CoAP responses with codes that are 2.xx MUST have a CoAP payload, > content type "application/cbor" that is a "resource representation" [RFC7= 252 > 5.5.1 Representation]. >=20 > All CoAP responses with codes that are not 2.xx MUST be a Diagnostic > Payload > [RFC7252 5.5.2 Diagnostic Payload] with no content type. The Diagnostic > Payload can contain additional information to aid troubleshooting. >=20 > +-------------+---------------------+----------+-------+ > |Response Code|Usage |Diagnostic|Payload| > +-------------+---------------------+----------+-------+ > |2.01 |Created |No |Yes | > |2.02 |Deleted |No |Yes | > |2.04 |Changed |No |Yes | > |2.05 |Content |No |Yes | > |3.00 |Alternative Server |No |Yes | > |4.00 |Bad Request |Yes |No | > |4.01 |Unauthorized |Yes |No | > |4.02 |Invalid Query |Yes |No | > |4.04 |Not Found |Yes |No | > |4.22 |Unprocessable Entity |Yes |No | > |5.00 |Internal Server Error|Yes |No | > |5.02 |Bad Gateway |Yes |No | > |5.03 |Service Unavailable |Yes |No | > |5.04 |Gateway Timeout |Yes |No | > +-------------+---------------------+----------+-------+ > Figure XXX: Supported CoAP response Codes " >=20 > Original: "Messages exchanged between DOTS client and server are > serialized ..." >=20 >=20 > 5.1 Overview (2) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Nowhere is mentioned what ports should be used. RFC7252 suggest a > default of 5684/udp for CoAP DTLS. draft-ietf-core-coap-tcp-tls suggests > 5684/tcp. >=20 > Should this be stated? >=20 >=20 > 5.1 Overview (3) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > No mention is made of doing any signal channel recovery if a DOTS agent > restarts for any reason. Things potentially could get out of sync unless= there > is some functionality to make sure that information held by each DOTS age= nt > is properly synchronized (even if it a simple "flush out all that you kno= w"). >=20 >=20 > 5.3.1 Requesting Mitigation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Original: ". The relative order of two mitigation requests from a DOTS cl= ient is > determined by comparing their respective mitigation-id values. If two > mitigation requests have overlapping mitigation scopes the mitigation > request with higher numeric mitigation-id value will override the mitigat= ion > request with a lower numeric mitigation-id value." >=20 > This raises several implementation questions. >=20 > Question 1 > ---------- > Say a PUT mitigation-id with a value of #99 is followed by a PUT mitigati= on-id > of #100 which overlaps, so #99 is ignored/overridden. Then there is a DE= LETE > #100. Do we revert back to #99? >=20 > If yes, then do we need to remember #1 through #98 to revert back to them > if needed - the logical extension of this is remembering all 2^31 entries= - > which probably is a DOS attack. >=20 > My suggestion would be that #99 is dropped/deleted if #100 overlaps, and > the subsequent deleting #100 withdraws that particular mitigation and so > mitigation stops. The new wording could be:- >=20 > Replacement: "The relative order of two mitigation requests from a DOTS > client is determined by comparing their respective mitigation-id values. = If > two mitigation requests have overlapping mitigation scopes the mitigation > request with higher numeric mitigation-id value will override the mitigat= ion > request with a lower numeric mitigation-id value. The overlapped lower > numeric mitigation-id is automatically deleted and no longer available fo= r > querying against." >=20 > Question 2 > ---------- > It is unclear as to how this overlapping works, say with #99 target-ip > [1.1.1.1,1.1.1.2] and #100 target-ip [1.1.1.2,1.1.1.3]. Is it correct tha= t > 1.1.1.1 should no longer be mitigated, but 1.1.1.3 should start? >=20 > What about overlapping protocols, but not overlapping target-ips etc? >=20 > Question 3 > ---------- > If there is an overlap, why cannot both mitigation scopes (both lower and > higher mitigation-ids) still continue? >=20 > Question 4 > ---------- > Handling mitigation request refreshes. > When the lifetime expires with the active mitigation-id, the mitigation s= tops > unless there is a refreshed mitigation request of some sort. Does the re= fresh > mitigation request to keep the mitigation going use the same mitigation-i= d, > or must it be a new (incremented?) mitigation-id? >=20 > If the refresh requires a new incremented id, then this will wrap at some > point and the "mitigation request with higher numeric mitigation-id value= will > override" test will fail. >=20 > Original: "If the DOTS server finds the mitigation-id parameter value > conveyed in the PUT request in its configuration data then the server MAY > update the mitigation request, and a 2.04 (Changed) response is returned = to > indicate a successful update of the mitigation request." >=20 > This implies the same mitigation-id is used for doing the refresh. > My suggestion is to add in a new paragraph at the end of section 5.3.1 fo= r > clarity. >=20 > New: "For mitigation to continue beyond the initial negotiated "lifetime"= , the > DOTS client will need to refresh the current mitigation request by sendin= g a > new PUT request. The PUT request SHOULD use the same "mitigation-id", > and SHOULD repeat all the other parameters as sent in the original mitiga= tion > request apart from a possible change to the "lifetime" > parameter. The DOTS server MAY refuse the refresh request if any of the > request parameters (apart from "lifetime") have changed." >=20 > Question 5 > ---------- > When the PUT is refreshed with the same mitigation-id by the client at so= me > point before the lifetime expires, if the signal mitigate content (e.g. > target-protocol is changed) is sent by the client, should this be allowed= , > ignored or rejected? >=20 > My suggestion is in the "New:" update under Question 4 just above. >=20 > Question 6 > ---------- > As Scope has been defined as an array, are multiple mitigation-ids allowe= d > with a single PUT request? > - I think only one should be allowed. The replacement is for the mitigat= ion-id > definition - the addition is at the end. >=20 > Replacement: "mitigation-id: Identifier for the mitigation request > represented using an integer. This identifier MUST be unique for each > mitigation request bound to the DOTS client, i.e., the mitigation-id para= meter > value in the mitigation request needs to be unique relative to the mitiga= tion- > id parameter values of active mitigation requests conveyed from the DOTS > client to the DOTS server. This identifier MUST be generated by the DOTS > client. This document does not make any assumption about how this > identifier is generated. This is a mandatory attribute. There can only = be one > mitigation-id request per Scope per single PUT request." >=20 >=20 > 5.3.2 Withdraw a DOTS Signal > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Can multiple mitigation-ids be sent in a single DELETE request (scope is = an > array)? >=20 > What gets sent back in the payload? >=20 > If the mitigation-id found, then that can easily be the mitigation-id > information. >=20 > If not found, is there no payload, or should there be an empty scope arra= y > something like { > "mitigation-scope": { > "scope": [ > ] > } > } >=20 > We need to define what the client will expect (especially if it is going = to make > a decision on a 2.02 response for a non-existent mitigation-id). >=20 > My suggestion is to add in a new paragraph at the end of this section. >=20 > New: "Multiple mitigation-ids MAY be included in the DELETE "scope". The > "resource representation" response payload always includes "mitigation- > scope" and "scope" with zero or more mitigation-ids that were found and > deleted. If the DELETE is repeated for one or more mitigation-ids during= the > active-but-terminating period, then the matching mitigation-ids continue = to > get returned." >=20 >=20 > 5.3.3 Retrieving a DOTS Signal (1) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > When/what to send back an unsolicited response when running with an > Observe. > Some questions that need to be answered. >=20 > When "observe" is set to 0, should the DOTS server send back an unsolicit= ed > information / status update > a) whenever there is a "status" parameter change > b) when there is a change to one of the "*-dropped" parameters > c) send a response at some regular time interval? > - Figure 10 implies it is just on a "status" parameter change. >=20 > If at a regular interval (c), should this be a configurable value (as per > configuration under 5.4?) or a defined fixed value? >=20 > What should the recommended frequency of update be (1 per n seconds")? >=20 > If Observe is not used to set up a regular frequency update, and therefor= e it > is the responsibility of the DOTS client to poll as required (perhaps for > graphing the data), should the DOTS Client set the Observe option (which = will > set up/cancel either (a) or (b) above) when polling? > -If Observe is set to 1 during the polling, then it will cancel any notif= ications > set up. >=20 > Is Observe a MUST with a signal GET? > - All examples have this Observe option included in Figure 10 >=20 > I think that adding in an extra parameter "refresh-rate" would help here = if > there is to be a continuous refresh of information. However, this would = only > work for the explicit "mitigation-id" request. Alternatively, the generic > request (no payload) could be replaced with one where the mitigation-id i= s -1 > (following the same usage as the challenges over using the GET configurat= ion > signal-id in 5.4.1). Thoughts? >=20 >=20 > 5.3.3 Retrieving a DOTS Signal (2) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > There is inconsistency in the definition of the "mitigation-scope" parame= ter > - it is either an object/map or an array (for the responses back from the= GET > with no payload). The usage needs to be consistent throughout the > specification to avoid errors creeping in. >=20 > As "scope" is an array, then the multiple responses should be:- >=20 > Replacement: " > { > "mitigation-scope":{ > "scope": [ > { > "mitigation-id": 12332, > "target-protocol": [ > 17 > ], > "lifetime":1801, > "status":2, > "bytes-dropped": 134334555, > "bps-dropped": 43344, > "pkts-dropped": 333334444, > "pps-dropped": 432432 > }, > { > "mitigation-id": 12333, > "target-protocol": [ > 6 > ], > "lifetime":1749, > "status":3, > "bytes-dropped": 0, > "bps-dropped": 0, > "pkts-dropped": 0, > "pps-dropped": 0 > } > ] > } > } > " >=20 >=20 > 5.3.3 Retrieving a DOTS Signal (3) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > "bytes-dropped" and "pkts-dropped". Are these counters from the start of > the original initial PUT mitigate requests, or are these reset to 0 whene= ver > there is a PUT mitigate refresh? >=20 > My inclination is to go with the count from the initial PUT mitigate requ= est > (with a potential wrap around for long mitigations). >=20 > It is possible that a DOTS client may have been restarted, but the mitiga= tion > request continues for the remainder of the lifetime > Replacement: "bytes-dropped: The total dropped byte count for the > mitigation request since the mitigation was initially requested. This is= an > optional attribute. >=20 > bps-dropped: The average dropped bytes per second for the mitigation > request. This is an optional attribute. >=20 > pkts-dropped: The total dropped packet count for the mitigation request > since the mitigation was initially requested. This is an optional attrib= ute. >=20 > pps-dropped: The average dropped packets per second for the mitigation > request. This is an optional attribute." >=20 >=20 > 5.3.3 Retrieving a DOTS Signal (4) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > The "lifetime" returned value is not defined in the mitigation status > parameters. Is this the remaining time (in seconds?) of the current > mitigation request? >=20 > Replacement: "The mitigation status parameters are described below. >=20 > lifetime: The remaining lifetime in seconds of the current mitigation-id > request. >=20 > bytes-dropped: The total dropped byte count.." >=20 >=20 > 5.3.4 Efficacy Update from DOTS Client (1) > -------------------------------------- > Original: "The PUT request MUST include all the parameters used in the PU= T > request to convey the DOTS signal (Section 5.3.1)." > This also implicitly implies that this must be done in 5.3.1 as well. >=20 > What is the DOTS server supposed to do if any of the parameters (apart fr= om > perhaps "lifetime") are different - does this invoke a 4.02? >=20 > The same question is true for 5.3.1. >=20 > Replacement: "While DDoS mitigation is active, a DOTS client MAY frequent= ly > transmit DOTS mitigation efficacy updates to the relevant DOTS server. A= n > PUT request (Figure 11) is used to convey the mitigation efficacy update = to > the DOTS server. The PUT request MUST include all the parameters used in > the PUT request to convey the DOTS signal (Section 5.3.1) unchanged apart > from "lifetime". The DOTS server MUST reject the request with a 4.02 cod= e if > this is not the case. The If-Match Option (Section 5.10.8.1 of > [RFC7252]) with an empty value is used to make the PUT request conditiona= l > on the current existence of a mitigation request with the same mitigation= -id. > If UDP is used as ... >=20 >=20 > 5.3.4 Efficacy Update from DOTS Client (2) > -------------------------------------- > Original:" The 5.xx response codes are returned if the DOTS server has er= red > or is incapable of performing the mitigation." >=20 > Should there be any definitions of what 5.xx code should be used where? >=20 >=20 > 5.3.4 Efficacy Update from DOTS Client (3) > -------------------------------------- > Does a PUT with "attack-status" refresh the outstanding lifetime on the > current mitigation request? >=20 > Or is the "lifetime" parameter optional, despite the MUST statement at th= e > beginning of this session "The PUT request MUST include all the parameter= s > used in the PUT request to convey the DOTS signal (Section 5.3.1)."? >=20 > For clarity, I think the following should be added in as a paragraph at t= he end > of this section:- >=20 > New: "The current mitigation does not have the lifetime refreshed when > using a Efficacy Update PUT as per section 5.3.4, but does have the lifet= ime > refreshed when using a Mitigation Request PUT as per section 5.3.1." >=20 >=20 > 5.4 DOTS Signal Channel Session Configuration > --------------------------------------------- > Original:" a. Heartbeat timeout: DOTS agents regularly send heartbeats > (Ping/ Pong) to each other after mutual authentication in order to keep t= he > DOTS signal channel open, heartbeat timeout is the time to wait for a Pon= g in > milliseconds." >=20 > Nowhere is the frequency defined for "regular send" and should this also = be > configurable in 5.4.1? >=20 >=20 > 5.4.1 Discover Acceptable Configuration Parameters (1) > -------------------------------------------------- > Original: "A GET request is used to obtain acceptable configuration > parameters on the DOTS server for DOTS signal channel session > configuration." >=20 > So, when making a configuration change, is this specific to the Signal Ch= annel > between the DOTS Server and DOTS client, or is it specific to each CoAP > session where potentially there could be multiple sessions for the same > signal channel? >=20 > Replacement: ""A GET request is used to obtain acceptable configuration > parameters on the DOTS server for current session using the DOTS signal > channel." >=20 >=20 > 5.4.1 Discover Acceptable Configuration Parameters (2) > -------------------------------------------------- > Figure 13. Does it also make sense to return Default values as well? > - It may make sense for these to be Current as opposed to Default values. >=20 > Replacement: "Content-Format: "application/cbor" > { > "heartbeat-timeout": {"MinValue": integer, "MaxValue" : > integer,"DefaultValue":integer}, > "max-retransmit": {"MinValue": integer, "MaxValue" : > integer,"DefaultValue":integer }, > "ack-timeout": {"MinValue": integer, "MaxValue" : > integer,"DefaultValue":integer }, > "ack-random-factor": {"MinValue": number, "MaxValue" : > number,"DefaultValue":integer } > } >=20 >=20 > 5.4.2. Convey DOTS Signal Channel Session Configuration (1) > -------------------------------------------------- > Original: "The RECOMMENDED values of transmission parameter values are > ack_timeout (2 seconds), max-retransmit (7), ack-random-factor (1.5) and > heartbeat-timeout (371 seconds)." >=20 > RFC7252 has max-retransmit set to 4, not 7. (RFC 7252 4.8 Transmission > Parameters). >=20 > With the exponential back off for retries of CON messages, using 4 gives = an > expiration of the request after about 1.5 minutes, with a value of 7 this= is > almost 10 minutes. The 10 minutes does seem excessively long to me - > especially when it is for a CON Heartbeat. > Unless there is a good reason for 7, I suggest we go with the RFC7572 > recommendations of 4. >=20 > Replacement: "The RECOMMENDED values of transmission parameter values > are ack_timeout (2 seconds), max-retransmit (4), ack-random-factor (1.5) > and heartbeat-timeout (371 seconds)." >=20 > Replacement: " > Header: PUT (Code=3D0.03) > Uri-Host: "www.example.com" > Uri-Path: "v1" > Uri-Path: "dots-signal" > Uri-Path: "config" > Content-Format: "application/cbor" > { > "signal-config": { > "session-id": 1234534333242, > "heartbeat-timeout": 30000, > "max-retransmit": 4, > "ack-timeout": 5, > "ack-random-factor": 1.5, > "trigger-mitigation": false > } > } > " >=20 >=20 > 5.4.2. Convey DOTS Signal Channel Session Configuration (2) > -------------------------------------------------- > Original: The PUT request with higher numeric session-id value over-rides= the > DOTS signal channel session configuration data installed by a PUT request > with a lower numeric session-id value." >=20 > Say a PUT session-id with a value of #99 is followed by a PUT session-id = of > #100 which overlaps, so #99 is ignored. Then there is a DELETE #100. Do= we > revert back to #99? >=20 > If yes, then do we need to remember #1 through #98 to revert back to them > if needed - the logical extension of this is remembering all 2^31 entries= - > which probably is a DOS attack. >=20 > My suggestion would be that #99 is dropped if #100 overlaps, and deleting > #100 deletes that particular session-id. The new wording would be:- >=20 > Replacement:" The PUT request with higher numeric session-id value over- > rides the DOTS signal channel session configuration data installed by a P= UT > request with a lower numeric session-id value. The overlapped lower > numeric session-id is automatically deleted and no longer available for > querying against.". >=20 > Footnote: I cannot think of any reason why there is a need to support > (incrementing) session-ids for configuring a CoAP session - am I missing > something? >=20 >=20 > 5.4.2. Convey DOTS Signal Channel Session Configuration (3) > -------------------------------------------------- > Original:"heartbeat-timeout: Heartbeat timeout is the time to wait for = a > response in milliseconds to check the DOTS peer health. This is an optio= nal > attribute." >=20 > So, heartbeat-timeout is configured in milliseconds. However, Figure 15 > example below only has a value of 30. This example value of 30 in > milliseconds is small. >=20 > Original: " > Header: PUT (Code=3D0.03) > Uri-Host: www.example.com > Uri-Path: "v1" > Uri-Path: "dots-signal" > Uri-Path: "config" > Content-Format: "application/cbor" > { > "signal-config": { > "session-id": 1234534333242, > "heartbeat-timeout": 30, > "max-retransmit": 7, > " >=20 > This needs to be updated to, say, 30000 instead of 30. >=20 > Replacement: " > Header: PUT (Code=3D0.03) > Uri-Host: www.example.com > Uri-Path: "v1" > Uri-Path: "dots-signal" > Uri-Path: "config" > Content-Format: "application/cbor" > { > "signal-config": { > "session-id": 1234534333242, > "heartbeat-timeout": 30000, > "max-retransmit": 4, > " >=20 >=20 > 5.4.2. Convey DOTS Signal Channel Session Configuration (4) > -------------------------------------------------- > Original: "Response code 4.22 (Unprocessable Entity) will be returned in = the > response if any of the heartbeat-timeout, max-retransmit, target-protocol= , > ack-timeout and ack-random-factor attribute values is not acceptable to t= he > DOTS server. The DOTS server in the error response conveys the minimum > and maximum attribute values acceptable by the DOTS server. The DOTS > client can re-try and send the PUT request with updated attribute values > acceptable to the DOTS server. >=20 > Content-Format: "application/cbor" > { > "heartbeat-timeout": {"MinValue": 15, "MaxValue" : 60}, > "max-retransmit": {"MinValue": 3, "MaxValue" : 15}, > "ack-timeout": {"MinValue": 1, "MaxValue" : 30}, > "ack-random-factor": {"MinValue": 1.0, "MaxValue" : 4.0} } > Figure 16: Error response body > " >=20 > The 4.22 response should, I believe for consistency, only be generating a > CoAP Diagnostic response, which does not contain payload data. I think t= his > paragraph should be re-worded to be consistent in the CoAP responses: >=20 > Replacement:"Response code 4.22 (Unprocessable Entity) will be returned i= n > the response if any of the heartbeat-timeout, max-retransmit, target- > protocol, ack-timeout and ack-random-factor attribute values are not > acceptable to the DOTS server. On receipt of the 4.22 response, the DOTS > client should re-request the maximum and minimum parameters acceptable > by the DOTS server as described in 5.4.1. The DOTS client can re-try and= send > the PUT request with updated attribute values acceptable to the DOTS > server. > If the DOTS client receives 3 responses of 4.22 in a row on the same sess= ion, > the DOTS client MUST stop trying to configure the session to prevent a > continuous retry loop." >=20 >=20 > 5.4.2. Convey DOTS Signal Channel Session Configuration (5) > -------------------------------------------------- > If a DOTS client wants to re-alter the session configuration with a subse= quent > PUT, should this use the same session-id? >=20 >=20 > 5.4.4. Retrieving DOTS Signal Channel Session Configuration > ----------------------------------------------------------- > Unlike the signal GET, it is not possible to get the current configuratio= n unless > the session-id is known, but the session-id can only be created by a PUT,= at > which point the configuration is already known and can be confirmed by th= e > GET. >=20 > As signal-id cannot easily be guessed unless hard coded in the DOTS clien= t, a > suggestion is that a session-id of -1 allows you to determine the current > configuration. As "signal-config" is not an array, it is not be possible= to return > multiple session-ids, but possibly the session-id of the current configur= ation > could be returned in the payload response to a session-id of -1. A new > paragraph at the end of this section. >=20 > New: "If "session-id" is set to -1, then the current signal configuration= is > returned. If the session has previously been configured, then the > appropriate session-id is returned with the current configuration paramet= ers, > otherwise -1 is returned for the session-id along with all the default > configuration parameters." >=20 >=20 > 5.6 Heartbeat Mechanism > ----------------------- > The frequency of the heartbeats is not mentioned. This should be > configurable in 5.14.2 and have a default value / max-min boundaries > discoverable in 5.4.1 or 5.4.4 or have a recommended fixed value. >=20 > My preference is that it should be configurable as one of the signal chan= nel > session configuration parameters, with a default value of 10 seconds. >=20 > e.g. to be inserted in the appropriate places. >=20 > "heartbeat-refresh": {"MinValue": 2, "MaxValue" : 60}, > heartbeat-refresh: Heartbeat refresh rate in seconds. This is an optio= nal > attribute. >=20 >=20 > 6 Mapping parameters to CBOR (1) > ---------------------------- > It is possible additional parameters may need to be added to this table -= e.g. > DefaultValue and heartbeat-refresh. >=20 >=20 > 6 Mapping parameters to CBOR (2) > ---------------------------- > If a client does not use the mapping parameters in a request, how should = the > DOTS server send back any responses - CBOR mapping encoded or just > encoded as strings? >=20 > Should an endpoint refuse to access non CBOR mapping encoded strings? >=20 > Replacement: "All parameters in the payload in the DOTS signal channel > MUST be mapped to CBOR types as follows and are given an integer key to > save space. The recipient of the data MAY reject the information if it i= s not > suitably mapped." >=20 >=20 > 6 Mapping parameters to CBOR (3) > ---------------------------- > What happens if a sender uses CBOR mapping that are not defined in the > signal channel specification? > - If additional ones are needed in the future, then there will need to be= a > protocol version increase (from v1 to v2). >=20 > New: "A DOTS agent MUST not use any additional Mapping parameters that > are not defined in Figure 21." >=20 >=20 > 10.2.2 Initial Registry Contents > -------------------------------- > It is possible additional parameters may need to be added to this table -= e.g. > DefaultValue and keepalive-refresh. >=20 >=20 > 11.1 nttdots > ------------ > When testing against the nttdots server / client, the following issues we= re > found:- >=20 > CBOR mapping is not in use - it is using the original strings. >=20 > COAP path requires /.wellknown/ in the UriPath. >=20 > Data Channel uses CBOR/COAP, not RESTCONF (already documented in DOTS > signal > draft) >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Regards >=20 > Jon >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Sep 28 23:05:08 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1181344F3 for ; Thu, 28 Sep 2017 23:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfsZQeBokqdx for ; Thu, 28 Sep 2017 23:05:04 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0105.outbound.protection.outlook.com [104.47.40.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4959713219E for ; Thu, 28 Sep 2017 23:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TPMnTUpjsaFUXftuRE4MyMh27jnrfFtphPUT3K1L0fQ=; b=hfA5qhnGdbEk+4H7AmtFVTTWU3ohyZQvxNDNq426vp3mnL1NhjHwtpO9ZBu+enGEgyc8ApI8jExwk4x0s3zYs95hEhQAyapkCtjp3pn2YrqOMnfUIEPENa5uSWseKb/odYGo7qwctjHHJlnVhpnOrAxJpT4KdsI3MpvmpDFlCo4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; Received: from [172.19.254.101] (184.82.231.92) by BY1PR0101MB1029.prod.exchangelabs.com (2a01:111:e400:5005::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 29 Sep 2017 06:05:01 +0000 From: "Roland Dobbins" To: Xialiang Cc: "Dots@ietf.org" Date: Fri, 29 Sep 2017 13:04:47 +0700 Message-ID: <993069A8-B670-4FA8-98E6-7A960654A8FA@arbor.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5419) X-Originating-IP: [184.82.231.92] X-ClientProxiedBy: SG2PR06CA0108.apcprd06.prod.outlook.com (2603:1096:3:14::34) To BY1PR0101MB1029.prod.exchangelabs.com (2a01:111:e400:5005::26) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fe8a16be-8de4-42d9-a2cf-08d507000626 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BY1PR0101MB1029; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 3:kLEQuITTIevCIyvkkQggsm3XhnKmmwxrrsZIrgzHDzAZ3V4OTdcUDuKcuJ0ErV3uGFVXABVLjbeBc+kVb+h0veE6wf402OlJiSQJrDnl6Q/2769JYRv1pQ4gl1led1hmK4KVZHe5P7myJ0AqDVjX56YN5y7AoMw336xlmv/AgTKuQNfLFsMZ8u0ecSdTx/dfBvg9aCSwDA3JCBE1Oy4JzenDKweGSzXrBm2dCNgVVSBtF5Kv4v7nSmyzEfK54PV/; 25:ira41+MJzL2XXGfLSdfwxHvuGfGJ1/2Ry4xrd9/zP5S6fRUpGlZu78bwGSitzy/sVSbgNZk9fqM6QfCFpKtYrtbxEPpujvsZZlh1NGmFsmbk+Cz4bKWJcXFkn5Oiow/AgqCjEtZecrPywILYWGTmhej36wZTh18Tuasaj01Px5B7Rq5jf6eaLNZIqVWdw3XBRkqSZXqrQbJo8IU3XiPmkWxHr0COd5abzSlzYDCh33ISsk3Dk/qipRUzORN1b503i8EbFY2OcaeJbqxP4PkZjGkys1Y7KNOodJ4b65rwIEDlUj8yqBB1afUbBoXICpTpov42haVROg1l4VLwgNWAIw==; 31:Jh8dge/4FT+E/dYXPOLtraw1BqOE5SIrlVKHSQLEl5UWxUwrHAmYN8LMtVZdQvsNQe4VOjzCzcsYTETbgWd1mm4AMCHl7NwlU/r9SY3gs6TlxXs/zjLVIedg9oMDsvWiMTRKAIuhVqrlcT3L7R/F+lbMF5Qcs/woXf7qA+peDVUIL9u1Bef1hFzrxOU2FYgLR5gdpirxLeTuh5cgqHvs6JK5HM9BErU3+u5nzuaKrtE= X-MS-TrafficTypeDiagnostic: BY1PR0101MB1029: X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 20:Ig8evUpCfxfqdVIu/NpVpMg971ZlWUS6Dfhn/qJJcBvsMfY2uhBJvAM7hjymAsBKPut4Qzrd/Mdm8mY6+y74taDmZEJRBS3rU0PEiR2d1zpuuH83GH2Pix5DOMR6pTuWo2Fma0fAgWBUmxLVYx6tFWD6iWeNYBROrBvUCs05hBJbHyDcoWRDaAWWhKYK6nEYZMyTbwmcDnVsXMXpDgbGxNIxFjqactrTuFvmakfPw9sx9Li35/si5M+1OwDRGPNAVjzZrtF9/RShSuzhkYedu1hqxvQI/MeyrIijuDzlOXVF49R83nhgMBWXUmTjd74Ieus6lcPLzRZ6kZzW1mMwAW7+f9Ht0wDJHHOl8yj47weW4U8MTQ/NWVsoptNVq3o0wiECZ9plPLsuxynGphCyZnGWH7skuFeLV/Bj6iO1MYHsy01ibyt4h0FPo0YmQLLnPWYHoX0mbCj6XfAanlw/eynS4cS98jvE5u8YRAxj3H0jGEHul7BR+vriW8Jm1p7J; 4:sQm5A6B/qsk5dcNlU6kzij1QborQ20qB9jzc5tDeAgUGp0ssJ6rc62EeMSDigNvLBSn+0qHlzN4Z2TWyQzQh04pdMEu6t+9oH3z5paWj/IEDxeIATgZ08GFHR1q5JJpep0knVdPNs16WVRv/+crsTYuBYkkVIYayKE8osBCtVOTi9ZlGRlpsD0744aXoo+roMXAHIlZ1g0PUg9lOLA7rL7uFajntXOKxFPYycsH6fyBOqBTVSSQZLq5DAEaBJmOy X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY1PR0101MB1029; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY1PR0101MB1029; X-Forefront-PRVS: 0445A82F82 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(376002)(39830400002)(346002)(24454002)(199003)(189002)(316002)(224303003)(50986999)(86362001)(33656002)(6486002)(82746002)(478600001)(16576012)(16586007)(105586002)(77096006)(47776003)(66066001)(6666003)(5660300001)(558084003)(7736002)(305945005)(189998001)(53936002)(106356001)(101416001)(5003940100001)(6246003)(53546010)(2950100002)(4326008)(83716003)(6916009)(68736007)(2906002)(50466002)(6116002)(97736004)(229853002)(3846002)(76176999)(50226002)(25786009)(8936002)(16526017)(36756003)(81166006)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0101MB1029; H:[172.19.254.101]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0101MB1029; 23:L+UqR0HvIvoM3dBOQPtQ8AuFwa1wB6InMhK4bYW?= =?us-ascii?Q?ioUHmvqd0ATBtPb2yoqlPEyVJw9lTtx4d4zWmFP+uS2lUIEMRvJx04Y6IHRr?= =?us-ascii?Q?iVkfHFTW8dA8ZoDYWH1Pi81o31NMuimSwznd4eE/xcqSvNaq6kU0uys+JM8g?= =?us-ascii?Q?sdaoHDCPRIkFIo9V7QiEg+434W5auQw9Ni/iB0x+EnHvG3C3zFnqLSRy/7mx?= =?us-ascii?Q?C6Aowrs9dupxk0TUfwWMJ3wNLwHclLAdGhn13lC+DEif0UGIiXrXsux1lA+9?= =?us-ascii?Q?EQdt+XO5C59BfZsoHL0z2HFvseKrr/c6u0IeaqnnNi9VeZIcmNM0nduXAy4N?= =?us-ascii?Q?F52/kLaiz417H7ep1tcfAEVlZV19oDMfF1/p+a0vvHw6yTr72lxLRgM/sR/q?= =?us-ascii?Q?99EAJPfyOK9fK8KTqbpsX0vJ91MsmPTwWp8xPN4FtstKkHnTofis87n1uLM/?= =?us-ascii?Q?ZOvhbA1isXMmiOJIBEEi18b8Y+nqTCCLzC3bnh2/JjCalMwz/5Qvgr4NdlJD?= =?us-ascii?Q?pINdsyXryxAA08YsJpBlWDNz9iH5n1labx6fw1IXy+VKja/mevUJAmMkkpO6?= =?us-ascii?Q?YFZ1FPcsKPxnfDym8j0U/4wAYIJSp2+5nbsEnaWqINhUvttqZVjEVgAm+FkD?= =?us-ascii?Q?kke885qafyAVcBWKX4OrOOLf0eLRBa1W0Fg9pBMISiTVMpxO2zBQoILVCIWF?= =?us-ascii?Q?ayxaXuU2ToDvhEK33+wgpM6dpmB6NRrJwkJ3BU4Nez0Cl2Snxo0JUXCcETXL?= =?us-ascii?Q?X92OsFzcCE8AoErivLtjOqenZunb9XKt4stQ+vl9150Juv1X3ox71KPDo+7D?= =?us-ascii?Q?aDsiT1WVmVR+mflB+KZx+VMC+4ZMaXVDrJJhSnbIoq7xZRjWHHeY67W4O5MF?= =?us-ascii?Q?nf9HnYBvTv0zqE0ss9EDBb7WUkT/dmsZbWoF32LvCY4C12V0998IgmktELz3?= =?us-ascii?Q?J1kQu0TTqr+JRzTBTi9kzUUJKjZ1AyMr+K/yysQtT+sFAH6JYDbuIndvJAvV?= =?us-ascii?Q?Zt6D1KfQFaIWjqPQ4oJBr0xvIQkegkK6hTSoIRM4Do3h96V11WF3oZE9wrnj?= =?us-ascii?Q?HNoQhL8tzDekWi9JFd77l581zt78ODDPCSWR8qQiJ328iMJTmXBZo8dLxG1y?= =?us-ascii?Q?rUTFbok/grinWBmG+Vbl2H4CLwa93mXP2sv1EQpq8EIlwl67NYkyc9sd5zbW?= =?us-ascii?Q?Cme6ehJJ8zcSwwAYdPPIOdyTp6ETRG8IgZc85e881Lo0d26D9yh/6gjAF4MT?= =?us-ascii?Q?hmLaHC7KG4zkzFKu01s0=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 6:w2C2a6zbWbCWLXXxp60aL/kRhgY7peIU0xWN9WBmzrL014o1BbG4PcwLYjRNsAWQ0oFWeCSJjDP/zlFLFAeT4U1iDpBDmliumGbdai0AZWT7FtWipedXd2/sjV+wUru0W25HNqX3YpQA3PPYwEfC1PrlSM2EBU6xjMz8QNpM5tEAb5T1q12WhFwwBRAfr/BypEoxD2McOx1ij5ZQm5DBbOB3pQFj9S0bdW9beQI0k2jxAZiE/PuSNcVLeU6iwKuuO082aNS0xLnVzDIXsYhJ/xRDl98eujraEdyIpUcgpowHCNJ7x0EWct+pkcRblunWiGRttYxHOix9oeAbMWoXPA==; 5:Ku8PVqFQi0QGh6CLDBiySqFMt6ito5IzrKsLwADAcMdbUJA/LeaQ0SfxCoA6/38cCi7s6xm6wK8K+1f2jbtvTC0GPqsjz+nGtb/vSbzNBPvxDx7BlElXnbSrhGwkFzDUl46ZQX6Ml/dgStoD9XYkCg==; 24:y94+fRq6YUa6BkyV+IURU7vAniEzl2y/jXIbhPfe9GD0OKA2m6CtNT/A/v1W72wdA9V85bjP3dE3doz2RyFuKY6TJmTlTcQMTvF4Mi4h0ZI=; 7:m5SgOBMI7KydGN30PE++N4Mv6ozHuULz8ViRFtL6DMzkd78mj3Vw05yQ5TLjeFILq2XyZQo1qyGnsGTkjgeEbeLDisCAWfHshUafV7MskmNCOFNAx4SDdpngITJfgeaHPzrmV6TqhDU7piMJpP9Wy3BD6I8zG/zsVnN1QKvMHuR4CHhrxwbKWLO6vtmAMaiTA/TWerIUNvZ9+JluoxPT/jZZw47pNlGRkjV4/6D8SCY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2017 06:05:01.8164 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0101MB1029 Archived-At: Subject: Re: [Dots] =?utf-8?b?YW5vdGhlciBvcHRpb246Ly/nrZTlpI06IENhbiBET1RT?= =?utf-8?q?_protocol_support_IP_whitelist_for_DOTS_client=27s_AA=3F?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 29 Sep 2017 06:05:06 -0000 On 7 Aug 2017, at 7:55, Xialiang (Frank) wrote: > In addition to IP whitelist and certificate, pre-share key can also be > an option. Yes, it should be. ----------------------------------- Roland Dobbins From nobody Thu Sep 28 23:05:17 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBF3134A3B for ; Thu, 28 Sep 2017 23:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1u1jc5WI_NCc for ; Thu, 28 Sep 2017 23:05:08 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0093.outbound.protection.outlook.com [104.47.40.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2129E13219E for ; Thu, 28 Sep 2017 23:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cO2rWgYGsHF+dXSaYvhrJDV6aQzH7Sj4BQKpnA7AEjo=; b=CFHa0ZuBju2BDYSri1xTrsaqzg4iywEff8yFLar9ituYgrhLWrLIwNyqn8SslBicnMj/FKkIA+29e/hYBMvk7LWDdR/D3emAVd6ZKCL0b/84VifSY/VDY51iHRi0cpAlWiSqbqkHR/iE3Xj1l0PF44MW1+7PV7IA1ybU7FN8qI0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; Received: from [172.19.254.101] (184.82.231.92) by BY1PR0101MB1029.prod.exchangelabs.com (2a01:111:e400:5005::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 29 Sep 2017 06:05:06 +0000 From: "Roland Dobbins" To: "Konda, Tirumaleswar Reddy" Cc: Xialiang , "Dots@ietf.org" Date: Fri, 29 Sep 2017 13:05:05 +0700 Message-ID: <6E4F0B0C-DB3D-4DB5-93EC-FFC652EB987A@arbor.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.7r5419) X-Originating-IP: [184.82.231.92] X-ClientProxiedBy: SG2PR06CA0108.apcprd06.prod.outlook.com (2603:1096:3:14::34) To BY1PR0101MB1029.prod.exchangelabs.com (2a01:111:e400:5005::26) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 877b89ea-0b86-432e-c02e-08d5070008cb X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BY1PR0101MB1029; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 3:2T7o5sJHXJOAhz0yCVtxqK0w5TSufImIZAfl3t3+IY3Sh59wp14j42QYRbgvvs7hKGsUul+Gh0BDhENSRmGRVhbiLsUTCNknGQ8vs1ev1vt7rI9uT3FgbgF21QHWonpSQMjO4yK+lBjK6xKOTerUMHJHn2clGnFX8vF/nmGdc/kEP5ROb8TSgC1exl5mgnpPgTo6CwYQibhfUIMIdhIDhZprxfSh1UfBPZQ49Vsr3tFY0H3cZqL8/blsmwi8+bQf; 25:Az8Rsngl7CHlwcZPkfRhMRWlgalVOUaZxhNcfapXoruzVkNJ9vN/p4+a/4xNV8r21vHGbINdiR3dSQfl7DmFvj/KW1S8kMm5PtdjxcHHlevjhOGx94jwzsVLfj0tD6iVqqivhBFd55HkB9uQYCAejW5qmZzObj9dSR0nMEJYLOmXPt4ugdKK9sOFNSZ6hGrXHzGxCFEhmEZ0sVq+iGhjyggRefDeY4gOjiiuEK26oBNrAhLbBOyhDWuPZNrGu/KynM2hJwLKSsaLKBiGKQkgS3xxZ0mz1Z6g7SopyExe/0/i/dxjc/GbAKkcipjk5hyY4fFl16Tv9Kpc2NEigfoC3g==; 31:yx2P0z7+4oNU06CMXGUG3bfFqbNpgt0l07EN4YMNy0Tj0/ymlU+6wYZjQEJKcjVUjFLbjlNU2zWJLqeDThweHa3mJVHWPjol0gYtAX+e55YISCdbF6sSV+q3j7uv60zb3AHol2HuIlOg5pyy4/AAMDlnhynuUVMd/BBBkjADKzHpJMt/NVARAdWtsFgh57u8G4TS40NCT19zmlGmYAcNdGjHiaKwv/+jUIKZlA/1bjo= X-MS-TrafficTypeDiagnostic: BY1PR0101MB1029: X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 20:9nQ0zEyxXRk0NKzGmN0GRhX1yWvCieY48IvVSFrIP+xssdiM/UNAUsZOXC7lCDtT+7+gIcDnMcatAjQ9MRVXBlJ5fRnsXLbwZl5MXxlXwBSQF36XJnsSunCf5fXELgBCH/eokyQAOKkY6mqbrI8NJ09RHUN/mI4s4zFLfzebmgoR3XTZyrH9C+ro3PscSsy9W53UZj9+G99yJDZqU5cqnR54nxFt4uED1N7pVPDkFdO85/j78WLs2PA06juCKd7VBtSWwEOL6XvQhB3oAtfWAn+PPhiiL9z7p80obRXeUx4Bu+bX/ijnpnqsXwvyZ0zpJ/enBjTpQHPUstj+q8RttQx8HZpXpkxrvYqV2WOISaGxujxyRv2XkcESeX1prh69Jte6Cwl/yX35YzF53GwxJkAtns6uNBLnY3wm6yMd4BsfXpRY+T0eaX/DBuF90o0QG1HG++G2JgKqtTobJ7O0FhZy/EDqAUVZqcO1LaME/qqDqUemSYzg7pcGZtT2+TPE; 4:YJFsRhaDC0AMbz0tYONWzHiI+OCJ0gvTuiPC6uRhqAb5jVsr2Kqfyb8QIl1BR9AfeY/GndseZkUU/njmnUIj/JTWNmKRmDtBfTKWakn43u0d0RDwRxMk9I+3v2OTMlv8jOklfXmNPOR7a3xWinbijBlUy9EIhxc6CFP9CR+zbp8x1wjGfhdwLJ+btMHjoqQ11ZVCE6axaEWk0WJl8daMju514KVHOBnlBDiUyQCdoIZBoQtA5u69QsMkrEYiYcfB X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY1PR0101MB1029; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY1PR0101MB1029; X-Forefront-PRVS: 0445A82F82 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(376002)(39830400002)(346002)(24454002)(199003)(189002)(2870700001)(316002)(224303003)(50986999)(86362001)(33656002)(6486002)(82746002)(478600001)(16576012)(23676002)(105586002)(77096006)(47776003)(66066001)(5660300001)(558084003)(7736002)(305945005)(189998001)(53936002)(106356001)(101416001)(6246003)(53546010)(2950100002)(4326008)(83716003)(6916009)(68736007)(2906002)(50466002)(6116002)(97736004)(229853002)(3846002)(76176999)(50226002)(25786009)(8936002)(16526017)(54906003)(36756003)(81166006)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0101MB1029; H:[172.19.254.101]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTFQUjAxMDFNQjEwMjk7MjM6TG5OaG12aUh2SFlxeUpRRmNWdUxjd21a?= =?utf-8?B?MzJJRm9ObFl5UWV0VDJhRVVjZzNCbEloTGZSMFUwMkcwU2M0eSt0ZkE3d3dS?= =?utf-8?B?NnU1QTBaQXZ4bFZFMGR4T2NhUzNVRkZpNlpDMjUxMUlYbUNxdFJqRExWaC9Q?= =?utf-8?B?SjNTOSs0R01aeUJndkJhOGY4KzV1cXNESmRyWFlBZEJ2NWFvb28wNHVReG5H?= =?utf-8?B?UkZrdThxRUl0ZnFNbmdvWlF6dnllcmhOVFdna3pEMzFSem96ZnA0M3lDM3lT?= =?utf-8?B?c28wZXlCekVLQTVGRUJoUVRIMHBDaVNKcy9WV2U3OU9taEVKazBpdnQ3UGlS?= =?utf-8?B?VjI1Umd4cXVHRm5wREZKUEoyRXNINld1WVMzT3lXNnh1T2hqNTU1eGNHMEM0?= =?utf-8?B?OVpzWWN2WUtqQm12Qk1lTlZNV0g4RjhaWENFVVJtdGZRZk1IU1cxZm1UbjJ3?= =?utf-8?B?N2thZjhSdk8wUWpxZSt2WHAxTXZEbTY1N1FhWWRDeHc5b3ZTS3RDVHZ0RjN6?= =?utf-8?B?TlpuYTU1d3dvY3pISHpRSUNqM29mU1B0VTk4YlNYazZqNHRpcGV0bmQ0SXlt?= =?utf-8?B?dHBPZEkwSXU2TThOeUxkcDFSYWVZbHp6am9pT3lIQ3NCSXcyQ1ZPTWpudjNT?= =?utf-8?B?Q1F1YVdoeFhGL3JlbkxoeXlIeENIRm5mTkJYa25JU3FQbVpra0NnTjl1RkJB?= =?utf-8?B?Rk1ucjlOaklPczlmd3RJd1JTS0x5Y0s3Y1lrK3h5b0N3QVpoWXlvRm1UK24z?= =?utf-8?B?RjUwMkZiSHBWQVJxajdUa3hPVU5QV1NaV3F0bTF4eTA5L3R6Y2ZZTnRJUjZQ?= =?utf-8?B?dXc5Nm5YcTlKc0pFbHVkZjRxMDA4NkJoRkhjZURROWE5YWE0UDNLdGZyRTh3?= =?utf-8?B?b3EvOXNpR1Axdm41TEcrSlg4SU1MUjBYQnBRcWNEMzlTR1pITkxpRmhqTHpP?= =?utf-8?B?azl5dC9JNXlreFVVdHg1dE1IWmJxSU1Rbmw3U3NTUUlyTnFGT0o5MFAzU1lH?= =?utf-8?B?YVhja3hlYUw5SENvVFpCWUpUVHpPNUtETkdDSWk4bWpOY00vUHk1aW4xdXIw?= =?utf-8?B?VUVVQTA5S0NPTlhYMnpKQjhlYTJ5VEVSK0l6Qnl2YVJzdnVRb1VKWU1mZDZn?= =?utf-8?B?UEFKdTFacXA1RUtaSU1XNnd1Z1lWaXJUMHNQZEp4eFNEQWN3NHpZaE5EM3g0?= =?utf-8?B?TTcvakhBbEZUUDNmd2hkTStRRXJaN2JlTVErRjI2OGY0aVZ1eWgzTStWM3pE?= =?utf-8?B?alFhS2dUNmxGenROM0NINXhUazEvUXdzS3pRSHJ0VkVuS0Y0dnJ2YzM1TmI2?= =?utf-8?B?V3lRdW1lUU0vZU5scW80TVU1UEN3T0xIOGU0NmdHUS9DSG8rK05OdEhjY3RK?= =?utf-8?B?Tm9kWDdMY0hiRDdkOXlaZE9YZ2crOG16M3JEcklNT1VhakU4NzFERmpPK25I?= =?utf-8?B?WHVkeTVueFdmV1NZa3kwcE12RFQ0c3pjZk1wR3QwSHBVUlFBbHBTbVNCS1Z6?= =?utf-8?B?YVZnZzBBRFBQYzM3cFk5NXFEWVllZS8xYS9WZXB6Z3RScnZjOUpacUdVZHNo?= =?utf-8?B?TWtramIrODdnM2FvYVg2ZXEyQ2x0UXpJcGI5L21vWHQwd3haRjhwSjJyVnlR?= =?utf-8?B?TXd1SHhPbEtBWU1TMXk4TVhzOWk1RVh4bG53c05TZHF0NjFFbWFkMnN3Y2I2?= =?utf-8?Q?Q3vXS89ntvy9TiHziAVY=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1029; 6:evtEY1FT4nOoF2HlFay/7i9C9YA5zqV+TF+nFHdADAEvYnzqmDWTRWd/yj0y6cXf8gJ9lSMwj4aKbvBS3ZvUOYbHK4qIAG+vBIHzyku0UUrwMReR9NpEQfgE6hvDJezxHkxkaZshEnx+Tx89TZwAiIVct8RFDJll/VCHpX7/01b53xI9pH6vsYcpauuYPmXIGZD9ihDHd20Z63fIFvkDz+COY/6C2dVKoe87ITH4pNtZZz+be6L7aTcW6RLAH65Gl7XkXGtCQaLBUlanjqURnVFxCqRg0FUMYYQ/uYCcT0bRkIVNcFTHTcgCEbhcc6hEVo9AONwbPzmfRH/Spb91iQ==; 5:566HbwaZKyAJ8bWlvuEV1P3G1JfCpiVH9ZQKnlA1xykaEvHyO+rLuFNTbdfGVKwzm8e9b1tpQWiJs+/LtAJ2P+Kvp3XgVhb/bpd0DVvi/J7MSLzwNqoAq7Vysi26CUx3R/WacNuoMRrEzX/vJN1H7A==; 24:xcN+tr2ap9RhK7irfUnTqgPjrdl85P3mo+LkR3nqHcjXW9z5g7iNVlWPEfR3iS9cdiw+q2nEETvdxYMYdrhNy/zT1ristg0u1AHNr14WOns=; 7:qXFuVLzlWxpNGoxNy78kB1t5ggV9YgZMrX+Ch+ztSDCJpZ2t2PtQ6P+1eXzW/7FqKhgxRAj42twG/NuY0u9T61lzLc/IfsYQp3Lu85XUmxbwFekAai7iw1HIxH30tCzvKyn9dyYTjCzO86nrxAcW4wM66XTx4XoMWHlxgmDbZUB52mF/yx6o2oH+qlaXRHgjLJhPEQpP8l5oLAyPg7tQh1TepcgD8/q3nATyhs5wEZA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2017 06:05:06.0352 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0101MB1029 Archived-At: Subject: Re: [Dots] =?utf-8?b?YW5vdGhlciBvcHRpb246Ly/nrZTlpI06IENhbiBET1RT?= =?utf-8?q?_protocol_support_IP_whitelist_for_DOTS_client=27s_AA=3F?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 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, 29 Sep 2017 06:05:09 -0000 On 7 Aug 2017, at 16:50, Konda, Tirumaleswar Reddy wrote: > I don’t think DOTS should relax the mutual authentication and > encryption requirements. Concur. ----------------------------------- Roland Dobbins From nobody Sat Sep 30 04:55:24 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E781E132F8F for ; Sat, 30 Sep 2017 04:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pzxq5-Kygb0n for ; Sat, 30 Sep 2017 04:55:19 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F38EA132076 for ; Sat, 30 Sep 2017 04:55:07 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1506772504; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=SwEjCwgl+8lu5r+KjczjmN9IcYuD1SZwDrh3az oIlSg=; b=Gaf/EmWby+lu0s1N6PNjOtKIyTHN3Tboj4bYlSBd 9dNlvzJCMiGLFClPzrbFc9H3EKTDard/HmLDMfGJIudgfYm4zF fVLvAFAlkKMByVBRdds42SV9ZTUDcCXSLHlZ7c8zlvB+i4aWhT 1m6RphqkwbgeXtmbSoZlLelXrBoHfRM= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 5da6_6738_b3a37a45_2dfc_4867_990d_46ac0b82a429; Sat, 30 Sep 2017 06:55:04 -0500 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 30 Sep 2017 05:55:02 -0600 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 30 Sep 2017 05:55:01 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Sat, 30 Sep 2017 05:55:01 -0600 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 30 Sep 2017 05:54:39 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Sat, 30 Sep 2017 11:54:37 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.016; Sat, 30 Sep 2017 11:54:37 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Coding and Interoperability Challenges Thread-Index: AQJWDLbdGWgIliMeta88DlSb7Xyh6wERxjbqobjAfoCAAAa5EIAC3pRA Date: Sat, 30 Sep 2017 11:54:37 +0000 Message-ID: References: <062f01d336b7$966e9160$c34bb420$@jpshallow.com> In-Reply-To: <062f01d336b7$966e9160$c34bb420$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.220.42] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:fsv5XCAfwNCmDtCqUhpBTRO3o6Y9NHzrqMHHtKsEvc77jWTs1h6OkVXaeR2rHkJxQI8D8ZiROpGNuiTB1N/SgOa9vox4guwkTuOFGoj8KetPTo0GkHUHS8ZFIPMqXMAHuvWcv+8hi0UZJ98psmo8ANFTD1pzpH+TnrcmBbfWU+Xz3j30Rgu0eL+Ka4Cu7bs2fb4B84J0C3jUvbKqZ7xDOhNZTz0+uW8Whx9OYFZhKNh8YUy+e5aKLZelI+8S6KfkDu4bsyQDVWZfn8hVCHnpegHEHFylGgoraLhVG/OI2QOIVh9vNfHTu65GNBQHRmXQI7Syu8a2zcFIJTB9BfKdBQ==; 5:0cXjKjRMWSou96iAthEuiG8KgfzwVlCctSb0Dgg1p+joXf5EtqHynO3486xnHwTWyieSZzgLqAY5+wFCZlr7SBLS2zyR9cXYuZV6NDJixPZ43kAj+fwZJ7A5OqO/NHzNfe7ecx3Uci4IH4hjDHCquA==; 24:KispTI4lkKqM97aDo8Tqa08BZ+tzY3Ks5MqPemyPodfKw5c0YH3fK1J5XSb0AYH4B/AmqKMqez04PAaDcbkd1DznVk6TkoHZG/EBu2sXtq8=; 7:yiin/egDiDel3xn4hvHsWbgBbRaBP4JlXpZdAe48/vB1Iv4jlFYtqYdX6se3P+sGrPqZA/ldf0b2QUrG/5L4a9Bm8Lcetiy9h3mLNjuf6uHITBUp2J9gcK5wNLbmXfLrILTE3tP2OGHbdTmOgWfG386h6jr3NeDvTabf0LrhJyXXZRKTVNWnlVPZFDb9Xhz+XN5Qxm+nRV5uUjH8OE1yD8YFqfcrsn00Ih3qVbN6LXo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b8c2fab6-b347-451c-ac03-08d507fa06a9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(79290750141951); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0446F0FCE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(39830400002)(376002)(377454003)(199003)(52084003)(57704003)(13464003)(189002)(51914003)(32952001)(51444003)(14454004)(6246003)(5660300001)(101416001)(53936002)(7696004)(2950100002)(99286003)(6306002)(55016002)(53946003)(16200700003)(66066001)(9686003)(25786009)(478600001)(97736004)(77096006)(6506006)(86362001)(72206003)(68736007)(110136005)(229853002)(966005)(2900100001)(2501003)(80792005)(81166006)(33656002)(106356001)(3660700001)(76176999)(54356999)(50986999)(81156014)(3846002)(6116002)(102836003)(105586002)(53546010)(189998001)(2906002)(305945005)(74316002)(8936002)(8676002)(316002)(15974865002)(6436002)(3280700002)(7736002)(21314002)(85282002)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2017 11:54:37.7013 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Version: 2.3.0.9418 : core <6127> : inlines <6104> : streams <1765251> : uri <2509025> Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2017 11:55:23 -0000 Hi Jon, Thanks for the detailed review. I have uploaded the updated draft to https:= //github.com/tireddy2/DOTS/=20 Please see inline > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Tuesday, September 26, 2017 4:37 PM > To: dots@ietf.org > Subject: Re: [Dots] Coding and Interoperability Challenges >=20 > Hi there, >=20 > I now have implemented a working DOTS Server supporting the signal > channel over UDP and is CoAP TCP ready. The data channel work has still = to > be done. > The DOTS Client is still a work in progress, but was used to test the DOT= S > server. This however has highlighted some vague, open to interpretation, > definitions in the signal spec draft-ietf-dots-signal-channel-03, several= of > which I have previously raised. >=20 > If there is insufficient time to address the issues before the virtual me= eting > on 2nd October, then it may make sense to discuss them at that meeting. >=20 > Given the interrelation of the draft IETF dots documents, other RFCs, the= re is > a reasonable chance that I may have misinterpreted something, or not > realised as consequence of what needs to be done. >=20 > The following is not in order of importance - it is following the signal > specification order. Instead of getting bogged down in a section, skip i= t and > read the other sections and come back to the one you are having trouble > with - the wider context may help you. In particular, Sections covering = 5.1 > may need to be initially skipped. >=20 >=20 > draft-ietf-dots-signal-channel-03 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > 5.1 Overview (1) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > In general, what should be in, or could be expected in the response is no= t > that clear. This should be tightened up - this section 5.1 with a new > penultimate paragraph at the end of this section may be a good place. Th= e > following comments / descriptions in this section highlight some areas th= at > have raised concerns. >=20 > Original: (End of section 5.3.1) "For responses indicating a client or se= rver > error, the payload explains the error situation of the result of the requ= ested > action (Section 5.5 in [RFC7252])." >=20 > [RFC 7572 5.5 Payloads and Representations Both requests and responses > may include a payload, depending on the Method or Response Code, > respectively. If a Method or Response Code is not defined to have a payl= oad, > then a sender MUST NOT include one, and a recipient MUST ignore it.] >=20 > If the response is not 2.xx, is the diagnostic message that is sent back = a CoAp > Diagnostic Message with no content format and a simple plain-text message > (RFC 5.5.2 Diagnostic Payload)? Yes (except for 3.00 (alternate server)).=20 >=20 > If so, what happens with the 4.22 (Unprocessable Entity) response in 5.4.= 1 > which states the acceptable values - which are encoded in CBOR? > - I think this should be a Diagnostic Payload response (perhaps with the = bad > value), thus inviting the DOTS Client to (re-)do a GET Request to discove= r the > valid values. > - It is also not possible to determine which is the value that has failed= with > just the current defined payload response - whereas a Diagnostic message > can give a hint as to the failing value. Agreed, updated draft.=20 >=20 > In 5.3.1, the only thing mentioned for a successful PUT response is the > "lifetime" parameter is required. It is unclear whether the rest of the > parameter/values that were part of the PUT request should also be in the > response. What should be returned? No need to convey rest of the parameter values, other than "lifetime" no ot= her mitigation parameter=20 will be modified by the server.=20 >=20 > Suggested update to 5.1 to handle "RFC 7572 5.5 Payloads and > Representations" sandwiched between 2 Originals to set the context:- >=20 > Original: ". Mitigation remains active until the DOTS client explicitly > terminates mitigation, or the mitigation lifetime expires." >=20 > New Addition: "The following CoAP requests and responses MUST be > supported by the DOTS agents. >=20 > +------------+-------------+ > |Method Code |Usage | > +------------+-------------+ > |0.00 |Heartbeat | > |0.01 |GET | > |0.03 |PUT | > |0.04 |DELETE | > +------------+-------------+ > Figure XXX: Supported CoAP Method Codes" >=20 > All CoAP responses with codes that are 2.xx MUST have a CoAP payload, > content type "application/cbor" that is a "resource representation" [RFC7= 252 > 5.5.1 Representation]. >=20 > All CoAP responses with codes that are not 2.xx MUST be a Diagnostic > Payload > [RFC7252 5.5.2 Diagnostic Payload] with no content type. The Diagnostic > Payload can contain additional information to aid troubleshooting. >=20 > +-------------+---------------------+----------+-------+ > |Response Code|Usage |Diagnostic|Payload| > +-------------+---------------------+----------+-------+ > |2.01 |Created |No |Yes | > |2.02 |Deleted |No |Yes | > |2.04 |Changed |No |Yes | > |2.05 |Content |No |Yes | > |3.00 |Alternative Server |No |Yes | > |4.00 |Bad Request |Yes |No | > |4.01 |Unauthorized |Yes |No | > |4.02 |Invalid Query |Yes |No | > |4.04 |Not Found |Yes |No | > |4.22 |Unprocessable Entity |Yes |No | > |5.00 |Internal Server Error|Yes |No | > |5.02 |Bad Gateway |Yes |No | > |5.03 |Service Unavailable |Yes |No | > |5.04 |Gateway Timeout |Yes |No | > +-------------+---------------------+----------+-------+ > Figure XXX: Supported CoAP response Codes " Thanks, simplified the above text as follows : DOTS agents MUST support GET, PUT, POST, and DELETE CoAP methods. The payload included in CoAP responses with 2.xx and 3.xx Response Codes MUST be of content type "application/cbor" (Section 5.5.1 in [RFC7252]). CoAP responses with 4.xx and 5.xx error Response Codes MUST include a diagnostic payload (Section 5.5.2 in [RFC7252]). The Diagnostic Payload can contain additional information to aid troubleshooting. >=20 > Original: "Messages exchanged between DOTS client and server are > serialized ..." >=20 >=20 > 5.1 Overview (2) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Nowhere is mentioned what ports should be used. RFC7252 suggest a > default of 5684/udp for CoAP DTLS. draft-ietf-core-coap-tcp-tls suggests > 5684/tcp. >=20 > Should this be stated?=20 Yes, updated draft.=20 >=20 >=20 > 5.1 Overview (3) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > No mention is made of doing any signal channel recovery if a DOTS agent > restarts for any reason. Things potentially could get out of sync unless= there > is some functionality to make sure that information held by each DOTS age= nt > is properly synchronized (even if it a simple "flush out all that you kno= w"). If the DOTS client reboots and does not have a persistent storage then it c= an use GET request without payload to learn all mitigation requests conveye= d by the DOTS client=20 to the DOTS server. DOTS server will typically have HA and persistent stora= ge.=20 >=20 >=20 > 5.3.1 Requesting Mitigation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Original: ". The relative order of two mitigation requests from a DOTS cl= ient is > determined by comparing their respective mitigation-id values. If two > mitigation requests have overlapping mitigation scopes the mitigation > request with higher numeric mitigation-id value will override the mitigat= ion > request with a lower numeric mitigation-id value." >=20 > This raises several implementation questions. >=20 > Question 1 > ---------- > Say a PUT mitigation-id with a value of #99 is followed by a PUT mitigati= on-id > of #100 which overlaps, so #99 is ignored/overridden. Then there is a DE= LETE > #100. Do we revert back to #99? No, overriding means #99 will be replaced with #100.=20 >=20 > If yes, then do we need to remember #1 through #98 to revert back to them > if needed - the logical extension of this is remembering all 2^31 entries= - > which probably is a DOS attack. >=20 > My suggestion would be that #99 is dropped/deleted if #100 overlaps, and > the subsequent deleting #100 withdraws that particular mitigation and so > mitigation stops. The new wording could be:- >=20 > Replacement: "The relative order of two mitigation requests from a DOTS > client is determined by comparing their respective mitigation-id values. = If > two mitigation requests have overlapping mitigation scopes the mitigation > request with higher numeric mitigation-id value will override the mitigat= ion > request with a lower numeric mitigation-id value. The overlapped lower > numeric mitigation-id is automatically deleted and no longer available fo= r > querying against." Thanks, updated text. >=20 > Question 2 > ---------- > It is unclear as to how this overlapping works, say with #99 target-ip > [1.1.1.1,1.1.1.2] and #100 target-ip [1.1.1.2,1.1.1.3]. Is it correct tha= t > 1.1.1.1 should no longer be mitigated, but 1.1.1.3 should start? Yes.=20 >=20 > What about overlapping protocols, but not overlapping target-ips etc? Protocols can overlap. For example, mitigation-id #99 with "target-ip [1.1.= 1.1] target-protocol [6,17]" and mitigation-id #100 with "target-ip [1.1.1.= 2] target-protocol [17]" then=20 there is no overlap and both mitigation requests will co-exist. >=20 > Question 3 > ---------- > If there is an overlap, why cannot both mitigation scopes (both lower and > higher mitigation-ids) still continue? Merging and maintaining overlapping mitigation scopes increases the complex= ity of managing conflicting mitigation requests.=20 >=20 > Question 4 > ---------- > Handling mitigation request refreshes. > When the lifetime expires with the active mitigation-id, the mitigation s= tops > unless there is a refreshed mitigation request of some sort. Does the re= fresh > mitigation request to keep the mitigation going use the same mitigation-i= d, > or must it be a new (incremented?) mitigation-id? The refresh mitigation request must use the same mitigation id.=20 >=20 > If the refresh requires a new incremented id, then this will wrap at some > point and the "mitigation request with higher numeric mitigation-id value= will > override" test will fail. >=20 > Original: "If the DOTS server finds the mitigation-id parameter value > conveyed in the PUT request in its configuration data then the server MAY > update the mitigation request, and a 2.04 (Changed) response is returned = to > indicate a successful update of the mitigation request." >=20 > This implies the same mitigation-id is used for doing the refresh. > My suggestion is to add in a new paragraph at the end of section 5.3.1 fo= r > clarity. >=20 > New: "For mitigation to continue beyond the initial negotiated "lifetime"= , the > DOTS client will need to refresh the current mitigation request by sendin= g a > new PUT request. The PUT request SHOULD use the same "mitigation-id", > and SHOULD repeat all the other parameters as sent in the original mitiga= tion > request apart from a possible change to the "lifetime" > parameter. =20 Any specific reason for "SHOULD" (I plan to use "MUST" instead of "SHOULD")= ? > The DOTS server MAY refuse the refresh request if any of the > request parameters (apart from "lifetime") have changed." PUT can be used to update the mitigation request (https://tools.ietf.org/ht= ml/rfc7252#section-5.8.3). If the DOTS server finds the mitigation-id param= eter value conveyed in the PUT request in its configuration data then the s= erver MAY update the mitigation request, and a 2.04 (Changed) response is r= eturned to indicate a successful update of the mitigation request. >=20 > Question 5 > ---------- > When the PUT is refreshed with the same mitigation-id by the client at so= me > point before the lifetime expires, if the signal mitigate content (e.g. > target-protocol is changed) is sent by the client, should this be allowed= , > ignored or rejected? Allowed.=20 >=20 > My suggestion is in the "New:" update under Question 4 just above. >=20 > Question 6 > ---------- > As Scope has been defined as an array, are multiple mitigation-ids allowe= d > with a single PUT request? Yes, allowed. > - I think only one should be allowed. The replacement is for the mitigat= ion-id > definition - the addition is at the end. >=20 > Replacement: "mitigation-id: Identifier for the mitigation request > represented using an integer. This identifier MUST be unique for each > mitigation request bound to the DOTS client, i.e., the mitigation-id para= meter > value in the mitigation request needs to be unique relative to the mitiga= tion- > id parameter values of active mitigation requests conveyed from the DOTS > client to the DOTS server. This identifier MUST be generated by the DOTS > client. This document does not make any assumption about how this > identifier is generated. This is a mandatory attribute. There can only = be one > mitigation-id request per Scope per single PUT request." >=20 > 5.3.2 Withdraw a DOTS Signal > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Can multiple mitigation-ids be sent in a single DELETE request (scope is = an > array)? Yes.=20 >=20 > What gets sent back in the payload? >=20 > If the mitigation-id found, then that can easily be the mitigation-id > information. >=20 > If not found, is there no payload, or should there be an empty scope arra= y > something like { > "mitigation-scope": { > "scope": [ > ] > } > } >=20 > We need to define what the client will expect (especially if it is going = to make > a decision on a 2.02 response for a non-existent mitigation-id). The client gets a 2.02 response even if the mitigation-id is not present (a= s explained in https://tools.ietf.org/html/rfc7252#section-5.8.4).=20 I don't see the need to return the mitigation-ids in the response.=20 >=20 > My suggestion is to add in a new paragraph at the end of this section. >=20 > New: "Multiple mitigation-ids MAY be included in the DELETE "scope". The > "resource representation" response payload always includes "mitigation- > scope" and "scope" with zero or more mitigation-ids that were found and > deleted. If the DELETE is repeated for one or more mitigation-ids during= the > active-but-terminating period, then the matching mitigation-ids continue = to > get returned." >=20 >=20 > 5.3.3 Retrieving a DOTS Signal (1) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > When/what to send back an unsolicited response when running with an > Observe. > Some questions that need to be answered. >=20 > When "observe" is set to 0, should the DOTS server send back an unsolicit= ed > information / status update > a) whenever there is a "status" parameter change > b) when there is a change to one of the "*-dropped" parameters > c) send a response at some regular time interval? > - Figure 10 implies it is just on a "status" parameter change. It is a), whenever there is a change to the "attack-status" parameter value= (https://tools.ietf.org/html/rfc7641 allows notification from the server=20 only when the state changes).=20 >=20 > If at a regular interval (c), should this be a configurable value (as per > configuration under 5.4?) or a defined fixed value? >=20 > What should the recommended frequency of update be (1 per n seconds")? >=20 > If Observe is not used to set up a regular frequency update, and therefor= e it > is the responsibility of the DOTS client to poll as required (perhaps for > graphing the data), should the DOTS Client set the Observe option (which = will > set up/cancel either (a) or (b) above) when polling? The client simultaneously can use GET with Observe (1) to receive notificat= ions and poll periodically using GET (without including OBSERVE option).=20 > -If Observe is set to 1 during the polling, then it will cancel any notif= ications > set up. >=20 > Is Observe a MUST with a signal GET? No. > - All examples have this Observe option included in Figure 10 Updated draft to clarify that Observe option is not required for polling.=20 >=20 > I think that adding in an extra parameter "refresh-rate" would help here = if > there is to be a continuous refresh of information. However, this would = only > work for the explicit "mitigation-id" request. Alternatively, the generic > request (no payload) could be replaced with one where the mitigation-id i= s -1 > (following the same usage as the challenges over using the GET configurat= ion > signal-id in 5.4.1). Thoughts? The frequency of polling the DOTS server to get the mitigation status shoul= d follow the usage guidelines given in https://tools.ietf.org/html/rfc8085#section-3.1.3.=20 >=20 >=20 > 5.3.3 Retrieving a DOTS Signal (2) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > There is inconsistency in the definition of the "mitigation-scope" parame= ter > - it is either an object/map or an array (for the responses back from the= GET > with no payload). The usage needs to be consistent throughout the > specification to avoid errors creeping in. >=20 > As "scope" is an array, then the multiple responses should be:- >=20 > Replacement: " > { > "mitigation-scope":{ > "scope": [ > { > "mitigation-id": 12332, > "target-protocol": [ > 17 > ], > "lifetime":1801, > "status":2, > "bytes-dropped": 134334555, > "bps-dropped": 43344, > "pkts-dropped": 333334444, > "pps-dropped": 432432 > }, > { > "mitigation-id": 12333, > "target-protocol": [ > 6 > ], > "lifetime":1749, > "status":3, > "bytes-dropped": 0, > "bps-dropped": 0, > "pkts-dropped": 0, > "pps-dropped": 0 > } > ] > } > } > " Agreed, updated draft.=20 >=20 >=20 > 5.3.3 Retrieving a DOTS Signal (3) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > "bytes-dropped" and "pkts-dropped". Are these counters from the start of > the original initial PUT mitigate requests, or are these reset to 0 whene= ver > there is a PUT mitigate refresh? The counters are from the start of the initial PUT mitigate request.=20 >=20 > My inclination is to go with the count from the initial PUT mitigate requ= est > (with a potential wrap around for long mitigations). The counter is unsigned integer and it will wrap around; added text to clar= ify.=20 >=20 > It is possible that a DOTS client may have been restarted, but the mitiga= tion > request continues for the remainder of the lifetime Yes.=20 > Replacement: "bytes-dropped: The total dropped byte count for the > mitigation request since the mitigation was initially requested. This is= an > optional attribute. >=20 > bps-dropped: The average dropped bytes per second for the mitigation > request. This is an optional attribute. >=20 > pkts-dropped: The total dropped packet count for the mitigation request > since the mitigation was initially requested. This is an optional attrib= ute. >=20 > pps-dropped: The average dropped packets per second for the mitigation > request. This is an optional attribute." Fixed.=20 >=20 >=20 > 5.3.3 Retrieving a DOTS Signal (4) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > The "lifetime" returned value is not defined in the mitigation status > parameters. Is this the remaining time (in seconds?) of the current > mitigation request? Yes. >=20 > Replacement: "The mitigation status parameters are described below. >=20 > lifetime: The remaining lifetime in seconds of the current mitigation-id > request. Updated draft.=20 >=20 > bytes-dropped: The total dropped byte count.." >=20 >=20 > 5.3.4 Efficacy Update from DOTS Client (1) > -------------------------------------- > Original: "The PUT request MUST include all the parameters used in the PU= T > request to convey the DOTS signal (Section 5.3.1)." > This also implicitly implies that this must be done in 5.3.1 as well. >=20 > What is the DOTS server supposed to do if any of the parameters (apart fr= om > perhaps "lifetime") are different - does this invoke a 4.02? Yes.=20 >=20 > The same question is true for 5.3.1. >=20 > Replacement: "While DDoS mitigation is active, a DOTS client MAY frequent= ly > transmit DOTS mitigation efficacy updates to the relevant DOTS server. A= n > PUT request (Figure 11) is used to convey the mitigation efficacy update = to > the DOTS server. The PUT request MUST include all the parameters used in > the PUT request to convey the DOTS signal (Section 5.3.1) unchanged apart > from "lifetime". The DOTS server MUST reject the request with a 4.02 cod= e if > this is not the case. Thanks, updated draft.=20 =20 > The If-Match Option (Section 5.10.8.1 of > [RFC7252]) with an empty value is used to make the PUT request conditiona= l > on the current existence of a mitigation request with the same mitigation= -id. > If UDP is used as ... >=20 >=20 > 5.3.4 Efficacy Update from DOTS Client (2) > -------------------------------------- > Original:" The 5.xx response codes are returned if the DOTS server has er= red > or is incapable of performing the mitigation." >=20 > Should there be any definitions of what 5.xx code should be used where? Yes, 5.03 error response code looks appropriate. Updated Section 5.3.4. >=20 >=20 > 5.3.4 Efficacy Update from DOTS Client (3) > -------------------------------------- > Does a PUT with "attack-status" refresh the outstanding lifetime on the > current mitigation request? Yes, it will also refresh the lifetime.=20 >=20 > Or is the "lifetime" parameter optional, despite the MUST statement at th= e > beginning of this session "The PUT request MUST include all the parameter= s > used in the PUT request to convey the DOTS signal (Section 5.3.1)."? >=20 > For clarity, I think the following should be added in as a paragraph at t= he end > of this section:- >=20 > New: "The current mitigation does not have the lifetime refreshed when > using a Efficacy Update PUT as per section 5.3.4, but does have the lifet= ime > refreshed when using a Mitigation Request PUT as per section 5.3.1." I don't see any harm if efficacy update is also used to refresh the mitigat= ion lifetime, it will be useful in a scenarios where the DDoS attack=20 is resulting in high packet loss and latency.=20 >=20 >=20 > 5.4 DOTS Signal Channel Session Configuration > --------------------------------------------- > Original:" a. Heartbeat timeout: DOTS agents regularly send heartbeats > (Ping/ Pong) to each other after mutual authentication in order to keep t= he > DOTS signal channel open, heartbeat timeout is the time to wait for a Pon= g in > milliseconds." >=20 > Nowhere is the frequency defined for "regular send" and should this also = be > configurable in 5.4.1? Yes, updated draft.=20 >=20 >=20 > 5.4.1 Discover Acceptable Configuration Parameters (1) > -------------------------------------------------- > Original: "A GET request is used to obtain acceptable configuration > parameters on the DOTS server for DOTS signal channel session > configuration." >=20 > So, when making a configuration change, is this specific to the Signal Ch= annel > between the DOTS Server and DOTS client, or is it specific to each CoAP > session where potentially there could be multiple sessions for the same > signal channel? DOTS Signal channel is the current CoAP session (see the definition of sign= al channel in https://tools.ietf.org/html/draft-ietf-dots-requirements-04).= =20 >=20 > Replacement: ""A GET request is used to obtain acceptable configuration > parameters on the DOTS server for current session using the DOTS signal > channel." >=20 >=20 > 5.4.1 Discover Acceptable Configuration Parameters (2) > -------------------------------------------------- > Figure 13. Does it also make sense to return Default values as well? > - It may make sense for these to be Current as opposed to Default values. >=20 > Replacement: "Content-Format: "application/cbor" > { > "heartbeat-timeout": {"MinValue": integer, "MaxValue" : > integer,"DefaultValue":integer}, > "max-retransmit": {"MinValue": integer, "MaxValue" : > integer,"DefaultValue":integer }, > "ack-timeout": {"MinValue": integer, "MaxValue" : > integer,"DefaultValue":integer }, > "ack-random-factor": {"MinValue": number, "MaxValue" : > number,"DefaultValue":integer } > } Yes, updated to add current values. >=20 >=20 > 5.4.2. Convey DOTS Signal Channel Session Configuration (1) > -------------------------------------------------- > Original: "The RECOMMENDED values of transmission parameter values are > ack_timeout (2 seconds), max-retransmit (7), ack-random-factor (1.5) and > heartbeat-timeout (371 seconds)." >=20 > RFC7252 has max-retransmit set to 4, not 7. (RFC 7252 4.8 Transmission > Parameters). >=20 > With the exponential back off for retries of CON messages, using 4 gives = an > expiration of the request after about 1.5 minutes, with a value of 7 this= is > almost 10 minutes. The 10 minutes does seem excessively long to me - > especially when it is for a CON Heartbeat. > Unless there is a good reason for 7, I suggest we go with the RFC7572 > recommendations of 4. Updated, instead of heartbeat timeout used heartbeat-interval (91 seconds, = derived from MAX_TRANSMIT WAIT counter) and=20 introduced missing-heartbeats-allowed (default value set to 3).=20 >=20 > Replacement: "The RECOMMENDED values of transmission parameter values > are ack_timeout (2 seconds), max-retransmit (4), ack-random-factor (1.5) > and heartbeat-timeout (371 seconds)." >=20 > Replacement: " > Header: PUT (Code=3D0.03) > Uri-Host: "www.example.com" > Uri-Path: "v1" > Uri-Path: "dots-signal" > Uri-Path: "config" > Content-Format: "application/cbor" > { > "signal-config": { > "session-id": 1234534333242, > "heartbeat-timeout": 30000, > "max-retransmit": 4, > "ack-timeout": 5, > "ack-random-factor": 1.5, > "trigger-mitigation": false > } > } > " >=20 >=20 > 5.4.2. Convey DOTS Signal Channel Session Configuration (2) > -------------------------------------------------- > Original: The PUT request with higher numeric session-id value over-rides= the > DOTS signal channel session configuration data installed by a PUT request > with a lower numeric session-id value." >=20 > Say a PUT session-id with a value of #99 is followed by a PUT session-id = of > #100 which overlaps, so #99 is ignored. Then there is a DELETE #100. Do= we > revert back to #99? No. >=20 > If yes, then do we need to remember #1 through #98 to revert back to them > if needed - the logical extension of this is remembering all 2^31 entries= - > which probably is a DOS attack. >=20 > My suggestion would be that #99 is dropped if #100 overlaps, and deleting > #100 deletes that particular session-id. The new wording would be:- >=20 > Replacement:" The PUT request with higher numeric session-id value over- > rides the DOTS signal channel session configuration data installed by a P= UT > request with a lower numeric session-id value. The overlapped lower > numeric session-id is automatically deleted and no longer available for > querying against.". >=20 > Footnote: I cannot think of any reason why there is a need to support > (incrementing) session-ids for configuring a CoAP session - am I missing > something? It is used to handle out-of-order delivery of DOTS Signal Channel Session C= onfiguration messages.=20 >=20 >=20 > 5.4.2. Convey DOTS Signal Channel Session Configuration (3) > -------------------------------------------------- > Original:"heartbeat-timeout: Heartbeat timeout is the time to wait for = a > response in milliseconds to check the DOTS peer health. This is an optio= nal > attribute." >=20 > So, heartbeat-timeout is configured in milliseconds. However, Figure 15 > example below only has a value of 30. This example value of 30 in > milliseconds is small. >=20 > Original: " > Header: PUT (Code=3D0.03) > Uri-Host: www.example.com > Uri-Path: "v1" > Uri-Path: "dots-signal" > Uri-Path: "config" > Content-Format: "application/cbor" > { > "signal-config": { > "session-id": 1234534333242, > "heartbeat-timeout": 30, > "max-retransmit": 7, > " >=20 > This needs to be updated to, say, 30000 instead of 30. >=20 > Replacement: " > Header: PUT (Code=3D0.03) > Uri-Host: www.example.com > Uri-Path: "v1" > Uri-Path: "dots-signal" > Uri-Path: "config" > Content-Format: "application/cbor" > { > "signal-config": { > "session-id": 1234534333242, > "heartbeat-timeout": 30000, > "max-retransmit": 4, Updated draft to use seconds instead of milliseconds. > " >=20 >=20 > 5.4.2. Convey DOTS Signal Channel Session Configuration (4) > -------------------------------------------------- > Original: "Response code 4.22 (Unprocessable Entity) will be returned in = the > response if any of the heartbeat-timeout, max-retransmit, target-protocol= , > ack-timeout and ack-random-factor attribute values is not acceptable to t= he > DOTS server. The DOTS server in the error response conveys the minimum > and maximum attribute values acceptable by the DOTS server. The DOTS > client can re-try and send the PUT request with updated attribute values > acceptable to the DOTS server. >=20 > Content-Format: "application/cbor" > { > "heartbeat-timeout": {"MinValue": 15, "MaxValue" : 60}, > "max-retransmit": {"MinValue": 3, "MaxValue" : 15}, > "ack-timeout": {"MinValue": 1, "MaxValue" : 30}, > "ack-random-factor": {"MinValue": 1.0, "MaxValue" : 4.0} } > Figure 16: Error response body > " >=20 > The 4.22 response should, I believe for consistency, only be generating a > CoAP Diagnostic response, which does not contain payload data. I think t= his > paragraph should be re-worded to be consistent in the CoAP responses: >=20 > Replacement:"Response code 4.22 (Unprocessable Entity) will be returned i= n > the response if any of the heartbeat-timeout, max-retransmit, target- > protocol, ack-timeout and ack-random-factor attribute values are not > acceptable to the DOTS server. On receipt of the 4.22 response, the DOTS > client should re-request the maximum and minimum parameters acceptable > by the DOTS server as described in 5.4.1. The DOTS client can re-try and= send > the PUT request with updated attribute values acceptable to the DOTS > server. Thanks, updated draft.=20 > If the DOTS client receives 3 responses of 4.22 in a row on the same sess= ion, > the DOTS client MUST stop trying to configure the session to prevent a > continuous retry loop." I don't see why the client would pick unacceptable values after getting the= min/max parameters from the DOTS server.=20 >=20 >=20 > 5.4.2. Convey DOTS Signal Channel Session Configuration (5) > -------------------------------------------------- > If a DOTS client wants to re-alter the session configuration with a subse= quent > PUT, should this use the same session-id? No, use a higher-numeric session id in the subsequent PUT request.=20 >=20 >=20 > 5.4.4. Retrieving DOTS Signal Channel Session Configuration > ----------------------------------------------------------- > Unlike the signal GET, it is not possible to get the current configuratio= n unless > the session-id is known, but the session-id can only be created by a PUT,= at > which point the configuration is already known and can be confirmed by th= e > GET. >=20 > As signal-id cannot easily be guessed unless hard coded in the DOTS clien= t, a > suggestion is that a session-id of -1 allows you to determine the current > configuration. As "signal-config" is not an array, it is not be possible= to return > multiple session-ids, but possibly the session-id of the current configur= ation > could be returned in the payload response to a session-id of -1. A new > paragraph at the end of this section. >=20 > New: "If "session-id" is set to -1, then the current signal configuration= is > returned. If the session has previously been configured, then the > appropriate session-id is returned with the current configuration paramet= ers, > otherwise -1 is returned for the session-id along with all the default > configuration parameters." Section 5.4.1 has been updated to return current and acceptable configurati= on range.=20 >=20 >=20 > 5.6 Heartbeat Mechanism > ----------------------- > The frequency of the heartbeats is not mentioned. This should be > configurable in 5.14.2 and have a default value / max-min boundaries > discoverable in 5.4.1 or 5.4.4 or have a recommended fixed value. >=20 > My preference is that it should be configurable as one of the signal chan= nel > session configuration parameters, with a default value of 10 seconds. >=20 > e.g. to be inserted in the appropriate places. >=20 > "heartbeat-refresh": {"MinValue": 2, "MaxValue" : 60}, > heartbeat-refresh: Heartbeat refresh rate in seconds. This is an optio= nal > attribute. Added heartbeat-interval (e.g. {"CurrentValue": 90, "MinValue": 60, "MaxVal= ue" : 240}). >=20 >=20 > 6 Mapping parameters to CBOR (1) > ---------------------------- > It is possible additional parameters may need to be added to this table -= e.g. > DefaultValue and heartbeat-refresh. Yes, added heartbeat-interval, missing-heartbeats-allowed and CurrentValue = for DOTS signal channel configuration.=20 >=20 >=20 > 6 Mapping parameters to CBOR (2) > ---------------------------- > If a client does not use the mapping parameters in a request, how should = the > DOTS server send back any responses - CBOR mapping encoded or just > encoded as strings? >=20 > Should an endpoint refuse to access non CBOR mapping encoded strings? Yes.=20 >=20 > Replacement: "All parameters in the payload in the DOTS signal channel > MUST be mapped to CBOR types as follows and are given an integer key to > save space. The recipient of the data MAY reject the information if it i= s not > suitably mapped." Updated draft.=20 >=20 >=20 > 6 Mapping parameters to CBOR (3) > ---------------------------- > What happens if a sender uses CBOR mapping that are not defined in the > signal channel specification? > - If additional ones are needed in the future, then there will need to be= a > protocol version increase (from v1 to v2). >=20 > New: "A DOTS agent MUST not use any additional Mapping parameters that > are not defined in Figure 21." No, vendors can add vendor-specific parameters (The key values in the range= of 32768 to 65536 are assigned for Vendor-Specific parameters). DOTS agent= s can safely ignore Vendor-Specific parameters they don't understand. >=20 >=20 > 10.2.2 Initial Registry Contents > -------------------------------- > It is possible additional parameters may need to be added to this table -= e.g. > DefaultValue and keepalive-refresh. Yes, updated section.=20 Cheers, -Tiru >=20 >=20 > 11.1 nttdots > ------------ > When testing against the nttdots server / client, the following issues we= re > found:- >=20 > CBOR mapping is not in use - it is using the original strings. >=20 > COAP path requires /.wellknown/ in the UriPath. >=20 > Data Channel uses CBOR/COAP, not RESTCONF (already documented in DOTS > signal > draft) >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Regards >=20 > Jon >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Sat Sep 30 05:54:16 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100621320C9 for ; Sat, 30 Sep 2017 05:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNJxiiMSAwsK for ; Sat, 30 Sep 2017 05:54:13 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210571286C7 for ; Sat, 30 Sep 2017 05:54:13 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dyHHV-00014U-W7; Sat, 30 Sep 2017 13:54:10 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <062f01d336b7$966e9160$c34bb420$@jpshallow.com> In-Reply-To: Date: Sat, 30 Sep 2017 13:54:12 +0100 Message-ID: <034b01d339eb$37251030$a56f3090$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGXUeWhTAMFfttcvwbk/5Yp4wSxYgDqKWj6oz3cfDA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2017 12:54:14 -0000 Hi Tiru, I will look at the updated draft later. However, in response to some of your comments >> If the DOTS client receives 3 responses of 4.22 in a row on the same session, >> the DOTS client MUST stop trying to configure the session to prevent a >> continuous retry loop." > I don't see why the client would pick unacceptable values after getting the min/max parameters from the DOTS server. I just wanted to prevent a continuous retry in case there is some buggy software out there / faulty hardware based on certain bit patterns etc. This is the only place in the spec where the client retries sending again when a failure message is returned from the server. >> "heartbeat-refresh": {"MinValue": 2, "MaxValue" : 60}, >> heartbeat-refresh: Heartbeat refresh rate in seconds. This is an optional >> attribute. > Added heartbeat-interval (e.g. {"CurrentValue": 90, "MinValue": 60, "MaxValue" : 240}). A lot of firewalls I have worked with in the past have a default of 30 sec for UDP session timeouts. Therefore the minimum value should be less than 30 - say 10 or 15 secs to prevent firewall session expiry. Regards Jon From nobody Sat Sep 30 06:41:27 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E404132D54 for ; Sat, 30 Sep 2017 06:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkR2EUr70TnP for ; Sat, 30 Sep 2017 06:41:24 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A328A13292F for ; Sat, 30 Sep 2017 06:41:23 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1506778882; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=z Bp+yGT1Zo0qyfkHG9dHt1eifLFPzG2SD9OC7qsApT c=; b=e8AdCeNlkg9haUiKJtQCeDkDOzJ9psL1LOSOB8o9YZ9D ittPM2BAFbFErORqapUq3wcCKY8z0y9O88mVjs1aEDTf4w0DVu lEXbTeDJ18x2sunkHqIAsUvWMaJkTB6XSsrOerZynNxNN+7Uvl WcCv/JHBcjoEw50301bTFPuf+xc= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 5da6_e6ec_36b3aaad_c84b_4f1d_b076_1600ef159efe; Sat, 30 Sep 2017 08:41:21 -0500 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 30 Sep 2017 07:41:21 -0600 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 30 Sep 2017 07:41:20 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Sat, 30 Sep 2017 07:41:20 -0600 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 30 Sep 2017 07:41:19 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Sat, 30 Sep 2017 13:41:19 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.016; Sat, 30 Sep 2017 13:41:18 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Coding and Interoperability Challenges Thread-Index: AdMouv44Udo0NFExSCOHW+HXkRNTEQRLPDXg Date: Sat, 30 Sep 2017 13:41:18 +0000 Message-ID: References: <070601d328ba$ffbbc440$ff334cc0$@jpshallow.com> In-Reply-To: <070601d328ba$ffbbc440$ff334cc0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.220.42] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:uBqEIXhaT9UbquufeWXtSOtioCJPPRzcQlr5B+/zfujl3TcCVPWeCm5KYEIn4bcool8hVG/U1ZopdTcczdjP6Z8Pv12yyXfTC1uY9bzr6sr18d8e7DsGJouA/lTmbysq7rxuvM1u2oNhX9oDZx9oQ6dxb14G+PRvlBhz3jFmOkwqETerMdcS5vZ5FMBaaUJE71rsKcQy1RMd8X4LuI4p1p58CpzRtMN1zLheRD/UY7L2Xbx7KiTB79MzPWK4bIU8pHr2An2Ksj39wyVkskINWmB3+fcO5Y6V/992gMKPuE2ljA/y61qJAAtQ/VCPxaDqr/xzKK+vUGpvDF3h+BmrkA==; 5:SHYKQdJsXsijxivvbbmZ9rWfqxHQFn/gTLiu4KYeiqIr9BApGM51INXRpvPiKSpTQ3R+f7BRP9mnjRCPv50V9PJu5Q9XBtctVgAsVgJMTNkMOzz55T9RdqkXf6KsHTYYMGJsimjF2zEJPBk+otW70w==; 24:X1isMyp+xwYzDBIoseCNOUCDIGmASnqOW3wq2HG9rz/2kATr3tGk3ZIPVVlQMF2/m8gEKYIy2sJTntnwvYgZ677qHiVhgmLyGgNWmE37d4g=; 7:b1aj5/dJnZPJZFO1ZAtA790VCr/iCWqom98Gsq2tv+0VvwqAkTmDPcoT9sOCgw1tBwcC+J44+myG4F/QsBxNNpEIzOwG+qRRpyjtkpGBiM+uaqIUQEMzZySBCozSEAPannyuRSvUuoWcH0N5p9WTPT7NKAGE875e4QuwgNgN1FHCQpaKmyhGThg7MhXZfRvBAuzEeoQA9QlJT5TtSPC3SBumAjnIw8OPwsTrSGIe2pI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2fc025fd-7f88-4186-6c22-08d50808edfc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(166708455590820)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 0446F0FCE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(57704003)(189002)(377454003)(199003)(32952001)(2501003)(6246003)(74316002)(2950100002)(86362001)(80792005)(6116002)(3846002)(14454004)(790700001)(5660300001)(606006)(966005)(2906002)(102836003)(53546010)(101416001)(2900100001)(7696004)(72206003)(50986999)(189998001)(105586002)(478600001)(54356999)(77096006)(6506006)(106356001)(76176999)(8936002)(81166006)(54896002)(7736002)(68736007)(9686003)(236005)(3660700001)(97736004)(229853002)(81156014)(8676002)(33656002)(19609705001)(53936002)(6306002)(110136005)(3280700002)(66066001)(316002)(6436002)(9326002)(55016002)(99286003)(25786009)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788E67855196CEAB788C03BEA7F0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2017 13:41:18.7202 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6127> : inlines <6104> : streams <1765262> : uri <2509064> Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2017 13:41:26 -0000 --_000_DM5PR16MB1788E67855196CEAB788C03BEA7F0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline. From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, September 8, 2017 9:26 PM To: dots@ietf.org Subject: [Dots] Coding and Interoperability Challenges Hi there, We are in the process of trying to code up a DOTS Client / Server implement= ation based on the draft standards so far and have come up with the followi= ng list of issues / questions. Nttdots =3D=3D=3D=3D=3D=3D=3D An excellent starting point, but CBOR ------- The nttdots server only accepts strings for the various parameters. It doe= s not (yet) accept CBOR that uses the CBOR mapping parameters (draft-ietf-d= ots-signal-channel Section 6). Signal Channel ------------------- Nttdots is expecting an additional path parameter in the POST/PUT etc path = (.wellknown), so instead of /v1/dots-signal/signal, it requires /.wellknown= /v1/dots-signal/signal which is not stated anywhere in the draft-ietf-dots-= signal-channel draft. If not present, it returns a 4.05 code. [TR] The draft can be updated to use well-known URI with dots-signal as URI= suffix, we can discuss in the interim WG meeting. RFC6690 refers to "/.wellknown/core" as a default entry point for discover= ing what resources are available. RESTCONF rfc8040 refers to "/.wellknown/host-meta" to determine the RESTCON= F root resource. Data channel ----------------- Data channel support uses CBOR / COAP, not RESTCONF (well actually it goes = over the signal channel), but that is documented as a current limitation, b= ut does need to be fixed. Libcoap =3D=3D=3D=3D=3D=3D=3D The currently available c libcoap library (develop branch) from https://git= hub.com/obgm/libcoap only supports DTLS with PreSharedKeys, not Certificate= s. Work needs to be done with this library to support PKI as well as COAP = over TLS (not yet an IETF standard) to support the signal channel requireme= nts. Doing a hack to libcoap to force known PKI keys works when used against Ntt= dots, so there is potential here to use a fixed version of this library. RawPublicKey has not been tried out. Libcoap requires openssl 1.1.0 or TinyDTLS - GnuTLS support is not currentl= y available. Red Hat/Centos distributions do not have openssl 1.1.0 - DTLS= support is only version 1, not version 1.2 in their versions of openssl. = The openssl libraries cannot be replaced in Red Hat/Centos - the 1.1.0 vers= ion has to be installed in addition to the existing openssl libraries. Libcoap assumes that all IP addresses are IPv4 (see coap_address_t), even t= hough there are some references to IPv6 elsewhere in the library. Default Values =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There is a list of configurable parameters, but no suggested defaults. [TR] No, all configurable parameters in the specification have default val= ues. Signal Port - UDP ---------------------- COAP using DTLS default port is 5684 (RFC 7252), nttdots port is 4646. Sho= uld DOTS be going for / defining the same port as COAP? (https://tools.ietf.org/html/draft-mortensen-dots-over-udp-00 refers to 464= 6) Signal Port - TCP --------------------- This does not have to be the same as the UDP port, but looks like it is goi= ng to be 5684 as per draft-ietf-core-coap-tcp-tls. Should DOTS be going fo= r / defining the same default port as COAP? [TR] Yes. Data Port ------------- RFC8040 - "2.2 HTTPS with X.509v3 Certificates" defines RESTCONF implementa= tions MUST support the "https" URI scheme, which has the IANA-assigned defa= ult port 443 for "/.wellknown/host-meta". Data Port cannot easily be the same as the Signal Port (TCP) as new incomin= g connections are either COAP or RESTCONF and it may be difficult to differ= entiate. Port 443 may clash with other GUIs or applications running on port 443 on t= he same host as the DOTS server. However, the other GUI/applications may h= ave to add in "/.wellknown/host-meta" to support replying that RESTCONF is = running on another port. Is the Link 'restconf' definition sufficient, or = de we need a link definition something like 'restconf-dots' added? What should the suggested default RESTCONF port be? [TR] 443 port, ALPN [RFC7301] can be used to identify DOTS data channel and= distinguish from other application protocols on the DOTS server using port= 443. Mitigation Lifetime ------------------------ This will be DOTS Server provider specific, but should be the order of days= . Do we need to suggest a default lifetime? [TR] The default value in the specification is 60 minutes. DOTS Client Restarts =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The DOTS Client will need to re-synchronize with the DOTS Server to get the= DOTS Server's current shared state (mitigation / filters etc) when it gets= restarted or reconnected. Should this be stated? [TR] After restart the DOTS client can use GET to learn the mitigation requ= ests it had conveyed to the DOTS server. DOTS Server Restarts =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The DOTS Server needs some way to signal to the DOTS client that it has res= tarted and that shared state needs to be re-synchronized. Should this be s= tated? [TR] DOTS server should have persistent storage and HA to handle restart (o= therwise DOTS client will have to go through the trouble of re-creating ali= ases, white-list/black-list ACL and mitigation requests during DDoS attack)= . -Tiru =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon --_000_DM5PR16MB1788E67855196CEAB788C03BEA7F0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please se= e inline.

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, September 8, 2017 9:26 PM
To: dots@ietf.org
Subject: [Dots] Coding and Interoperability Challenges

 

Hi there,

 

We are in the process of trying= to code up a DOTS Client / Server implementation based on the draft standa= rds so far and have come up with the following list of issues / questions.<= o:p>

 

Nttdots

=3D=3D=3D=3D=3D=3D=3D

 

An excellent starting point, bu= t

 

CBOR

-------

 

The nttdots server only accepts= strings for the various parameters.  It does not (yet) accept CBOR th= at uses the CBOR mapping parameters (draft-ietf-dots-signal-channel Section= 6).

 

Signal Channel

-------------------<= /span>

 

Nttdots is expecting an additio= nal path parameter in the POST/PUT etc path (.wellknown), so instead of /v1= /dots-signal/signal, it requires /.wellknown/v1/dots-signal/signal which is= not stated anywhere in the draft-ietf-dots-signal-channel draft.  If not present, it returns a 4.05 code.

 

[TR] The draft can be updated t= o use well-known URI with dots-signal as URI suffix, we can discuss in the = interim WG meeting.

 

RFC6690 refers to  “= /.wellknown/core” as a default entry point for discovering what resou= rces are available.

RESTCONF rfc8040 refers to R= 20;/.wellknown/host-meta” to determine the RESTCONF root resource.

 

Data channel<= /p>

-----------------

 

Data channel support uses CBOR = / COAP, not RESTCONF (well actually it goes over the signal channel), but t= hat is documented as a current limitation, but does need to be fixed.<= /o:p>

 

Libcoap

=3D=3D=3D=3D=3D=3D=3D

 

The currently available c libco= ap library (develop branch) from https://github.com/obgm/libcoap= only supports DTLS with PreSharedKeys, not Certificates.  Work ne= eds to be done with this library to support PKI as well as COAP over TLS (n= ot yet an IETF standard) to support the signal channel requirements.

 

Doing a hack to libcoap to forc= e known PKI keys works when used against Nttdots, so there is potential her= e to use a fixed version of this library.

 

RawPublicKey has not been tried= out.

 

Libcoap requires openssl 1.1.0 = or TinyDTLS – GnuTLS support is not currently available.  Red Ha= t/Centos distributions do not have openssl 1.1.0 – DTLS support is on= ly version 1, not version 1.2 in their versions of openssl.  The openssl libraries cannot be replaced in Red Hat/Centos – the 1.1= .0 version has to be installed in addition to the existing openssl librarie= s.

 

Libcoap assumes that all IP add= resses are IPv4 (see coap_address_t), even though there are some references= to IPv6 elsewhere in the library.

 

Default Values

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

 

There is a list of configurable= parameters, but no suggested defaults.

 

[TR]  No, all configurable= parameters in the specification have default values.

 

Signal Port – UDP

----------------------

 

COAP using DTLS default port is= 5684 (RFC 7252), nttdots port is 4646.  Should DOTS be going for / de= fining the same port as COAP?

(https://tools.ietf.org/html/draf= t-mortensen-dots-over-udp-00 refers to 4646)

 

Signal Port – TCP

---------------------

 

This does not have to be the sa= me as the UDP port, but looks like it is going to be 5684 as per draft-ietf= -core-coap-tcp-tls.  Should DOTS be going for / defining the same defa= ult port as COAP?

 

[TR] Yes.

 

Data Port

-------------=

 

RFC8040 – “2.2 HTTPS with X.509v3 Certificates” defin= es RESTCONF implementations MUST support the "= ;https" URI scheme, which has the IANA-assigned default port 443 for “/.wellknown/host-meta”.=

 

Data Port cannot easily be the same as the Signal Port (TCP) as new inc= oming connections are either COAP or RESTCONF and it may be difficult to di= fferentiate.

 

Port 443 may clash with other GUIs or applications running on port 443 = on the same host as the DOTS server.  However, the other GUI/applicati= ons may have to add in “/.wellknown/host-meta” to support replying that RESTCONF is running on another port.  Is the= Link ‘restconf’ definition sufficient, or de we need a link de= finition something like ‘restconf-dots’ added?

 

What should the suggested default RESTCONF port be?

 

[TR] 443 port, ALPN [RFC7301] can be use= d to identify DOTS data c= hannel and distinguish from other application protocols on the DOTS server = using port 443.

 

Mitigation Lifetime<= /span>

------------------------

 

This will be DOTS Server provid= er specific, but should be the order of days.  Do we need to suggest a= default lifetime?

 

[TR] The default value in the s= pecification is 60 minutes.

 

DOTS Client Restarts=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 

The DOTS Client will need to re= -synchronize with the DOTS Server to get the DOTS Server’s current sh= ared state (mitigation / filters etc) when it gets restarted or reconnected= .  Should this be stated?

 

[TR] After restart the DOTS cli= ent can use GET to learn the mitigation requests it had conveyed to the DOT= S server.

 

DOTS Server Restarts=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 

The DOTS Server needs some way = to signal to the DOTS client that it has restarted and that shared state ne= eds to be re-synchronized.  Should this be stated?

 

[TR] DOTS server should have pe= rsistent storage and HA to handle restart (otherwise DOTS client will have = to go through the trouble of re-creating aliases, white-list/black-list ACL= and mitigation requests during DDoS attack) .

 

-Tiru

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Regards

 

Jon

--_000_DM5PR16MB1788E67855196CEAB788C03BEA7F0DM5PR16MB1788namp_-- From nobody Sat Sep 30 07:13:01 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7872F1344CE for ; Sat, 30 Sep 2017 07:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMDY0SZeTj9e for ; Sat, 30 Sep 2017 07:12:56 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C83D1344DC for ; Sat, 30 Sep 2017 07:12:54 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1506780754; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=K lD3sCbKgaNQ2idU9zR6zRFC4FVQOD5eub8wmppmu5 s=; b=ooHEoM+bF9QJqrVuDi/hjFUthtOh5SmRqQ5tBXLwFsbP ByitZuZt1LlSzIjdnAG2j3pMnDXWoR6fFbXCk0S0uGiAxtoXl1 DVfOYs1bacJqW5RjpryJ0s+MIElWyhqC4Rk47fpcfFy36ZAriQ BN3W7qgbqZummihKfdVCQkFOErk= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 5da6_09cc_6425e940_a4ef_45d2_aec0_00a192f16afc; Sat, 30 Sep 2017 09:12:32 -0500 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 30 Sep 2017 10:12:31 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Sat, 30 Sep 2017 10:12:31 -0400 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 30 Sep 2017 10:12:30 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Sat, 30 Sep 2017 14:12:29 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.016; Sat, 30 Sep 2017 14:12:29 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Coding and Interoperability Challenges Thread-Index: AdMouv44Udo0NFExSCOHW+HXkRNTEQEi7ROAAyrIryA= Date: Sat, 30 Sep 2017 14:12:29 +0000 Message-ID: References: <070601d328ba$ffbbc440$ff334cc0$@jpshallow.com> <00a101d32d46$b2f30cf0$18d926d0$@jpshallow.com> In-Reply-To: <00a101d32d46$b2f30cf0$18d926d0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.220.42] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:MimLTsLCbd5rRIFlUBtZBoJFXWROMqtcui4SxvbiMwlpztscR+lK7q29oX0ZK9YJtwfTZo6kATc1CQ1Ub2ZtOshqeVPp6fwh+mQByoF24Lr40b07XsU3fUw4Cn9EppADd7t/6NNAcCOwj222Wu8Kbwq3WU26carfUhIh8rF77frpE/TN6qYq44YVP5fGJzpFuAk2UJnk2ict+tsAO78eB7M95JB23U5Qp2I9Y1XRtLRG15e3FndV7MRirUT2bekDMELoW0YOOHO/q5oaTy0+Y3GfY7vJ21DgUUIBfTyjbJqAHCRJ2iwr0XpB7ODD2Edb+HMCtV/7yT/gb506AYeXUg==; 5:MLa1lcd1ZSh99mVe1fJCg2ndJ2bY8MJUyn3B5D2Hv2oc21ACSk2NZjiIkepwV24z3LsiLU8Pg2LdkINtcRTZLTJPY9aoIlQkmhq+BBzjG+fb1/DlfP5whZF9fcOcaOP/C40Ks1o1faxhGSEVSYFNLg==; 24:XTay9K3Bh+xEAIpeWm7x6T+PW+eL1blwPEUhYlnM/knB4NaVf+2BC1rWm5oNU492feNuy4GHmHYb9ZxfdMj5/mKPFxLQzgroKg27uEl8aCA=; 7:hZ2lhufeykoDUogz0KTpa/0HDwtYwqvh6HJBr/jgK3CGPRanT5hq3qqaGFkibTjGi2WsFLmurfZWgf+84athptsy6T5HH73v5MNqfdpstQMGnAQgLwXY0MSX+jdH8UBPGMeXLvmUP/JppuHwriW0L2ckStgfnV+TOz5i60D85913fafJnTM30xXnaymd5eDlg7k5AkbpkWNrZ7owVWOCZGhyWzneFZN6ryrmSp69vfo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3ceb2a12-495e-4e1e-1c40-08d5080d48fe x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(120809045254105)(166708455590820)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123558100)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 0446F0FCE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(57704003)(189002)(377454003)(199003)(32952001)(2501003)(6246003)(2950100002)(74316002)(80792005)(6116002)(3846002)(14454004)(790700001)(5660300001)(606006)(2906002)(966005)(102836003)(53546010)(101416001)(2900100001)(7696004)(50986999)(72206003)(86362001)(189998001)(105586002)(478600001)(54356999)(77096006)(6506006)(106356001)(76176999)(8936002)(81166006)(54896002)(7736002)(68736007)(9686003)(236005)(3660700001)(97736004)(229853002)(81156014)(8676002)(33656002)(19609705001)(53936002)(6306002)(110136005)(3280700002)(66066001)(316002)(6436002)(9326002)(55016002)(99286003)(25786009)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788B30F01C35B8E41564384EA7F0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2017 14:12:29.3753 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6127> : inlines <6104> : streams <1765265> : uri <2509076> Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2017 14:12:59 -0000 --_000_DM5PR16MB1788B30F01C35B8E41564384EA7F0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline [TR] From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Thursday, September 14, 2017 4:16 PM To: dots@ietf.org Subject: Re: [Dots] Coding and Interoperability Challenges Hi there, No responses to date. I have subsequently found that libcoap does properly support IPv6 - and hav= e updated my previous questions / comments. I however have further signal channel questions / discrepancies from https:= //datatracker.ietf.org/doc/draft-ietf-dots-signal-channel Usage of PUT signal =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Usage of "attack-status" ------------------------------- 5.3.1. PUT definition does not include '"attack-status": integer' 5.3.4. PUT definition is initially identical to 5.3.2, but includes '"attac= k-status": integer' and states that it is mandatory. If this parameter is mandatory, then it should be included in the 5.3.1 def= inition, or is it mandatory only if this is defining an Efficacy update? [TR] "attack-status" parameter is specific to efficacy update. With the 5.3.4 version, would not just sending the "mitigation-id" and "att= ack-status" be sufficient? [TR] No. PUT updates the mitigation request, Efficacy update has to convey = all the parameters sent in the original mitigation request (see https://too= ls.ietf.org/html/rfc7252#section-5.8.3). When refreshing with a 5.3.4 PUT, does this reset the lifetime expiry count= er? [TR] Yes, 5.3.4 PUT updates the mitigation lifetime. PUT refresh --------------- When the PUT is refreshed by the client at some point before the lifetime e= xpires, if the signal mitigate content (e.g. target-protocol is changed) is= sent by the client, should this be allowed, ignored or rejected? [TR] Allowed. COAP Response information ------------------------------------ There is reference to the server having the ability to update the lifetime = in its response to the PUT (5.3.1). "The server MUST always indicate the actual lifetime in the response and the remaining lifetime in status messages sent to the client. This is an optional attribute in the request." However, nowhere else does it state what should be in the body of the resp= onse (if anything) for a PUT or DELETE. There are hints in the COAP RFC th= at suitable diagnostics can be added for failure response codes. Do we just echo back the request (with update lifetime possibly) for PUT? [TR] No, only the updated lifetime is returned in the response. What body responses do we send back for a DELETE? [TR] No body in DELETE for 2.xx responses. Do the body responses need to be in CBOR (including diagnostic messages) ? [TR] CBOR body only for 2.xx and 3.xx responses. CBOR Key Values mapping =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D If a request comes into the server that does not use the CBOR mapping param= eters (section 6), is this to be rejected? [TR] Yes. If the request is to be accepted, is the server response to always use CBOR= mapping, or does the server have to reply without using the CBOR mapping? [TR] DOTS server also uses the CBOR mapping. Scope =3D=3D=3D=3D=3D Scope has been defined as an array - presumably to allow multiple mitigatio= n-ids to be returned in a response. However, if two or more mitigation-ids are used in a PUT - is this allowed?= [TR] Yes. If there are 2 or more mitigation-ids, what does the response code refer to= - especially if it would be different for the individual request mitigatio= n-ids? [TR] No, there is no mechanism to send multiple response codes (Even if on= e mitigation-id succeeds but the other mitigation-id fails then an error is= returned in the response). -Tiru -- I'm sure that more questions will come up as we continue to try to do an im= plementation of the signal channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Jon Shallow Sent: 08 September 2017 16:56 To: dots@ietf.org Subject: [Dots] Coding and Interoperability Challenges Hi there, We are in the process of trying to code up a DOTS Client / Server implement= ation based on the draft standards so far and have come up with the followi= ng list of issues / questions. Nttdots =3D=3D=3D=3D=3D=3D=3D An excellent starting point, but CBOR ------- The nttdots server only accepts strings for the various parameters. It doe= s not (yet) accept CBOR that uses the CBOR mapping parameters (draft-ietf-d= ots-signal-channel Section 6). Signal Channel ------------------- Nttdots is expecting an additional path parameter in the POST/PUT etc path = (.wellknown), so instead of /v1/dots-signal/signal, it requires /.wellknown= /v1/dots-signal/signal which is not stated anywhere in the draft-ietf-dots-= signal-channel draft. If not present, it returns a 4.05 code. RFC6690 refers to "/.wellknown/core" as a default entry point for discover= ing what resources are available. RESTCONF rfc8040 refers to "/.wellknown/host-meta" to determine the RESTCON= F root resource. Data channel ----------------- Data channel support uses CBOR / COAP, not RESTCONF (well actually it goes = over the signal channel), but that is documented as a current limitation, b= ut does need to be fixed. Libcoap =3D=3D=3D=3D=3D=3D=3D The currently available c libcoap library (develop branch) from https://git= hub.com/obgm/libcoap only supports DTLS with PreSharedKeys, not Certificate= s. Work needs to be done with this library to support PKI as well as COAP = over TLS (not yet an IETF standard) to support the signal channel requireme= nts. Doing a hack to libcoap to force known PKI keys works when used against Ntt= dots, so there is potential here to use a fixed version of this library. RawPublicKey has not been tried out. Libcoap requires openssl 1.1.0 or TinyDTLS - GnuTLS support is not currentl= y available. Red Hat/Centos distributions do not have openssl 1.1.0 - DTLS= support is only version 1, not version 1.2 in their versions of openssl. = The openssl libraries cannot be replaced in Red Hat/Centos - the 1.1.0 vers= ion has to be installed in addition to the existing openssl libraries. > Libcoap assumes that all IP addresses are IPv4 (see coap_address_t), even= though there are some references to IPv6 elsewhere in the library. Not the case - Ipv6 is fully supported Default Values =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There is a list of configurable parameters, but no suggested defaults. Signal Port - UDP ---------------------- COAP using DTLS default port is 5684 (RFC 7252), nttdots port is 4646. Sho= uld DOTS be going for / defining the same port as COAP? (https://tools.ietf.org/html/draft-mortensen-dots-over-udp-00 refers to 464= 6) Signal Port - TCP --------------------- This does not have to be the same as the UDP port, but looks like it is goi= ng to be 5684 as per draft-ietf-core-coap-tcp-tls. Should DOTS be going fo= r / defining the same default port as COAP? Data Port ------------- RFC8040 - "2.2 HTTPS with X.509v3 Certificates" defines RESTCONF implementa= tions MUST support the "https" URI scheme, which has the IANA-assigned defa= ult port 443 for "/.wellknown/host-meta". Data Port cannot easily be the same as the Signal Port (TCP) as new incomin= g connections are either COAP or RESTCONF and it may be difficult to differ= entiate. Port 443 may clash with other GUIs or applications running on port 443 on t= he same host as the DOTS server. However, the other GUI/applications may h= ave to add in "/.wellknown/host-meta" to support replying that RESTCONF is = running on another port. Is the Link 'restconf' definition sufficient, or = de we need a link definition something like 'restconf-dots' added? What should the suggested default RESTCONF port be? >Mitigation Lifetime Global Mitigation Lifetime ------------------------ >This will be DOTS Server provider specific, but should be the order of day= s. Do we need to suggest a default lifetime? This is different to the lifetime refresh - I was thinking of a total mitig= ation lifetime slot as a chargeable unit when I wrote this, but this is rea= lly a DOTS Server domain controller decision. DOTS Client Restarts =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The DOTS Client will need to re-synchronize with the DOTS Server to get the= DOTS Server's current shared state (mitigation / filters etc) when it gets= restarted or reconnected. Should this be stated? DOTS Server Restarts =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The DOTS Server needs some way to signal to the DOTS client that it has res= tarted and that shared state needs to be re-synchronized. Should this be s= tated? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon --_000_DM5PR16MB1788B30F01C35B8E41564384EA7F0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please se= e inline [TR]

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Thursday, September 14, 2017 4:16 PM
To: dots@ietf.org
Subject: Re: [Dots] Coding and Interoperability Challenges

 

Hi ther= e,

&n= bsp;

No resp= onses to date.

&n= bsp;

I have = subsequently found that libcoap does properly support IPv6 – and have= updated my previous questions / comments.

&n= bsp;

I howev= er have further signal channel questions / discrepancies from https://datatracker.ietf.org/doc/draft-ietf-do= ts-signal-channel

&n= bsp;

Usage o= f PUT signal

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Usage o= f “attack-status”

-------= ------------------------

5.3.1. = PUT definition does not include ‘“attack-status”: integer= ’

5.3.4. = PUT definition is initially identical to 5.3.2, but includes ‘“= attack-status”: integer’ and states that it is mandatory.<= /o:p>

&n= bsp;

If this= parameter is mandatory, then it should be included in the 5.3.1 definition= , or is it mandatory only if this is defining an Efficacy update?

 

[TR] “attack-status”= ; parameter is specific to efficacy update.

 

With th= e 5.3.4 version, would not just sending the “mitigation-id” and= “attack-status” be sufficient?

 

[TR] No. PUT updates the mitiga= tion request, Efficacy update has to convey all the parameters sent in the = original mitigation request (see https://tools.ietf.org/html/rfc7252#section-5.8.3= ).

&n= bsp;

When re= freshing with a 5.3.4 PUT, does this reset the lifetime expiry counter?

 

[TR] Yes, 5.3.4 PUT updates the= mitigation lifetime.

&n= bsp;

PUT ref= resh

-------= --------

When th= e PUT is refreshed by the client at some point before the lifetime expires,= if the signal mitigate content (e.g. target-protocol is changed) is sent b= y the client, should this be allowed, ignored or rejected?

 

[TR] Allowed.=

&n= bsp;

COAP Re= sponse information

-------= -----------------------------

There i= s reference to the server having the ability to update the lifetime in its = response to the PUT (5.3.1).

&n= bsp;

“= The server MUST always indicate the actual lifetime in

 &= nbsp;    the response and the remaining lifetime in status m= essages sent to

 &= nbsp;    the client.  This is an optional attribute in = the request.”

&n= bsp;

However= , nowhere else does it state what should be in the body of the  respon= se (if anything) for a PUT or DELETE.  There are hints in the COAP RFC= that suitable diagnostics can be added for failure response codes.

Do we j= ust echo back the request (with update lifetime possibly) for PUT?

 

[TR] No, only the updated lifet= ime is returned in the response.

 

What bo= dy responses do we send back for a DELETE?

 

[TR] No body in DELETE for 2.xx= responses.

&n= bsp;

Do the = body responses need to be in CBOR (including diagnostic messages) ?

 

[TR] CBOR body only for 2.xx an= d 3.xx responses.

&n= bsp;

CBOR Ke= y Values mapping

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

If a re= quest comes into the server that does not use the CBOR mapping parameters (= section 6), is this to be rejected? [TR] Yes.

If the = request is to be accepted, is the server response to always use CBOR mappin= g, or does the server have  to reply without using the CBOR mapping?

 

[TR] DOTS server also uses the = CBOR mapping.

&n= bsp;

Scope

=3D=3D= =3D=3D=3D

&n= bsp;

Scope h= as been defined as an array – presumably to allow multiple mitigation= -ids to be returned in a response.

&n= bsp;

However= , if two or more mitigation-ids are used in a PUT - is this allowed?= [TR] Yes.

If ther= e are 2 or more mitigation-ids, what does the response code refer to –= ; especially if it would be different for the individual request mitigation= -ids?

 

[TR]  No, there is no mech= anism to send multiple response codes (Even if one mitigation-id succeeds b= ut the other mitigation-id fails then an error is returned in the response)= .

 

-Tiru

 

--=

I’= ;m sure that more questions will come up as we continue to try to do an imp= lementation of the signal channel.

&n= bsp;

Regards=

&n= bsp;

Jon

From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: 08 September 2017 16:56
To: dots@ietf.org
Subject: [Dots] Coding and Interoperability Challenges

 

Hi there,

 

We are in the process of trying= to code up a DOTS Client / Server implementation based on the draft standa= rds so far and have come up with the following list of issues / questions.<= o:p>

 

Nttdots

=3D=3D=3D=3D=3D=3D=3D

 

An excellent starting point, bu= t

 

CBOR

-------

 

The nttdots server only accepts= strings for the various parameters.  It does not (yet) accept CBOR th= at uses the CBOR mapping parameters (draft-ietf-dots-signal-channel Section= 6).

 

Signal Channel

-------------------<= /span>

 

Nttdots is expecting an additio= nal path parameter in the POST/PUT etc path (.wellknown), so instead of /v1= /dots-signal/signal, it requires /.wellknown/v1/dots-signal/signal which is= not stated anywhere in the draft-ietf-dots-signal-channel draft.  If not present, it returns a 4.05 code.

RFC6690 refers to  “= /.wellknown/core” as a default entry point for discovering what resou= rces are available.

RESTCONF rfc8040 refers to R= 20;/.wellknown/host-meta” to determine the RESTCONF root resource.

 

Data channel<= /p>

-----------------

 

Data channel support uses CBOR = / COAP, not RESTCONF (well actually it goes over the signal channel), but t= hat is documented as a current limitation, but does need to be fixed.<= /o:p>

 

Libcoap

=3D=3D=3D=3D=3D=3D=3D

 

The currently available c libco= ap library (develop branch) from htt= ps://github.com/obgm/libcoap only supports = DTLS with PreSharedKeys, not Certificates.  Work needs to be done with= this library to support PKI as well as COAP over TLS (not yet an IETF standard) to support the signal channel requirem= ents.

 

Doing a hack to libcoap to forc= e known PKI keys works when used against Nttdots, so there is potential her= e to use a fixed version of this library.

 

RawPublicKey has not been tried= out.

 

Libcoap requires openssl 1.1.0 = or TinyDTLS – GnuTLS support is not currently available.  Red Ha= t/Centos distributions do not have openssl 1.1.0 – DTLS support is on= ly version 1, not version 1.2 in their versions of openssl.  The openssl libraries cannot be replaced in Red Hat/Centos – the 1.1= .0 version has to be installed in addition to the existing openssl librarie= s.

 

> Libcoap assumes that all IP addresses are IPv4 (s= ee coap_address_t), even though there are some references to IPv6 elsewhere= in the library.

Not the= case – Ipv6 is fully supported

 

Default Values

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

 

There is a list of configurable= parameters, but no suggested defaults.

 

Signal Port – UDP

----------------------

 

COAP using DTLS default port is= 5684 (RFC 7252), nttdots port is 4646.  Should DOTS be going for / de= fining the same port as COAP?

(http= s://tools.ietf.org/html/draft-mortensen-dots-over-udp-00 refers to 4646)

 

Signal Port – TCP

---------------------

 

This does not have to be the sa= me as the UDP port, but looks like it is going to be 5684 as per draft-ietf= -core-coap-tcp-tls.  Should DOTS be going for / defining the same defa= ult port as COAP?

 

Data Port

-------------=

 

RFC8040 – “2.2 HTTPS with X.509v3 Certificates” defin= es RESTCONF implementations MUST support the "= ;https" URI scheme, which has the IANA-assigned default port 443 for “/.wellknown/host-meta”.=

 

Data Port cannot easily be the same as the Signal Port (TCP) as new inc= oming connections are either COAP or RESTCONF and it may be difficult to di= fferentiate.

 

Port 443 may clash with other GUIs or applications running on port 443 = on the same host as the DOTS server.  However, the other GUI/applicati= ons may have to add in “/.wellknown/host-meta” to support replying that RESTCONF is running on another port.  Is the= Link ‘restconf’ definition sufficient, or de we need a link de= finition something like ‘restconf-dots’ added?

 

What should the suggested default RESTCONF port be?=

 

>Mitigation Lifetime<= o:p>

Global = Mitigation Lifetime

------------------------

 

>This will be DOTS Server provider specific, but sh= ould be the order of days.  Do we need to suggest a default lifetime?<= span style=3D"color:#1F497D">

This is= different to the lifetime refresh – I was thinking of a total mitiga= tion lifetime slot as a chargeable unit when I wrote this, but this is real= ly a DOTS Server domain controller decision.

 

DOTS Client Restarts=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 

The DOTS Client will need to re= -synchronize with the DOTS Server to get the DOTS Server’s current sh= ared state (mitigation / filters etc) when it gets restarted or reconnected= .  Should this be stated?

 

DOTS Server Restarts=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 

The DOTS Server needs some way = to signal to the DOTS client that it has restarted and that shared state ne= eds to be re-synchronized.  Should this be stated?

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Regards

 

Jon

--_000_DM5PR16MB1788B30F01C35B8E41564384EA7F0DM5PR16MB1788namp_-- From nobody Sat Sep 30 13:44:40 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A794134219 for ; Sat, 30 Sep 2017 13:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeNrXD0254D8 for ; Sat, 30 Sep 2017 13:44:37 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E720134214 for ; Sat, 30 Sep 2017 13:44:36 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dyOcj-0001Fd-Kh; Sat, 30 Sep 2017 21:44:33 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <070601d328ba$ffbbc440$ff334cc0$@jpshallow.com> <00a101d32d46$b2f30cf0$18d926d0$@jpshallow.com> In-Reply-To: Date: Sat, 30 Sep 2017 21:44:35 +0100 Message-ID: <037701d33a2c$ed55c6b0$c8015410$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0378_01D33A35.4F1CEDD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJWDLbdGWgIliMeta88DlSb7Xyh6wERxjbqAVIVJZ+htPyQ4A== Content-Language: en-gb Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2017 20:44:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0378_01D33A35.4F1CEDD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, Thanks for your updates and feedback - much appreciated. As per https://github.com/tireddy2/DOTS/ (pre draft-ietf-dots-signal-channel-04) dated 30 Sep, along with responses to my emails of Sep 8, Sep 14 and Sep 26, I have the following additional feedback / comments and suggestions. [I see that alias is now alias-name - a clearer definition, but also needs to be the same in the data channel spec] https://github.com/tireddy2/DOTS/ ============================== 5.1 Overview "DOTS agents MUST support GET, PUT, POST, and DELETE CoAP methods." No examples are given for POST usage, so should POST be a MUST? 5.3.1. Requesting mitigation ============================= We need to clarify what is overlapping - is it just a common IP address / fqdn / uri and not common protocol "Orig: ... DOTS client is determined by comparing their respective mitigation-id values. If two mitigation requests have overlapping mitigation scopes the mitigation request with higher numeric mitigation-id value will override the mitigation request with a lower numeric mitigation-id value. The overlapped lower numeric mitigation-id is automatically deleted and no longer available at the DOTS server. New: Overlapping is true if there is a common IP, IP Prefix, FQDN, URI or alias-name between the two mitigation-ids. Orig: The Uri-Path option carries ....." 5.3.3. Retrieving a DOTS Signal (1) ================================ Bps-dropped and pps-dropped as now defined can easily be computed from the mitigation start time and the total number dropped. Over the life of a mitigation it would be good to report higher numbers at peak mitigation times. The last 1 second average, or the average since the last GET request, or last 5 minute average could be alternative methods of definition, but appreciate that methods of measurement and reporting make it difficult to be precise what easily can be reported here. Suggested replacements (included a grammar change from 'a optional' to 'an optional') Replacement: "bps-dropped: The average dropped bytes per second for the mitigation request since the last status request. This is an optional attribute." Replacement: "pps-dropped: The average dropped packets per second for the mitigation request since the last status request. This is an optional attribute." 5.3.3. Retrieving a DOTS Signal (2) ================================ Does it make sense to add in a "mitigation-start" : time as well as the bytes dropped etc. in the status response? 5.3.3.1. Mitigation Status ===================== The 03 -> 04 replacement text can be better worded as below (with spelling correction):- Orig: "A DOTS client retrieves the information about a DOTS signal at frequent intervals to determine the status of an attack. The DOTS client can send the GET request at frequent intervals without the Observe option to" Replacement: "retrieve the configuration and status data of the mitigation Request. The frequency of polling the DOTS server to get the mitigation status should follow the usage guidelines given in https://tools.ietf.org/html/rfc8085#section-3.1.3." Orig: " If the DOTS server has been able to mitigate the attack and the attack has stopped, the DOTS server indicates as such in the status, and the DOTS client recalls the mitigation request" Addition: "by issuing a DELETE for the mitigation-id." 5.4.2. Convey DOTS Signal Channel Session Configuration ======================================================== "missing-heartbeat-interval" should be "missing-hb-allowed" in Figure 16. 5.3.1. Requesting mitigation ============================= >From a previous email dialogue >> However, nowhere else does it state what should be in the body of the response (if anything) for a PUT or DELETE. There are hints in the COAP RFC that suitable diagnostics can be added for failure response codes. >> Do we just echo back the request (with update lifetime possibly) for PUT? > [TR] No, only the updated lifetime is returned in the response. OK, the CBOR response (JSON format) is which of the 2 versions below? { "mitigation-scope": { "scope": [ { "mitigation-id": integer, "lifetime": integer } ] } } Or { "lifetime": integer } We need this clarified in the spec. 5.3.2. Withdraw a DOTS Signal ============================== >From a previous email dialogue >> What body responses do we send back for a DELETE? > [TR] No body in DELETE for 2.xx responses. Spec needs to state this Orig: "The DOTS server immediately acknowledges a DOTS client's request to withdraw the DOTS signal using 2.02 (Deleted) response code." New: "There is no response payload." Orig: "A 2.02 (Deleted) Response Code is returned even if the mitigation-id ..." Other (1) ===== >From a previous email dialogue >> Nttdots is expecting an additional path parameter in the POST/PUT etc path (.wellknown), so instead of /v1/dots-signal/signal, it requires /.wellknown/v1/dots-signal/signal which is not stated anywhere in the draft-ietf-dots-signal-channel draft. If not present, it returns a 4.05 code. > [TR] The draft can be updated to use well-known URI with dots-signal as URI suffix, we can discuss in the interim WG meeting. I believe that doing a Discover (GET /.well-known/core) to determine the actual configuration paths should be used (RFC6690). Other (2) ===== >> If the DOTS client receives 3 responses of 4.22 in a row on the same session, >> the DOTS client MUST stop trying to configure the session to prevent >> a continuous retry loop." > I don't see why the client would pick unacceptable values after > getting the min/max parameters from the DOTS server. I just wanted to prevent a continuous retry in case there is some buggy software out there / faulty hardware based on certain bit patterns etc. This is the only place in the spec where the client retries sending again when a failure message is returned from the server. Other (3) ===== >> "heartbeat-refresh": {"MinValue": 2, "MaxValue" : 60}, >> heartbeat-refresh: Heartbeat refresh rate in seconds. This is an optional >> attribute. > Added heartbeat-interval (e.g. {"CurrentValue": 90, "MinValue": 60, "MaxValue" : 240}). A lot of firewalls I have worked with in the past have a default of 30 sec for UDP session timeouts. Therefore the minimum value should be less than 30 - say 10 or 15 secs to prevent firewall session expiry. Other (4) ===== >> New: "For mitigation to continue beyond the initial negotiated "lifetime", the >> DOTS client will need to refresh the current mitigation request by sending a >> new PUT request. The PUT request SHOULD use the same "mitigation-id", >> and SHOULD repeat all the other parameters as sent in the original mitigation >> request apart from a possible change to the "lifetime" >> parameter. > Any specific reason for "SHOULD" (I plan to use "MUST" instead of "SHOULD") ? MUST is fine by me Other (5) ===== >> When "observe" is set to 0, should the DOTS server send back an unsolicited >> information / status update >> a) whenever there is a "status" parameter change >> b) when there is a change to one of the "*-dropped" parameters >> c) send a response at some regular time interval? >> - Figure 10 implies it is just on a "status" parameter change. > It is a), whenever there is a change to the "attack-status" parameter value (https://tools.ietf.org/html/rfc7641 allows notification from the server only when the state changes). Actually, only "status" is returned in the GET request. "attack-status" is used for efficacy updates. Perhaps "status" should be defined as "state-status" for clarity. draft-ietf-dots-data-channel-03 ========================== 3.2.3. Retrieving Installed Identifiers ============================== The JSON examples do not always follow the YANG model Container(YANG) = object(JSON) (RFC7951- 5.2) List(YANG) = array(JSON) (RFC7951 - 5.4) "ietf-dots-data-channel-identifier:identifier" is a container, not a list, and therefore cannot be an array. Figure 7. As "alias" is the array, all the aliases should be done at that level. 3.3.1 Install Filtering Rules Draft-ietf-netmod-acl-model-13 rev 2017-06-12 has changed the YANG definition for "ietf-access-control-list:access-lists" "Added feature and identity statements for different types of rule matches. Split the matching rules based on the feature statement and added a must statement within each container." The feature containers (e.g. ipv4-acl) are missing from all examples for the filter rules. "acl-type" is now of form "ipv4-acl", not "ipv4". All references to ietf-access-control-list:access-lists need to be updated, including the rate-limiting / fragment extensions. ===================================== Regards Jon ------=_NextPart_000_0378_01D33A35.4F1CEDD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Thanks for your updates = and feedback – much appreciated.

 

As per = https://github.com/tireddy2/DOTS/ (pre = draft-ietf-dots-signal-channel-04) dated 30 Sep, along with responses to = my emails of Sep 8, Sep 14 and Sep 26, I have the following additional = feedback / comments and suggestions.

 

[I see that = alias is now alias-name – a clearer definition, but also needs to = be the same in the data channel spec]

 

https://github.com/tireddy2/DOTS/

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

5.1 = Overview

 

“DOTS agents MUST support = GET, PUT, POST, and DELETE CoAP methods.”

 

No = examples are given for POST usage, so should POST be a = MUST?

 

 

5.3.1.  Requesting = mitigation

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

We = need to clarify what is overlapping – is it just a common IP = address / fqdn / uri and not common protocol

 

“Orig: = ... DOTS client is determined by comparing their respective = mitigation-id values.  If two mitigation requests have overlapping = mitigation scopes the mitigation request with higher numeric = mitigation-id value will override the mitigation request with a lower = numeric mitigation-id value.  The overlapped lower numeric = mitigation-id is automatically deleted and no longer available at the = DOTS server.

New:  Overlapping = is true if there is a common IP, IP Prefix, FQDN, URI or alias-name = between the two mitigation-ids.

Orig:  The Uri-Path option carries = .....”

 

 

5.3.3.  Retrieving a DOTS = Signal (1)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Bps-dropped and pps-dropped as now defined can easily = be computed from the mitigation start time and the total number = dropped.  Over the life of a mitigation it would be good to report = higher numbers at peak mitigation times.  The last 1 second = average, or the average since the last GET request, or last 5 minute = average could be alternative methods of definition, but appreciate that = methods of measurement and reporting make it difficult to be precise = what easily can be reported here.

 

Suggested = replacements (included a grammar change from ‘a optional’ to = ‘an optional’)

 

Replacement:  “bps-dropped:  The = average dropped bytes per second for the mitigation

request since the last status request.  This is = an

optional = attribute.”

 

Replacement: = “pps-dropped:  The average dropped packets per second for = the

mitigation request since the last = status request.  This

is an = optional attribute.”

 

5.3.3.  Retrieving a DOTS = Signal (2)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Does it make sense to add in a = “mitigation-start” : time as well as the bytes dropped etc. = in the status response?

 

 

5.3.3.1.  Mitigation Status

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

 

The 03 -> 04 replacement text can be better worded = as below (with spelling correction):-

 

Orig: = “A DOTS client retrieves the information about a DOTS signal = at

frequent intervals to determine = the status of an attack.  The DOTS

client can send the GET request at frequent intervals = without the

Observe option to” =

Replacement: “retrieve the = configuration and status data of the mitigation

Request. The frequency of polling the DOTS server = to get the mitigation status should follow the usage guidelines given in = https://tools.= ietf.org/html/rfc8085#section-3.1.3.”

Orig:  “ If the DOTS server has been able = to mitigate the attack and

the attack = has stopped, the DOTS server indicates as such in the

status, and the DOTS client recalls the mitigation = request”

Addition: =  “by issuing a DELETE for the = mitigation-id.”

 

 

5.4.2.  Convey DOTS Signal = Channel Session Configuration

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

"missing-heartbeat-interval" should be = “missing-hb-allowed” in Figure 16.

 

 

5.3.1.  Requesting = mitigation

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

From a previous email = dialogue

 

>> However, = nowhere else does it state what should be in the body of the =  response (if anything) for a PUT or DELETE.  There are hints = in the COAP RFC that suitable diagnostics can be added for failure = response codes.

>> Do we just echo back the request (with = update lifetime possibly) for PUT?

 

> [TR] = No, only the updated lifetime is returned in the response. =

 

OK, the CBOR response (JSON format)  is which of = the 2 versions below?

 

{

  = "mitigation-scope": {

     "scope": = [

        = {

          = "mitigation-id": integer,

          = "lifetime": integer

        = }

      = ]

   }

}

 

Or =

 

{

   = "lifetime": integer

}

 

We need this = clarified in the spec.

 

 

5.3.2.  Withdraw a DOTS = Signal

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

From a previous email = dialogue

 

>> What body responses do we send back for = a DELETE?

 

> [TR] No = body in DELETE for 2.xx responses.

 

Spec needs = to state this

 

Orig: "The DOTS server immediately acknowledges a = DOTS client's request to

withdraw the = DOTS signal using 2.02 (Deleted) response code."

New: "There is no response = payload."

Orig: "A 2.02 = (Deleted) Response Code is returned even if the mitigation-id = ..."

 

 

Other = (1)

=3D=3D=3D=3D=3D

 

From a previous email = dialogue

 

>> Nttdots is = expecting an additional path parameter in the POST/PUT etc path = (.wellknown), so instead of /v1/dots-signal/signal, it requires = /.wellknown/v1/dots-signal/signal which is not stated anywhere in the = draft-ietf-dots-signal-channel draft.  If not present, it returns a = 4.05 code.

 

> [TR] The draft can = be updated to use well-known URI with dots-signal as URI suffix, we can = discuss in the interim WG meeting.

 

I believe that doing a = Discover (GET /.well-known/core) to determine the actual configuration = paths should be used (RFC6690). 

 

Other = (2)

=3D=3D=3D=3D=3D

 

>> If the DOTS client receives 3 responses of = 4.22 in a row on the same

session,

>> the DOTS client MUST stop trying to = configure the session to prevent

>> a continuous retry = loop."

 

> I = don't see why the client would pick unacceptable values after =

> getting

the min/max parameters from the DOTS server. =

 

I just wanted to prevent a continuous retry in case = there is some buggy software out there / faulty hardware based on = certain bit patterns etc.

This is = the only place in the spec where the client retries sending again when a = failure message is returned from the server.

 

Other (3)

=3D=3D=3D=3D=3D

 

 

>> "heartbeat-refresh": = {"MinValue": 2, "MaxValue" : 60},

>> heartbeat-refresh:   Heartbeat = refresh rate in seconds.  This is an

optional

>> attribute.

 

> = Added heartbeat-interval (e.g. {"CurrentValue": 90, = "MinValue": 60,

"MaxValue" : 240}).

 

A lot = of firewalls I have worked with in the past have a default of 30 sec for = UDP session timeouts.  Therefore the minimum value should be less = than

30 - say 10 or 15 secs to = prevent firewall session expiry.

 

Other (4)

=3D=3D=3D=3D=3D

 

>> New: "For mitigation to continue = beyond the initial negotiated "lifetime", the

>> DOTS client will need to refresh the = current mitigation request by sending a

>> new PUT request.  The PUT request = SHOULD use the same "mitigation-id",

>> and SHOULD repeat all the other parameters = as sent in the original mitigation

>> request apart from a possible change to = the "lifetime"

>> = parameter. 

 

> = Any specific reason for "SHOULD" (I plan to use = "MUST" instead of "SHOULD") ?

 

MUST = is fine by me

 

Other (5)

=3D=3D=3D=3D=3D

 

>> When "observe" is set to 0, = should the DOTS server send back an unsolicited

>> information / status = update

>> a) whenever there = is a "status" parameter change

>> b) when there is a change to one of the = "*-dropped" parameters

>> c) send a response at some regular time = interval?

>> - Figure 10 = implies it is just on a "status" parameter = change.

 

> It is a), whenever there is a change to the = "attack-status" parameter value (https://tools.ietf.org/html/= rfc7641 allows notification from the server

only when the state changes).

 

Actually, only “status” is returned in = the GET request. “attack-status” is used for efficacy = updates.  Perhaps “status” should be defined as = “state-status” for clarity.

 

draft-ietf-dots-data-channel-03

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 

3.2.3.  Retrieving Installed = Identifiers

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

The = JSON examples do not always follow the YANG model

Container(YANG) =3D object(JSON) (RFC7951- = 5.2)

List(YANG) =3D array(JSON) = (RFC7951 - 5.4)

"ietf-dots-data-cha= nnel-identifier:identifier" is a container, not a list, and = therefore cannot be an array. Figure 7.  As = “alias” is the array, all the aliases should be done at that = level.

 

3.3.1 Install Filtering = Rules

 = 

Draft-ietf-netmod-acl-model-13 rev 2017-06-12 has changed the YANG =
definition for =
"ietf-access-control-list:access-lists"
=

 =

"Added feature and = identity statements for different types of rule matches. Split the = matching rules based on the feature statement and added a must statement = within each container.”

 =

The feature containers = (e.g. ipv4-acl) are missing from all examples for the filter = rules.

 =

"acl-type" is = now of form "ipv4-acl", not = "ipv4".

 =

All references to = ietf-access-control-list:access-lists = need to be updated, including the rate-limiting / fragment = extensions.

 =

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

 =

Regards

 =

Jon

 =

 

 

 

------=_NextPart_000_0378_01D33A35.4F1CEDD0--